I want to use mod_disk_cache in apache to cache my xml feeds to a folder and serve direct from that folder.
These are feeds dynamically created by php - but not changing very often.
I want the caching at the htaccess level to avoid any strain/call to php and keep server stress to a minimum.
http://httpd.apache.org/docs/2.2/mod/mod_cache.html
httpd.apache.org/docs/2.2/mod/mod_disk_cache.html
Has anyone done this before? Did it work for you?
I'm getting my server company to install the modules I need and can then have a go myself.
I'm hoping to use something similar to:
<IfModule mod_cache.c>
<IfModule mod_disk_cache.c>
CacheRoot c:/cacheroot
CacheEnable disk /
CacheDirLevels 5
CacheDirLength 3
</IfModule>
</IfModule>
I'll be sending Expires: and Last-Modified: headers in the xml too.
Think this will give me the desired solution and filling that cache folder and avoiding calls to php?
Or is this approach all wrong?
Thanks in advance for any guidance
I used in the past Apache with mod_cache on a Unix environment. It worked fine with low user load, but days with heavy load the system went down all the day.
After some tests we moved to Varnish Cache and now everything works better.
The problem is that only Unix environment is supported, a new varnish windows cygwin-based version exists, but I don't now if is suitable for production environment:
http://varnish-cache.org/trac/wiki/VarnishOnCygwinWindows
It's not a bad thing. I've been using it long time ago. It works.
But you should know there are now really better alternatives when handling caches in front of an apache server. One of theses nice tools is Varnish. You will have very fine tunnings available.
Here's a deep explanation of why varnish is a modern tool and why this new way of using the OS (and not separating memory and disk in spirit) is good : http://www.varnish-cache.org/trac/wiki/ArchitectNotes
About the headers you should use theses headers to communicate with Varnish (or other things, like urls) and let the cache tool handle the final headers.
If you can have a direct access on your server and not just a restricted apache access try it. Now if you can only access apache configuration... but ... c:/cacheroot, you're using a windows server in production? You'll need an Unix-like system for varnish preferably 64bits.
Related
I want to know if my Apache server uses .htaccess files or not. If it uses them, then why and how?
How can I know if my Apache server is using .htaccess or not?
Thank you.
As for why, it's a convenient way for shared-hosting providers to give some access to users who would like to set some configuration options. You obviously wouldn't want everyone to have access to the main configuration file for security purposes. It's also useful for development purposes since you can set different options for different directories.
As for how Apache uses the file, I recommend reading the documentation.
As for how to know if Apache is using .htaccess files, it most likely is. I've yet to meet a shared hosting provider that doesn't. And if you are running your own server, I assume you would know how you set it up. Worst case scenario, you could follow this advice from the docs:
A good test for this is to put garbage in your .htaccess file and reload the page. If a server error is not generated, then you almost certainly have AllowOverride None in effect.
I'm running apache 2.2.24 on Max OS X 10.9.1. Currently, we have a network drive that we access all of our Git repos on at /Volumes/GitWebsites. I would like to configure Apache to serve our PHP based repos from that directory. So, localhost (or 127.0.0.1)/phpsite1/ or /phpsite2? etc. will serve sites from /Volumes/GitWebsites/phpsite1/ or /phpsite2/ in the browser. My two questions are:
Do I simply modify the server root or do I need to use the mod-alias in the httpd.conf file?
What are the permission setting I need to in order for apache to access /Volumes/GitWebsites ?
I've done configuration changes like this in IIS 7.5 and set up a NodeJS dev environment but still new to make large scale changes to Apache. Thanks for any help given.
If you are happy with serving the contents of /Volumes/GitWebsites as it is then it should be fine to point the document root at it. It's also makes it easy to add sites later.
However this could be troublesome later if you want to manage php configuration later on for the sites separately.
I was just doing some testing with YSlow and it's telling me:
Grade F on Compress components with gzip: There are 10 plain text
components that should be sent compressed
I know that Apache 1.3 uses mod_gzip while Apache 2.x uses mod_deflate, and so the easiest solution to remedy this is to use mod_deflate on an Apache 2 server.
However, I've checked with two shared hosting companies and one local company and they've all told me that they don't support mod_deflate.
I know that some older browsers have trouble accepting gzipped / deflated content, and I'm not suggesting it be enabled by default, but are there any negatives for making mod_deflate available? Is it just extra load on the server's processors?
Also, are there any alternatives? I saw that if you are using a CMS like Wordpress you could potentially install a caching plugin which would serve out gzipped cached versions of the pages initially generated via PHP.
Compression takes CPU time. Maybe the hosting company decided they care more about CPU than network traffic. Maybe they offer it with a more expensive package. MAybe they simply didn't add it. Only your hosting company would know.
When using PHP you can check whether your PHP setup has zlib support enabled. If that is the case you can use ob_start("ob_gzhandler"); in code to enable an output buffer which will compress your data or set zlib.output_compression in your php configuration for instance by using php_flag zlib.outout_compression on in your .htaccessfile.
http://php.net/ob_gzhandler
http://php.net/zlib.output-compression
I google on the net and found two approaches to redirect incoming requests to apache in Ubuntu OS: 1) using httpd.conf and 2) using .htaccess.
I am confused. What are the differences between them?
Please share if you know how.
Thank you!
The .htaccess-file is meant to be used on shared servers where you don't have access to the primary Apache config files. It is generally a better idea to use httpd.conf or your site config rather than .htaccess if you can as this has a lower processing overhead (as far as I know, the .htaccess-file is parsed on each request), but both ways work fine.
The webserver hosting my website is not returning last-modified or expiry headers. I would like to rectify this to ensure my web content is cacheable.
I don't have access to the apache config files because the site is hosted on a shared environment that I have no control over. I can however make configurations via an .htaccess file. The server - apache 1.3 - is not configured with mod_expires or mod_headers and the company will not install these for me.
With these limitations in mind, what are my options?
Sorry for the post here. I recognise this question is not strictly a programming question, and more a sys admin question. When serverfault is public I'll make sure I direct questions of this nature there.
What sort of content? If static (HTML, images, CSS), then really the only way to attach headers is via the front-end webserver. I'm surprised the hosting company doesn't have mod_headers enabled, although they might not enable it for .htaccess. It's costing them more bandwidth and CPU (ie, money) to not cache.
If it's dynamic content, then you'll have control when generating the page. This will depend on your language; here's an example for PHP (it's from the PHP manual, and is a bad example, as it should also set the response code):
if (!headers_sent()) {
header('Location: http://www.example.com/');
exit;
}
Oh, and one thing about setting caching headers: don't set them for too long a duration, particularly for CSS and scripts. You may not think you want to change these, but you don't want a broken site while people still have the old content in their browsers. I would recommend maximum cache settings in the 4-8 hour range: good for a single user's session, or a work day, but not much more.