[Tilesathome] Using RAM-drive for ROMA temp tables

[Kai Krueger]

On 08/12/08 18:51, Milenko wrote:
>> -----Original Message-----
>> From: tilesathome-bounces at openstreetmap.org [mailto:tilesathome-
>> bounces at openstreetmap.org] On Behalf Of Kai Krueger
>> Sent: Monday, December 08, 2008 1:39 PM
>> To: tilesathome at openstreetmap.org
>> Subject: Re: [Tilesathome] Using RAM-drive for ROMA temp tables
>>
>> On 08/12/08 18:18, Matthias Julius wrote:
>>      
>>> "Milenko"<milenko at king-nerd.com>   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 T at H 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 t at h, 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 
t at h 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 t at h 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
> Tilesathome at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tilesathome
>