> > Why you need to check for tileset completness? File format is defined > > to contain offset to all possible tiles followed by tile data (which > > maybe zero length). It's not possible to send incomplete tilesets. > > Right now it is, and many upload single tiles only. It's a significan part of > the upload handler to decide whether it's a complete tileset. > Some need to e.g. split their tilesets in across serveral upload files as > their ISP's proxy only allows small files to be uploaded, apparently.
Is it really many uploads? It seems that only easy way for uploading smaller zips in loop mode is specifying ZipHardLimit parameter, which isn't even mentioned in sample config. Anyway my guess is that combining two big files will still be faster than creating lots of small files. This part should be easy to check by benchmark. > > Btw. Is tilesets unzipping done on hdd or ramdisc? Using ramdisc > > should improve performance a bit without extra effort. > > > It's unzipped to the disk partition where the tiles are. So the final mv to > their end destination is cheap. Unzipping into RAM disk and then moving them > to the partition were equally expensive. We had tried a RAM disk before on > the dev server. This is quite suprising. My test showed that creating and moving 1000 very small files is significatly faster using ramdisc (9 seconds to 15 seconds). Also not all files have to be actually moved, 0, 65 and 67 bytes length files are only instructions to delete tile/create empty land/sea. _______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome
