During a recent site implementation I found myself needing SSL termination, and so put Nginx in front of Varnish to handle the SSL. Afterwards someone pointed out that Apache Traffic Server (http://trafficserver.apache.org/) provides caching proxy services and also handles SSL (and has many other interesting features).
To the best of my knowledge there is no Apache Traffic Server module for Drupal, I would be interested in making one. It seems that much of the requirements would be the same as for Varnish, with the main difference being the cache purging syntax and the handling of drupal / proxy cache communications. With this in mind, it would seem to make sense to move towards a generalised caching proxy module that used submodules to handle the differences between the various caching proxies.
Is moving in this direction of interest to the Varnish module maintainers? Are there any pitfalls you foresee or other reasons why you would recommend keeping caching proxy related modules separate?
Comments
Comment #1
fabsor commentedFor purging, this would certainly be true. Creating a plugin type for doing purging is certainly possible and the Purge module is already doing that and works for a few different proxy servers.
The varnish module is focusing on purging with Varnish right now, but it has the potential of doing a lot more, for instance swapping VCL files and other operations that are Varnish-specific. In the long run I think the Varnish module will move more to being an API for communicating with Varnish and do a lot of things with, and among them is purging, but there is certainly room for more generic implementations that focuses more strictly on doing cache invalidation.
Comment #2
fabsor commentedLooking a bit closer at the Purge module, I realize that it doesn't provide a good way of extending the functionality with support for more servers. One approach would be to create a patch to the purge module that adds support for a new CTools plugin type, called proxy server. The functionality could then be extended easily, both inside the module and by other modules, for instance like this one. I'm moving this issue over to the purge module to see how they feel about that.
Comment #3
beanjammin commentedThanks for following up fabsor, I'll have a closer look at the purge module.
Comment #4
SqyD commentedI'm not familiar with the Apache Traffic Server and the way it supports purging url's from it's caches. I suspect it's not that different from other methodes this module already supports. The current code already has some modularity to support different purge methodes and works quite efficient. I'm not sure if introducing a plugin architecture will not introduce overhead and hinder future code restructuring. Could you explain (or link to) how Apache Traffic Server handles purges?
Comment #5
beanjammin commentedI was unaware of the purge module when I originally posted this to the varnish module's issue queue. It's quite likely that it handles purges similar to what this module already does.
You'll find information on how to purge from the cache near the bottom of this page http://trafficserver.apache.org/docs/v2/admin/cache.htm
Comment #6
SqyD commentedJust read this section in the Apache Traffic Server documentation and this is indeed exactly how this Purge Module works out of the box with the default Varnish/Squid method.
@Beanjammin I would love to hear if this works for you so I can include Apache Traffic Server as a supported reverse proxy cache. Thanks for putting this to my attention.
Comment #7
SqyD commentedI'm just a Varnish guy. If anyone would like to test and confirm to me this is working with Apache Traffic Server I am more then willing to add it as an officially supported proxy. If it turnes out a (few) extra features are needed I am accepting patches but I don't have the time to go and setup a separate reverse proxy. I'm upping this for a 2.x release for now.
Comment #8
japerry