Avoid Custom mod_rewrite Rules with Varnish

When you are working on a website project running PHP on Apache, and you need to redirect a single device type to a different URL than the rest of your visitors, I’m sure the first thought that many of you would have is to utilize Apache’s mod_rewrite. It is a highly flexible URL rewriting engine that would allow you to rewrite with almost any combination of requirements to a just as complex set of URLs depending on the situation.

However, if you utilize a caching solution like Varnish, then this may not be a desirable solution. Lets say that that one device visits the url http://www.example.com/something/special and it causes a cache-miss. As a result, Varnish will pass the request on to the Apache web server which detects that you are using the special device, and it rewrites the request to deliver the appropriate special page for the special device. When the Apache web server returns its payload, Varnish takes that as the cacheable value for that specific URL. A few seconds later, a seperate, non-special device visits the page, and instead of getting the non-special payload, it gets the cached version of the special page. The exact opposite scenario could happen just as easily.

This occurs because Varnish’s main goal is to reduce the amount of traffic that makes it to your back-end web server. As a result, your Apache mod_rewrite rules are bypassed many times, rendering them useless when you could have multiple different returned results for the same URL requested.

One of the easiest and simplest ways around this is to move your rewriting of the device or browser specific rewrites into your Varnish configuration files. These support the same regular-expression powered custom rewriting abilities that you have with mod_rewrite, but without the caching layer messing things up.

Always make sure to do your rewriting as close to the client’s browser as possible. It makes things simpler, and can dramatically improve performance.

Tags:

Related Posts

Apr 14, 2014
One minute

Varnish and Magento Performance Mystery

One of the things that you think you will solve when you implement a Varnish caching server in front of a Magento website is performance problems. However, this is not necessarily the case.

When I set Varnish up to cache content in front of my Magento website, I get what seems to be much improved performance. If I run a few tests in the developer tools of Chrome, it seems that the waterfall chart makes sense and the data is loaded appropriately and in a timely manner with the main HTML being downloaded in about 300ms.

#magento #varnish #performance
Read More
Apr 23, 2014
2 minutes

Magento appending __SID to URLs

When trying to fully optimize a Magento website to run as fast as possible, I tend to opt for turning on all of the caching options in Magento, and then put the Varnish caching server in front of the web server with the Turpentine plugin. However, when you do this with some configurations, you start seeing the __SID query string parameter added to the end of the site’s url. Unfortunately, when the Turpentine plugin sees the __SID query string in the URL, it means that this page request will bypass the cache and load it directly from the server, slowing things down.

#cache #varnish
Read More
Mar 29, 2014
2 minutes

301 Redirecting in Varnish

In Magento, you can set your secure and non-secure URLs explicitly. This works as expected in most cases, but can cause some issues when you have to specify full URLs or need to make any AJAX requests. When using the Nexcess Turpentine extension to enable Magento and Varnish to work together and you wish to only support traffic at www.example.com and not example.com, you would need to enable the setting in the Turpentine module to normalize the host.

#magento #varnish
Read More