On Sun, 28 Mar 2010 11:04:04 +0200, Patrick Kilian <[email protected]> wrote: > Hi all, > > >> "* Server load too high, unlikely we can upload after rendering, waiting > >> 30s.." > > Not sure under which condition Clients would see that, but there is no > > restriction on the upload for the server, so I am not sure this error > > message is correct on the client side.
Ahh, right. Thanks for the reminder :-). Sergiusz, the real underlying issue is not CPU "load", but simply that the upload happen quicker than the server is processing them. Uploading involves unzipping the zip file, creating a tileset file from it, putting it at the correct location, and to update the Request database. I guess the biggest improvment (besides exponential waiting on the client side, which Patrick mentioned and which I thought is implemented), would be to create the tileset files on the client side and upload them, so the server does not have to unzip and create a tileset file. There is actually code in the client to do that. And I believe there is even code in the server already to handle them correctly. But, essentially being untested, it was not turned on by default and has been lingering for a while (as it did not use to be a performance bottleneck). So, checking out the client side tileset file generation and create a few tileset files, uploading them to the server and check the resulting maps with the tile detail url (http://tah.openstreetmap.org/Browse/details/tile/12/2175/1408/) for correctness would be the first thing to do. It might require some more client or server work, but it might actually just work. If it does, we should turn that on, saving the server quite some upload processing. Hope that are enough pointers for now, let me know if you need anything specific from me, Sebastian > The server reports a load value between 0 and 1 via the GoNogoURL URL. > This value is multiplied by 1000 in the client. If the resulting value > is greater then 750, then the client defers the upload. The relevant > code contains the following comment: > But in the end we have to accept that the ~110 active clients (many of > them multicore and quite fast) can render batches of simple prio4 tiles > which are expired by my oldtile script or the oldtile checker faster > then the server can handle the upload. And no removal of code checking > for that condition is going to fix it. All we (might) get is a hung > server drowned in upload requests. _______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/listinfo/tilesathome
