My concern is that even if a reimplementation of the API in some other
form will not fundamentally solve the scalability problem if all data
requests will have to be served by a single machine.<br><br>Will not the introduction of the 0.6 API offer a solution in the sense that will will with far greater reliability allow the separation of read and write requests? With versioned map elements all read requests could be redirected to some mirror server, while only write requests will continue to hit the real (master) server. With read requests removed from the main server, it should be able to handle serve more active mappers better than at the moment.<br>
<br>Mirror servers, in the form of OSMXAPI (which claims to be only a few minutes behind the real DB nowadays), could then handle the bulk of the requests.<br><br>Could the effort for a API reimplementation be directed to some sort of smart mirror service using HTTP redirects, which would shield client applications from the existence of the mirror services?<br>
A first version could redirect read-request to a single read-only server, while future versions could smarten up and be specific on bounding boxes, allowing for a regionalisation of mirror servers, which would not have to host the entire world...<br>
Much of that could probably be achieved by URL rewriting in Apache.<br><br><br>Ludwig<br><br><br><br><br><div class="gmail_quote">2008/5/26 Tom Hughes <<a href="mailto:tom@compton.nu">tom@compton.nu</a>>:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In message <1211658532.3899.18.camel@test.asus><br>
<div class="Ih2E3d">          Joachim Zobel <<a href="mailto:jzobel@heute-morgen.de">jzobel@heute-morgen.de</a>> wrote:<br>
<br>
> Am Donnerstag, den 22.05.2008, 00:06 +0100 schrieb Tom Hughes:<br>
> > > Writing Apache modules in C is hard, and I don't think using mod_cpp<br>
> > > will make it much easier. Doing Apache modules in Perl (mod_perl has<br>
> > API<br>
> > > access including filters) is a lot easier.<br>
> ><br>
> > Ye gads no. We want to keep the memory footprint under some sort of<br>
> > control so mod_perl is a non-starter.<br>
><br>
> Everybody seems obsessed with low memory footprint. Why? Memory is<br>
> cheap, and we are not planning an embedded system. What is the number of<br>
> concurrent requests we need to handle?<br>
<br>
</div>I'm not obsesses with memory footprint, but with our current code<br>
memory is far and away the biggest problem.<br>
<br>
Currently we can handle about six simultaneous requests to the data<br>
heavy API calls - that is basically map data downloads, gps data<br>
downloads and potlatch calls.<br>
<br>
The reason is that we have to allow about 600Mb or so for each call<br>
and that quickly mounts up as you try and add extra simultaneous<br>
accesses.<br>
<br>
Factor in the fact that many of these calls may take a minute or<br>
more and you have a serious limitation to the load we can support.<br>
<br>
Of course we can just add hardware, but we should be able to reduce<br>
the menory footprint dramatically as well.<br>
<div><div></div><div class="Wj3C7c"><br>
Tom<br>
<br>
--<br>
Tom Hughes (<a href="mailto:tom@compton.nu">tom@compton.nu</a>)<br>
<a href="http://www.compton.nu/" target="_blank">http://www.compton.nu/</a><br>
<br>
_______________________________________________<br>
dev mailing list<br>
<a href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev" target="_blank">http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev</a><br>
</div></div></blockquote></div><br>