[Tilesathome] Using RAM-drive for ROMA temp tables

[Matthias Julius]

Dirk Stöcker <openstreetmap at dstoecker.de> writes:

> On Tue, 9 Dec 2008, Matthias Julius wrote:
>
>>> 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.
>>
>> I don't think there is anything wrong with T at H dedicated ROMA servers
>> as long it is clear to a potential user that its data is incomplete
>> and meant to be for T at H only.
>>
>> They probably should run behind their own load balancer called
>> roma.tah.openstreetmap.org or so.  And they should include a comment
>> in their data about the fact.
>
> I would not encourage such special handling in cases where the data is so 
> equal to the main API (i.e. I would have no objections for converted data 
> in other formats).
>
> One of the problems is that future is not really predictable and it is 
> much better to have an open interface compared to a short-term speedup.
> It is already a bad idea that created_by is skipped in XAPI. Don't make 
> the same problems with ROMA.

One certainly has to be careful.  And the filter rules would need to
be documented.

>
> If on the other hand a standard interface can be established, so that 
> e.g. the server is faster when a "strip-xxx" request is done, but a 
> non-stripped request can be delivered nevertheless (as default) I would 
> say this could be a fine solution.

The goal here is to make the database faster by limiting the amount of
data that is stored in there.  So if a server only supports the
"strip-xxx" request and no regular request it can do no harm.

Matthias