Support for limiting number of connections

[rinigus]

It would be great to be able to specify the number of concurrent connections to tile server in the tile server configuration. That would allow to limit this number when needed. Use case: locally running osmscout-server limits the number of generated tiles by number of CPU cores. All additional connections are simply dropped. I expect that some service providers could do the same.

[M4rtinK]

It would be great to be able to specify the number of concurrent connections to tile server in the tile server configuration. That would allow to limit this number when needed.

Yeah, that really should be supported & configured from the map config file. Possibly with limits both per layer & per layer group - if OSM scout provided more layers it would be possible to set a global limit for all layers it provides.

There is currently a global download pool fed by a single download queue, but I think it should be doable to make it respect a maximum number of download requests for a given layer/group in the pool at any given time. :)

Use case: locally running osmscout-server limits the number of generated tiles by number of CPU cores. All additional connections are simply dropped.

Hmm, I wonder if the connections could be eventually queued and only forwarded to the rendering pool once a rendering "slot" becomes available ?

This would have the benefit of making it possible to make effective use of resources - it would generally make sense for apps to do the same thing as osmscout-server when requesting tiles - open 2 connections on a 2 CPU device to make the tiles available as quickly as possible (eq. make osmscout use both CPUs for rendering). But that would basically mean that two apps can't share one running osmscout-server in such case - depending on implementation of the current connection handling either the first application would get both of the slots and the other one would get only dropped connections or each application would generally get 50% of connections dropped.

Another possibly more advanced use-case/optimization would be to let applications open a lot more connections than the number of CPUs the device has and use that to optimize rendering - applications seldom request random tiles but rather bunches of neighboring tiles. A rendering server can make use of that and render a single area covering the neighboring tiles at once and then chop that to the tiles requested and feeding them to the respective connections. IIRC that's what Mapnik does for dynamic rendering of high zoom levels, but I'm not sure how hard or easy this would be to implement in osmscout-server.

Basically just a bunch of ideas/suggestions. :)

I expect that some service providers could do the same.

Yeah, some providers indeed seem to be stingy about this. Yet another argument for robust local map rendering. :-)

So until per layer/group thread count is implemented, I have setup a workaround:

1. pull latest modRana from master
2. go to Options->Network (you are using the Qt 5 interface, right ?)
3. set the number of automatic download threads to 1 (or possibly 2/4, depending on CPU count)
4. then restart modRana for the change to take effect.

That should stop modRana from firing 10 download threads your direction as it does by default. :)

[rinigus]

Hmm, I wonder if the connections could be eventually queued and only

forwarded to the rendering pool once a rendering "slot" becomes available ?

This would have the benefit of making it possible to make effective use of resources - it would generally make sense for apps to do the same thing as osmscout-server when requesting tiles - open 2 connections on a 2 CPU device to make the tiles available as quickly as possible (eq. make osmscout use both CPUs for rendering). But that would basically mean that two apps can't share one running osmscout-server in such case - depending on implementation of the current connection handling either the first application would get both of the slots and the other one would get only dropped connections or each application would generally get 50% of connections dropped.

Dropping of the connections is an unfortunate limitation (feature) of the library that I use to provide http server. In generel, queuing would be preferred and I should either swap the library or write a patch to fix it. I'll put it into issues for the server.

Another possibly more advanced use-case/optimization would be to let applications open a lot more connections than the number of CPUs the device has and use that to optimize rendering - applications seldom request random tiles but rather bunches of neighboring tiles. A rendering server can make use of that and render a single area covering the neighboring tiles at once and then chop that to the tiles requested and feeding them to the respective connections. IIRC that's what Mapnik does for dynamic rendering of high zoom levels, but I'm not sure how hard or easy this would be to implement in osmscout-server.

It is possible. This is done in some other code (qt client library of libosmscout, if I am not mistaken). However, it seems to me that similar effect can be reached by larger tiles with the Z and tile size given by user. This technique is simple and I used it in https://github.com/rinigus/osmscout-server/blob/master/thirdparty/poor-maps/tilesources/osmscout_day_L_%401x.json . Namely, when poor-maps is thinking that it pulls tiles for some Z, in reality, Z+1 (thats parameter shift in URL) are shown allowing me to pack 4 256x256 tiles into one 512x512. I must say that I prefer this approach since its simple and allows to optimize parameters in determined manner.

