Hi, >> I think I'd trust Tom more than anyone else in OSM to understand the >> load which a given feature is going to place on the servers, > > Thats not the point, its not about x number of CPU seconds per request > - its that the statistics are fundamentally different for, say, > running a WMS and running a tile server. One scales, one doesn't.
ALL problems regarding read-access scalability can be solved by implementing a proper "feed" mechanism (or DB slaves or whatever you want to call it). We have made steps in that direction with the weekly dumps, daily diffs, hourly diffs, and OsmXAPI is doing its best to keep a current data set with these services. [EMAIL PROTECTED] read requests have already moved off the main API to OsmXAPI, and OsmXAPI scales perfectly. The only thing that isn't perfect about OsmXAPI is that its data may still be two hours old which is good enough for many cases, but still not "the real thing" (not good enough to base an export tab on). I think if we invest a bit more work in that direction, then we'll end up with a central database that will only serve live editor read/ writes, and everything else can be run from the slaves. It's not exactly a low-hanging fruit but not that difficult either, and the reward is not having to worry about numbers of read requests. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
