I have read about a technique involving writing to disk a rendered dynamic page and using that when it exists using mod_rewrite. I was thinking about cleaning out the cached version every X minutes using a cron job.
I was wondering if this was a viable option or if there were better alternatives that I am not aware of.
(Note that I'm on a shared machine and mod_cache is not an option.)
You could use your cron job to run the scripts and redirect the output to a file.
If you had a php file index.php, all you would have to do is run
php index.php > (location of static file)
You just have to make sure that your script runs the same on command line as it does served by apache.
I would use a cache on application level. Because the application knows best when the cached version is out of date and is more flexible and powerful in the matter of cache negotiation.
Does the page need to be junked every so often because it just has to? Or should it be paralleled with a static version after an update to the page?
If the latter, you could try and write a script that would make a copy of the just edited page and save it to its static filename version. That should lighten the write load since in that scenario you wouldn't need to have a fresh static copy unless there was a change made that needed some show time.
Related
I have some CGI scripts which are used internal to the organization. Due to some standard changes, the server/system team has commented the below line from httpd.conf (apache config file) that support the CGI scripts. Because of this change, the existing CGI scripts are affected and unable to execute them on browser.
### LoadModule cgid_module modules/mod_cgid.so
Is there a way to overcome this situation and make the scripts work as is.
NOTE : The above commented line cannot be uncommented/enabled.
Ways of circumventing your company's policy, from best to worse:
Load mod_cgi anyway.
Load mod_fcgi, and convert your CGI script into a Fast CGI daemon. It's a lot of work, but you'll can get faster code out of it!
Load your own module that does exactly the same thing as mod_cgi. mod_cgi is open source, so it should be easy to just rename it.
Load mod_fcgi, and write a Fast CGI daemon that executes your script.
Install a second apache web server with mod_cgi enabled. Link to it directly or use mod_proxy on the original server.
Write your own web server. Link to it directly or use mod_proxy on the original server.
Last time you asked this question, you talked about using mod_perl instead. The standard way to run CGI program unchanged (for some value of "unchanged") under mod_perl is by using ModPerl::Registry. Did you try that? How did it go?
Another alternative would be to convert your programs to use PSGI. You could try using Plack::App::Wrap::CGI or CGI::Emulate::PSGI. Using Plack would free you from any deployment restrictions. You could run the code under mod-perl or even as a separate service behind a proxy server.
But I can't help marvelling at how ridiculous this whole situation is. Your company has CGI programs that it (presumably) relies on to run part of its business. And they've just decided to turn off support for them. You need to find out why this decision has been made and try to buy some time in order to convert to an alternative technology.
I've got a little project that uses perl cgi scripts. At this moment I use Apache to run these scripts. I have an index.html file that redirects to a cgi file.
Now I want to make my project 'portable', which means that I want to be able to move the project to another location without the need to configure apache (so not changing the cgi-bin directory in the configuration). The end product would be a script (or html file) that could be opened so that a browser would pop up, just like it would run as it would be using Apache. I actually don't really know where to start.
It's not completely clear what you're asking. But I suspect you're about to find out why PSGI/Plack is such a good idea.
If you write your application to the PSGI interface then you'll be able to just drop it in to any PSGI-enabled web environment (or set up your own lightweight web server using something like Starman).
I am trying to find a way to make sure browsers dont cache versions of my css files everytime I push a new update.
I was thinking the best way would be to somehow get the file timestamp of the css file on the filesytem and append append it tot he css URL somehow like www.mysite.com/css/style.css?13245645434
Is this possible at all? If not, then any idea how i can make sure the browser gets a new version of the file when it is updated? I dont want to eliminate browser cache all together because if the file hasnt been touched then i would like it to be cached. However, when i push a new update i would like to someone tell the browser that.
I understand i can write server side code to put the style.css?2342343 in but i want to see if its possible through apache at all.
Thanks
everytime I push a new update
How do you push updates? If there is an automated build process you have then that is the right place to rewrite your URLs.
If you wanted to do the rewriting via apache you'd need a module which would parse the html and rewrite the links. That would not be optimal.
Lastly, consider rewriting to /css/42/style.css (where 42 is the current version) because in case you cache your site through a proxy or CDN, query parameters may not work.
I am working on a project that processes images, saves the processed images in a cache, and outputs the processed image to the client. Lets say that the project is located in /project/, the cache is located in /project/cache/, and the source images are located wherever else on the server (like in /images/ or /otherproject/images/). I can set up the cache to mirror the path to the source image (e.g. if the source image is /images/image.jpg, the cache for that image could be /project/cache/images/image.jpg), and the requests to the project are roughly /project/path/to/image (e.g. /project/images/image.jpg).
I would like to serve the images from the cache, if they exist, as efficiently as possible. However, I also want to be able to check to see if the source image has changed since the cached image was created. Ideally, this would all be done with mod_rewrite so PHP wouldn't need to be used to do any of the work.
Is this possible? What would the mod_rewrite rules need to be for this to work?
Alternatively, it seems like it would be a fine compromise to have mod_rewrite serve the cached file most of the time but send 1 out of X requests to the PHP script for files that are cached. Is this possible?
You cannot acces the file modification timestamp from the RewriteRule, so there is no way around using PHP or another programming language for that task.
On the other hand this is really simple in PHP, so you should first check whether the PHP solution is good enough in you case. Only if it isn't you should look for alternatives.
What if you used the client to do some of the work? Say you display an image in the web browser and always use src="/cache/images/foobar.jpg" and add an onerror="this.src='/images/foobar.jpg'". In mod_rewrite, send anything that goes to the /images/ dir to a script that will return and generate an image in the cache.
Is there any way to automatically minify static content and then serve it from a cache automatically? Similar to have mod_compress/mod_deflate work? Preferably something I could use in combination with compression (since compression has a more noticeable benefit).
My preference is something that works with lighttpd but I haven't been able to find anything, so any web server that can do it would be interesting.
You can try nginx's third party Strip module:
http://wiki.nginx.org/NginxHttpStripModule
Any module you use is just going to remove whitespace. You'll get a better result by using a minifier that understands whatever you're minifying. e.g. Google's Closure javascript compiler.
It's smart enough to know what a variable is and make it's name shorter. A whitespace remover can't do that.
I'd recommend minifying offline unless your site is very low traffic. But if you want to minify in your live environment I recommend using nginx's proxy cache. (Sorry but I don't have enough reputation to post more than one link)
Or you can look into memcached for an in-memory cache or Redis for the same thing but with disk backup.
I decided to do this through PHP (mostly because I didn't feel like writing a lighttpd module).
My script takes in a query string specifying the type of the files requested (js or css), and then the names of those files. For example, on my site the CSS is added like this:
<link rel="stylesheet" href="concat.php?type=css&style&blue" ... />
This minifies and concatenates style.css and blue.css
It uses JSMin-PHP and cssmin.
It also caches the files using XCache if it's available (since minifying is expensive). I actually plan to change the script so it doesn't minify if Xcache isn't available, but I have Xcache and I got bored.
Anyway, if anyone else wants it, it's here. If you use mine you'll need to change the isAllowed() function to list your files (it may be safe to make it just return true, but it was easy to just list the ones I want to allow).
I use Microsoft Ajax Minifier which comes with a C# library to minify js files. I use that on the server and serve up a maximum of two minified .js files per page (one "static" one that is the same across the whole site, and one "dynamic" one that is specific to just that page).
Yahoo's YUI compressor is also a simple Java .jar file that you could use as well.
The important thing, I think, is not to do it on a file-by-file basis. You really do need to combine the .js files to get the most benefit. For that reason, an "automatic" solution is not really going to work - because it will necessarily only work on a file-by-file basis.
If you use Nginx instead of lighttpd then you can take advantage of Nginx's embedded Perl support to leverage the Perl module JavaScript-Minifier to minify and cache JS server-side.
Here are the details on how to achieve this: wiki.nginx.org/NginxEmbeddedPerlMinifyJS