Basically just a bunch of ideas/suggestions. :)

Keep them coming :)

I expect that some service providers could do the same.

Yeah, some providers indeed seem to be stingy about this. Yet another argument for robust local map rendering. :-)

So until per layer/group thread count is implemented, I have setup a workaround:

1. pull latest modRana from master
2. go to Options->Network (you are using the Qt 5 interface, right ?)
3. set the number of automatic download threads to 1 (or possibly 2/4, depending on CPU count)
4. then restart modRana for the change to take effect.

No problem - no workaround needed for me :) . But would be great to have as an option in the program. I found the code in modRana and hacked it to limit it to 4. On desktop, I use GTK, I think. On phone, I am not sure whether I even patched it - have to check. If memory serves me right, on phone it wasn't needed.

cheers,

rinigus

[rinigus]

Hi! Just wanted to give you an update - I am getting closer to the first release with search (location and free text) and POI guide (POI next to the given origin) implemented. Its surely not perfect, but it may be a good time to start getting the first version out of the way. At this time, I'll forward users to readme with the code snippet to help them to access the server from modRana (as a tile server). However, since there are several issues that have to be resolved with the server (import, for example), I presume that the most of the interest would be from map app developers with the user base coming later. This release should allow you to test the server and see what can be done better

best wishes,

rinigus

[M4rtinK]

Dropping of the connections is an unfortunate limitation (feature) of the library that I use to provide http server. In generel, queuing would be preferred and I should either swap the library or write a patch to fix it. I'll put it into issues for the server.

Sounds good. :)

It is possible. This is done in some other code (qt client library of libosmscout, if I am not mistaken). However, it seems to me that similar effect can be reached by larger tiles with the Z and tile size given by user. This technique is simple and I used it in https://github.com/rinigus/osmscout-server/blob/master/thirdparty/poor-maps/tilesources/osmscout_day_L_%401x.json . Namely, when poor-maps is thinking that it pulls tiles for some Z, in reality, Z+1 (thats parameter shift in URL) are shown allowing me to pack 4 256x256 tiles into one 512x512. I must say that I prefer this approach since its simple and allows to optimize parameters in determined manner.

Yeah, that's definitely simpler way how to optimize stuff and mostly how the current tile scaling works in modRana - it takes a tile from a lower zoom level and stretches it over 4 tiles on the current zoom level, mostly to make text and other features bigger (but blurry). But of course if it takes a tile that already is 512x512 pixels it won't get blurry. :)

BTW, even thought this is actually the incorrect issue for this but it looks like the new modRana tile drawing code I'm currently working on actually does the map tile scaling almost without a hitch. :D There are some small issues with switching the scaling factor not updating the tile tracking model, but that should be quite easy to fix.

So in general the tile scaling breakage should be fixed once I merge the better_tile_drawing branch back to master, which should be hopefully quite soon. :)

Keep them coming :)

OK. :)

Hi! Just wanted to give you an update - I am getting closer to the first release with search (location and free text) and POI guide (POI next to the given origin) implemented. Its surely not perfect, but it may be a good time to start getting the first version out of the way. At this time, I'll forward users to readme with the code snippet to help them to access the server from modRana (as a tile server).

I guess it could be added to the default map config file - say an "OSM Scout" group with two layers: "day" and "night" (or "OSM Scout day" & "OSM Scout night" if just day & night would be too generic). We could also mark it "EXPERIMENTAL" or something for the time being (group & layer name can be easily changed later as long as the id/folder name stays the same. :)

I guess I could also add a check to trigger a notification telling user it is experimental and some manual setup is currently needed.

EDIT: And we could then add the maximum connection count property to the group & layer descriptions once the needed code is in place in modRana. :)

However, since there are several issues that have to be resolved with the server (import, for example), I presume that the most of the interest would be from map app developers with the user base coming later. This release should allow you to test the server and see what can be done better

That sounds very good - and yet again a huge thanks for doing all this! :)

I'll make sure to let you know if I hit any issues when I try it out & or if I get any improvement ideas/suggestions. :)

[rinigus]

Yeah, that's definitely simpler way how to optimize stuff and mostly how the current tile scaling works in modRana - it takes a tile from a lower zoom level and stretches it over 4 tiles on the current zoom level, mostly to make text and other features bigger (but blurry). But of course if it takes a tile that already is 512x512 pixels it won't get blurry. :)

Note that maybe 1024x1024 is even better in practice.

BTW, even thought this is actually the incorrect issue for this but it looks like the new modRana tile drawing code I'm currently working on actually does the map tile scaling almost without a hitch. :D There are some small issues with switching the scaling factor not updating the tile tracking model, but that should be quite easy to fix.

So in general the tile scaling breakage should be fixed once I merge the better_tile_drawing branch back to master, which should be hopefully quite soon. :)

Excellent!

I guess it could be added to the default map config file - say an "OSM Scout" group with two layers: "day" and "night" (or "OSM Scout day" & "OSM Scout night" if just day & night would be too generic). We could also mark it "EXPERIMENTAL" or something for the time being (group & layer name can be easily changed later as long as the id/folder name stays the same. :)

I guess I could also add a check to trigger a notification telling user it is experimental and some manual setup is currently needed.

Would be great to get the configs in modRana repo. The manual setup mainly requires import of the maps. The rest should be fine as soon as modRana is configured to access it. But experimental is surely adequate - we don't know how it will work for others in practice.

However, since there are several issues that have to be resolved with the server (import, for example), I presume that the most of the interest would be from map app developers with the user base coming later. This release should allow you to test the server and see what can be done better

That sounds very good - and yet again a huge thanks for doing all this! :)

I'll make sure to let you know if I hit any issues when I try it out & or if I get any improvement ideas/suggestions. :)

Thank you! And it would impossible without great code covering client side :)

[rinigus]

Dear @M4rtinK,

I finally released the first version to OpenRepos, so you could try it. I very much hope it will work as intended and it would hook with modRana in your setup as well.

I will start looking into routing now to be able to cover all the basic functionality. Then I could run through all functionality again and enhance it.

Thank you for your help!

rinigus

[rinigus]

Just an update - I am changing the internal web engine and I hope to be able to accept large number of connections in the end. The connections will be queued in the server and pulled when calculating slot is available. That should simplify things on your side by keeping the connection count as it is. I'll let you know when new HTTP server code is ready

[M4rtinK]

Dear @M4rtinK,

I finally released the first version to OpenRepos, so you could try it. I very much hope it will work as intended and it would hook with modRana in your setup as well.

Thanks a lot - I will hopefully finally try it out in a few days. I've been recently a bit more busy than usual & was also battling a nasty cold. But that should be over now and I should hopefully be again able to get back up to speed. :)

I will start looking into routing now to be able to cover all the basic functionality. Then I could run through all functionality again and enhance it.

Sounds good! :)

Thank you for your help!

Thanks to you for all the work you are doing on the libosmscout-server! :)

rinigus

[M4rtinK]

Just an update - I am changing the internal web engine and I hope to be able to accept large number of connections in the end. The connections will be queued in the server and pulled when calculating slot is available. That should simplify things on your side by keeping the connection count as it is. I'll let you know when new HTTP server code is ready

That sounds good - while per map layer/map layer group connection count limiting is certainly doable, it is not trivial if it also should be robust enough and handle various edge cases and issues such as download queue starvation, etc. There is also a lot of other stuff on the TODO pile, such as libosmscout-server API usage improvements, stabilization of the new tile drawing code, etc.

So thanks for the heads up - it's good to know I can prioritize other stuff for now. :)

[rinigus]

Great! I am swamped with few bug reports, but would hopefully get a chance to work on HTTP server part tonight. So, I hope it would progress in time and will be ready by the modRana release. Take care and keep away from cold :)

[rinigus]

Since its not needed anymore - let's close it.

[M4rtinK]

Sure. :)