Jason, You're not at all wrong about the issues with the server design.
This is something that's been well known and understood for several years: As the project grows, the cost of scaling on a single system will not scale accordingly. What I mean by that is, that it's not a linerar cost to buy a single machine with linear scaling. So if you are growing, it makes more economical (and technical) sense to scale away, rather than building up. What would this mean in the context of OSM? It might mean something like moving the GPX data off the main database. Or maybe having historical data on a slower database than the current data. It also includes things like aggressive caching and uausing tiled map calls (something that Ian and I worked on, and Ian has a new implementation of). And there's room for more optimizations even then, but just these would make an impact. So why doesn't this happen? Frankly, because I think the project doesn't have anyone who can act in the kind of technical leadership role this would require. Making these kinds of changes would require modifying (and testing) the rails port, as well as possibly modifying cgimap (depending on which calls were effected), and the database, and setting up the new hardware, and coordinating with whatever hosting situation that would be in, etc. It's not something anyone can do, with the possible exception of the sys-admins (who are both extremely overworked and volunteer). This is why the org needs a structural change, to give someone the authority and resources to oversee projects like this. Without this, the OWG is stuck ordering more hardware. - Serge _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
