On Dec 27, 7:33 pm, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: > > Good point. Not that I am willing to risk it (just using the pdf is not > > such a bad option) but I am wondering if it would make sense to create > > a ramdrive for something like this. if memory is needed, swap would > > happen, which should be better than creating files. > > You mean permanently deprivating your server of it's precious ram than > only temporarily? And so far, swapping has always been the worst thing > to happen for me - whereas mere disk-IO didn't slow _everything_ down. > > You should really check your premises on what is affecting performance, > and what not. And get a faster server... > > Diez
What resources this server is lacking currently? Harddisk space Harddisk bandwidth (the server just wouldn't stop reading/writing at peak times) RAM Network CPU In short, what resource is the most precious and what resources you still have spares? Possible option: * Serve the PDFs directly --> Harddisk space - low, as it's not converted --> Harddisk bandwidth - low, depends on how much its requested --> RAM - low, virtually no RAM usage --> Network - low, depends on how much its requested --> CPU - low, virtually no processing is done --> The simplest to implement, moderate difficulty for users that don't have PDF reader --> Users that don't have a PDF reader might experience difficulties, nowadays most people have Adobe Reader on their computer, and most people at least know about it. Many computers are also preinstalled with a pdf reader. * Preconvert to PNGs, the conversion is done at another computer to not restrain the server --> Harddisk space - High, as file is saved as image file --> Harddisk bandwidth - Moderate, as there are many files and overall are big --> RAM - low, virtually no RAM usage --> Network - Moderate, as the total file served is big --> CPU - Low, virtually no processing is done --> Simple * Serve a precompressed, preconverted PNGs --> Harddisk space - Moderate-high, should be smaller than just PNG --> Harddisk bandwidth - Moderate-High, as files can't be served in chunks --> RAM - Low, Virtually no RAM usage --> Network - High, as files can't be served in chunks --> CPU - Low, virtually no processing is done --> Moderately-Simple --> Might be problem if users don't have unzipper (XP, Vista, and most Linux provides unzipper on default installation, older OSes might not) --> Files can't be served in chunks, users have to download whole zip before opening any * Convert the PDFs to PNG on the fly: --> Harddisk space - Low, take as much as serving direct PDF --> Harddisk bandwidth - Moderate to Low, depending on implementation --> RAM - Moderate, as processing is done, RAM is clearly needed --> Network - Moderate, as the files served as PNG --> CPU - High, complex processing is done on the CPU before the file can be sent to the network --> Complex to implement Seeing these options, I think it is much better to serve the PDFs directly, it's very simple, and very efficient on the server. If you're afraid that not everyone have PDF readers, direct them to Adobe's site or serve the installation files on the server. The installation for the reader is a one-off download, so it should only choke the server for the first several weeks. -- http://mail.python.org/mailman/listinfo/python-list
