https://bugzilla.wikimedia.org/show_bug.cgi?id=33980
--- Comment #33 from kakrue...@gmail.com --- What is the best way to comment on the individual issues raised by Brandon? Inline comments in the wikipage? Discussing them here on the ticket, or as comments at the bottom of the wikipage? The two main issues I'd like to address though are: 1) Is there a realistic estimate of the load this system needs to actually support? On the wiki page, the proposed load numbers range from 200 tiles per second to 30000 tiles per second. It is hard to plan a system if the estimates of what needs to be supported varies over two orders of magnitude. The 200 tiles per second estimate comes from the empirical numbers we are seeing on the toolserver which is running the "in production" system for the OSM gadget which is embedded in at least the German, Italian, Spanish and a bunch of other Wikipedias and from the WMA, which is embedded in most of the "Desktop" Wikipedias. I have no idea where the estimate of 30000 tiles/s comes from. As a comparison all of osmf's tile serving infrastructure is on the order of 3000 - 4000 tile/s including everywhere where the osmf tiles are embedded in other peoples site. So it seems like we really need a better and more justified estimate of the expected load. I.e. looking through the logs of the existing systems, both for mobile (mapquest open) and desktop (toolserver) and figure out what access patterns the pages have, where these tiles would be used in. My impression is that we are trying to build a system that is potentially orders of magnitude more potent than what is actually needed in the beginning. One has to, however, also remember, that there are two types of scaling in a typical tile server that are semi-independent and scale in different ways and have rather different hardware demands: Scaling of serving of tiles and scaling of rendering. Although rendering does to some degree scale with serving load, to a good degree, it also scales with update frequency and editing frequency in OSM, both of which are independent of the size of the serving site. 2) "direct PostgreSQL queries for rendering aren't going to scale well". Although it depends on what exactly you mean, the OSM rendering stack has proved in countless installations that it does scale pretty well. And really, the system is the only way that is possible if you want an up-to-date map at high zoom levels unless you throw a gigantic amount of hardware at it. And even then, you wont be able to achieve the minutely updated map up to Z20, as you can with the current OSM software stack without too much issues. It is also follows the concept that is used in pretty much any other scaleable website (including mediawiki). I.e. that you have a bunch of application servers in the background that render pages from a database on request and then have multiple levels of caching in front of that to achieve the necessary performance. That is exactly what mod_tile / renderd do as well and only a tiny fraction of requests actually need to be rendered on the fly. E.g. looking at the setup on osm.org. Out of the 3000 tiles/s served, typically only somewhere between 5 - 10 tiles/s are rendered on the fly. As most of those are updates, only about 1 tile/s is not actually available in the master cache (of about 1.5TB) and needs to be rendered on the fly. As nearly all of those are high zoom tiles, they typically can be rendered in a few 100 milliseconds and so a single multi-core server is usually quite capable of rendering 5 - 10 tiles/s. The master cache can also vary smoothly between 0 and the full set of all tiles depending on where you want to put the trade off of between disk space and rendering capacity. Empirically 1 - 2 TB have generally proven as fairly good trade-offs. Furthermore, mod_tile / renderd are designed to very gracefully degrade once they can't keep up with the rendering load anymore and simply some of the areas won't be quite fully up-to-date for the duration of the overload. But pretty much no one will notice if it shows "yesterday's" map instead of "today's" map. Once you move over to trying to display many different map styles, things start to look differently, as in the current setups you need to more or less "duplicate" things per style. At that point you probably do want to move over to "vector tiles" which get styled and rendered either on the client side, or potentially on the fly server side for weak dumb clients. The software stack for that is indeed not yet well developed and tested. But for a single style, I would consider the current software stack as fairly mature, robust and scalable. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
