in reply to Slow SSI

I'll suggest an architectural change... your script does a lot of directory readings, reading of files, randomizing and sorting, and it's doing all of these things on every page hit. How often do you really need to change the image gallery? If you can live with more infrequent updates, have a cron job which does this work and stores the results in a file. Then your SSI just opens this file, reads the image data and generates the HTML.

Even if you have the cron job run once a minute, you are only doing this work once a minute instead of once for every page hit.

Replies are listed 'Best First'.
Re^2: Slow SSI
by Baffled (Acolyte) on Feb 13, 2008 at 20:04 UTC
    Thats actually a really good idea and something totally different than I was expecting. It wouldnt even have to be every minute, more like every 30 would work. I've never made a crone job before, but have heard of it. So this would be a independent script that ran in the background? Would it still be a cgi type of file? Im thinking your talking about splitting this file into two parts and making the search for item part run by crone in the background while the print stuff is called from the html? Or would it still be a ssi?
[reply]
      For minimum modification you would change your SSI from 
      <!--#exec cgi="/cgi-bin/foo.cgi"-->

to 

<!--#include virtual="/cache/latest.html" -->

      [download]

      You would add a command to your crontab like: 

      30 * * * * /www/cgi-bin/foo.cgi > /www/cache/latest.html

      [download]

      All this entry does is run the foo.cgi script once every 30 minutes and pipe the output to the file you are including via your SSI. Naturally you will need to adjust the paths and names to suit. Execute the command once to generate the latest.html include and also ensure that the command works as expected.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom