--- In PanoToolsNG@yahoogroups.com
, Roger Howard <rogerhoward@...>
> I did something just like this for Zoomify some years ago... it
> raised enough flags on their end that I switched hosts for that
> project to one that didn't care about inode counts. It added a lot
> of CPU load, IIRC, to an otherwise low-load viewer since you had to
> get PHP involved with every tile operation... it also adds a lot of
> additional i/o overhead since there's several extra reads (parsing
> the ZIP header) per tile.
> I played with other approaches - the most obvious is to pre-parse
> each ZIP file and create an index in a database, which holds just
> the file offsets of each tile within the ZIP. Assuming the zip is
> saved without compression (since there's no real benefit) then you
> can unpack files from it pretty quickly with a lot less load with
> simple file reads by byterange than actually using the PHP zip
> libraries for each tile read.
> Depending on your host, you may also consider storing tiles in the
> database - seems stupid, but in many cases there's a lot more
> excess database capacity than storage/inodes and it'd be trivial to
> store each tile in a blob and write a php shim for it.
Thanks for the extra info, we'll see what happens with my host.
The pre-parsing approach is very interesting, I'm definately going to give that a try...