|
What kind of hardware would be required for tile server(s) to support 18k map-view requests per minute? I know there are a lot of variables involved, but a ballpark estimate would be fine. |
|
In my experience, a "standard" server (enterprise SSD, quad-core processor, 32 GB RAM*) will do around 1 metatiles per second (that's 64 tiles) on the "easy" zoom levels (14 and above), giving you about 4000 tiles per minute. That's the rendering performance, and not taking into account potential updates; delivering the tiles is something else but usually not critical. Your assumption that 80% will require rendering on the fly is un-realistic for most use cases since most use cases will have "hot spots" - either along the motorway network if you're monitoring cars, or at event locations if you're monitoring events, etc. - leading to a much higher cache hit rate. Load-balancing the creation of tiles is a bit tricky as if you're doing it wrong you'll just waste time by having the same tiles created on multiple machines. My suggestion would be to go with a 64 GB dual-quad core system with 1 TB of NVMe disks and if you find that's not good enough for you, add a couple proxies to lighten the tile access load. (*) note that more than 32 GB of RAM might be required to do a data import, depending on how you build your infrastructure. What method would you recommend for load balancing such that high-availability is maintained (database, rendering, & serving), but rendering isn't duplicated on multiple systems? Is there a way to push a rendered tile out to the other systems when it's first rendered so that they only have to read it from cache?
(09 Jul '16, 01:00)
bengsp
There are many ways but one possible way is to use a "pinning" load balancer that tries to route all requests from the same client to the same server. Then you could use serveral Tirex (not renderd) based tile servers and have them synchronize their caches with tirex-syncd, or you could use renderd based tile servers that don't use a local tile cache but one that resides on a reliable network file system.
(09 Jul '16, 20:39)
Frederik Ramm ♦
Would using something like lsyncd be an option to keep tile cache synced between servers while continuing to use renderd? If renderd uses the database or something else to keep track of what tiles have already been rendered then I expect that wouldn't work, but I don't know if that's the case.
(14 Jul '16, 22:09)
bengsp
1
It would work but consider this: You use some sort of load balancing that randomly distributes requests across all your servers. Someone views the map on his browsers and generates 20 different tile requests. All happen to be on a single 8x8 meta but the requests are distributed across 10 servers. Now all 10 servers have to compute the same meta tile - which means your performance isn't any better than if you only had one server. This problem can be reduced by pinning requests from the same client to the same backend server. DNS round robin may work in many cases too if browsers cache DNS lookup results.
(14 Jul '16, 22:24)
Frederik Ramm ♦
So as long as there's a persistence profile in place that keeps a user pinned to the same server (with a timeout of at least, say, 15-20 sec) then syncing the tile cache directory would work? Renderd doesn't rely on the database for information about what tiles have already been rendered?
(15 Jul '16, 01:06)
bengsp
Yes it would work (at least for the standard file backend in renderd). There's no status being kept about finished jobs outside of the meta tile tree in the file system.
(15 Jul '16, 07:42)
Frederik Ramm ♦
showing 5 of 6
show 1 more comments
|
|
This is not from the OpenStreetMap ecosystem of software, but I think you will find the ESRI maintained System Design Strategies pages a good read. http://wiki.gis.com/wiki/index.php/System_Design_Strategies_Preface Since the basic processes of creating web maps and tiles are similar, the benchmarks and graphs ESRI is showing, should give you some idea of the kind of hardware required. Especially the Platform Performance page should potentially be of help: |
Please explain what you mean by "map view". Does that include zooming and panning, or is it a new "map view" every time the user does something? How big is the map display?
Each request would = 1 tile. We can assume zoom levels 0-12 would be pre-rendered, but the remaining levels would need to be rendered on the fly and delivered to the client within a reasonable amount of time, so within a couple seconds.
Are you updating the OSM data that you're storing? If so, presumably you're doing something with "dirty" tiles (rerender, mark as dirty or delete) and that needs to be factored in.
If I was being asked for an answer to that question at $dayjob, the first thing that I'd ask for is more information - possibly via a chat with the potential customer. You might find you get more luck in a more interactive channel such as #osm-dev - without more details any answers are bound to be a bit "how long is a piece of string".
Yes, the OSM data would be updated and tiles would be re-rendered afterward, but this would be a high-availability setup and that could be done while one or more other tile servers handle the load. For simplicity, I would leave that as a non-factor and it will be refactored in later.
Basically I just want to know necessary system requirements to handle serving of 18k tiles/minute. Since I don't know the exact % of total requests that would fall on each zoom level, we can be conservative and say 80% of total requests (~14k) will need rendered on the fly.
So what hardware (storage, RAM, & compute) would be required to render roughly 14k tiles/minute? Are we talking 4-core 32GB RAM and a single enterprise SSD, or something like 40-core 512GB RAM and enterprise-class IO accelerator PCI-E storage?