On 08/12/08 18:51, Milenko wrote: >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:tilesathome- >> [EMAIL PROTECTED] On Behalf Of Kai Krueger >> Sent: Monday, December 08, 2008 1:39 PM >> To: [email protected] >> Subject: Re: [Tilesathome] Using RAM-drive for ROMA temp tables >> >> On 08/12/08 18:18, Matthias Julius wrote: >> >>> "Milenko"<[EMAIL PROTECTED]> writes: >>> >>> >>> >>>> Is this worth trying? I'll try it on my server if no one else wants >>>> >> to >> >>>> volunteer. :) Are we sure that these tags are not needed by the >>>> >> clients? >> >>>> Anyone have any other tags that might not be needed? >>>> >>>> >>> Unless the ROMA servers are dedicated to [EMAIL PROTECTED] we need to be >>> careful >>> when filtering out tags and attributes. >>> >>> >> Unless it causes too much trouble, I would be also in favor of keeping >> all the tags. At the moment the results returned by ROMA are fully >> compatible with the main API as far as I know and so ROMA could be used >> for more than just [EMAIL PROTECTED], potentially even a limited form of >> editing, >> which I think is a good idea. As an example of other applications using >> ROMA, I have added roma as an alternative source to getting data for >> GpsMid, although that would cope fine with the tags you suggested to >> filter. >> >> Kai >> >>> Matthias >>> > > OK - I wasn't aware that the ROMA servers were being used for other > purposes. That's why I asked first. If that's the case, then we should > leave the db alone. > > I've been trying to speed up the response time of my server without having > to purchase additional hardware - guess maybe I'll have to look at some > additional drives. >
Well, if it means you don't have to buy new hardware, then I think it would be fair enough to say those applications that need that data have to use something else, especially as those tags you suggested to drop are probably only ever needed if you plan to reupload the data. But does it really make that much of a difference? As mentioned already by others, there should probably also be a clear OSM wide way of marking data as "incomplete" which editors and the main API could recognize and reject if appropriate. There are probably a bunch of other things that could be optimized in [EMAIL PROTECTED] aswell that would allow for better response times. Overall, the 4 ROMAs now running seemed to just about be enough on average, although during busy times you can easily wait 5 - 10 minutes for a single request. One of the main problems seem to be the huge load spikes generated by the current way of adding changed tiles once every couple of hours. Here suddenly nearly all clients start requesting complex tiles at once, causing queuing times of up to 10 minutes, whereas at the end of the changed request period, often the ROMAs are mostly idle. A more even injection of changed tiles might help quite a bit here. Also I am wondering if something else is going on with tiles getting rerequested? In the 3 last three days, the LB has processed about 150.000 requests with close to 300 GB of traffic. That would be about 2000 requests per hour. The [EMAIL PROTECTED] statistics however show only about 800 processed tiles per hour on average? Does anyone know where this large discrepancy comes from? Kai > -Jeremy > > > > _______________________________________________ > Tilesathome mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/tilesathome > _______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/listinfo/tilesathome
