# NGINX Caching **URL:** \ **Category:** NGINX\ **Created:** [April 16, 2010, 12:32am UTC](https://www.ruby-forum.com/t/nginx-caching/187033 "2010-04-16T00:32:46Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![cls](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e68b1a/32.png) [@cls](https://www.ruby-forum.com/u/cls)\ **Post date:** [April 16, 2010, 12:32am UTC](https://www.ruby-forum.com/t/nginx-caching/187033/1 "2010-04-16T00:32:46Z")
Hello I’m looking for a web server to serve as a front end reverse proxy for a web application built on mod\_perl Currently I’m using apache and mod\_proxy, but I’m not happy with mod\_proxy’s implementation because it doesn’t provide me any high availability/failover for the backend nodes. I would like an server that can do the following things: 1. serve static assets for my pages (js/css/images/etc…) 2. proxy the page requests back to a mod\_perl app layer for dynamic page generation 3. be “aware” of the health of the app layer nodes so as not to send requests to a node that is down 4. support SSL client connections 5. compress output to clients 6. support named virtual hosts 7. provide URL rewriting 8. runs on linux/centOS 9. and support caching of dynamically generated pages (provided they contain the correct cache headers) I’m not having much luch finding a sever that can peform all of these functions, but it looks like NGINX and lighthttpd are my closest bets. NGINX seems like it will do everything except #9. I can’t find any information in the NGINX documentation that mentions the ability to support caching of pages to prevent full requests from going back to the app layer for every hit. So… two questions 1. Am I missing something? Does NGINX in fact support caching? 2. Is NGINX a good fit for my project give my other requirements? Thanks a lot for your responses. Posted at Nginx Forum: > **[NGINX Caching](https://forum.nginx.org/read.php?2,75533,75533#msg-75533)** > > Hello I'm looking for a web server to serve as a front end reverse proxy for a web application built on mod\_perl Currently I'm using apache and mod\_proxy, but I'm not happy with mod\_proxy's implementation because it doesn't provide me any high... ---
**Author:** ![cls](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e68b1a/32.png) [@cls](https://www.ruby-forum.com/u/cls)\ **Post date:** [April 16, 2010, 12:41am UTC](https://www.ruby-forum.com/t/nginx-caching/187033/2 "2010-04-16T00:41:33Z")
On Thu, Apr 15, 2010 at 5:32 PM, cls [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > 1. Am I missing something? Â Does NGINX in fact support caching? Yes ti does. See fastcgi\_cache and proxy\_cache under the following URLs: > **[GitHub - nginxinc/nginx-wiki: ARCHIVED -- Source for the now archived NGINX Wiki...](https://github.com/nginxinc/nginx-wiki)** > > ARCHIVED -- Source for the now archived NGINX Wiki section of https://www.nginx.com > **[GitHub - nginxinc/nginx-wiki: ARCHIVED -- Source for the now archived NGINX Wiki...](https://github.com/nginxinc/nginx-wiki)** > > ARCHIVED -- Source for the now archived NGINX Wiki section of https://www.nginx.com > 1. Is NGINX a good fit for my project give my other requirements? ## It would seem so. Note than nginx rewrite module is significantly more limited than Apache’s mod\_rewrite. You’ll also want a good fastcgi implementation for your perl stuff, too. The list archives should have some good pointers. Or look here: [http://www.fastcgi.com/drupal/node/5](http://www.fastcgi.com/drupal/node/5) RPM ---
**Author:** ![cls](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e68b1a/32.png) [@cls](https://www.ruby-forum.com/u/cls)\ **Post date:** [April 16, 2010, 12:44am UTC](https://www.ruby-forum.com/t/nginx-caching/187033/3 "2010-04-16T00:44:29Z")
Hi, since version 0.7.48 NginX provide caching to : [http://wiki.nginx.org/NginxHttpProxyModule#proxy\_cache](http://wiki.nginx.org/NginxHttpProxyModule#proxy_cache) Olivier ---
**Author:** ![cls](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e68b1a/32.png) [@cls](https://www.ruby-forum.com/u/cls)\ **Post date:** [April 19, 2010, 4:26am UTC](https://www.ruby-forum.com/t/nginx-caching/187033/4 "2010-04-19T04:26:06Z")
On Thursday, April 15, 2010, cls [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > I’m a little confused by “fastcgi”. Â What are the benefits of using fastcgi as my proxy “protocol” rather than standard HTTP? Most interpreted HTTP servers are slow, single threaded, and generally don’t work great at scale. Not sure about perl, but this is definitely true for Ruby, .net, and others. Or were you just planning on using nginx to proxy to multiple Apache instances that run mod\_perl? That’s widely done, but not exactly lightweight or simple. You keep all the complexity of apache, and add another layer of complexity. Complexity is the natural enemy of security, stability, and performance. – RPM ---
**Author:** ![cls](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e68b1a/32.png) [@cls](https://www.ruby-forum.com/u/cls)\ **Post date:** [April 16, 2010, 12:58am UTC](https://www.ruby-forum.com/t/nginx-caching/187033/5 "2010-04-16T00:58:32Z")
## Ryan M. Wrote: > ## It would seem so. Note than nginx rewrite module is significantly more limited than Apache’s mod\_rewrite. You’ll also want a good fastcgi implementation for your perl stuff, too. The list archives should have some good pointers. Or look here: [http://www.fastcgi.com/drupal/node/5](http://www.fastcgi.com/drupal/node/5) > > RPM I’m a little confused by “fastcgi”. What are the benefits of using fastcgi as my proxy “protocol” rather than standard HTTP? Posted at Nginx Forum: [http://forum.nginx.org/read.php?2,75533,75541#msg-75541](http://forum.nginx.org/read.php?2,75533,75541#msg-75541) ---
**Author:** ![cls](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e68b1a/32.png) [@cls](https://www.ruby-forum.com/u/cls)\ **Post date:** [April 19, 2010, 4:47am UTC](https://www.ruby-forum.com/t/nginx-caching/187033/6 "2010-04-19T04:47:46Z")
On Sun, 2010-04-18 at 21:25 -0500, Ryan M. wrote: > On Thursday, April 15, 2010, cls [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > > I’m a little confused by “fastcgi”. What are the benefits of using > > fastcgi as my proxy “protocol” rather than standard HTTP? > > Most interpreted HTTP servers are slow, single threaded, and generally > don’t work great at scale. Not sure about perl, but this is definitely > true for Ruby, .net, and others. There are plenty of fast HTTP servers written in interpreted languages. In fact, I can not think of a single example that has your described limitations nor what these suggested limitations may have to do with HTTP versus FastCGI. The slowness of the application will matter far more than the protocol used. Regards, Cliff ---
**Author:** ![cls](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e68b1a/32.png) [@cls](https://www.ruby-forum.com/u/cls)\ **Post date:** [April 19, 2010, 3:08pm UTC](https://www.ruby-forum.com/t/nginx-caching/187033/7 "2010-04-19T15:08:50Z")
On Sun, Apr 18, 2010 at 10:21 PM, Ryan M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > There are plenty of fast HTTP servers written in interpreted languages. > > In fact, I can not think of a single example that has your described > > limitations nor what these suggested limitations may have to do with > > HTTP versus FastCGI. Â The slowness of the application will matter far > > more than the protocol used. Anecdotal benchmarks showing FastCGI \> HTTP for Ruby applications: [http://www.openminds.be/blog/2008/03/26/benchmarking-ebb-thin-mongrel-and-fastcgi-for-ruby-on-rails-hosting/](http://www.openminds.be/blog/2008/03/26/benchmarking-ebb-thin-mongrel-and-fastcgi-for-ruby-on-rails-hosting/) Of course, simpler is better, so you should probably minimize change when moving to nginx. Cliff is of course correct: the proxy protocol is the least of your performance worries. If you don’t have or foresee scalability issues, and are comfortable with the performance/limitations/security of whatever back-end HTTP server you’re using for Perl, then stick with that instead of moving to something new and unfamiliar. ## We use nginx as an HTTP proxy in front of IIS and Tomcat at high load, because those two are the amongst the best environments for serving .NET and Java-based web applications respectively. We use FastCGI for our PHP applications. RPM ---
**Author:** ![cls](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e68b1a/32.png) [@cls](https://www.ruby-forum.com/u/cls)\ **Post date:** [April 19, 2010, 5:22am UTC](https://www.ruby-forum.com/t/nginx-caching/187033/8 "2010-04-19T05:22:17Z")
On Sunday, April 18, 2010, Cliff W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > In fact, I can not think of a single example that has your described > limitations nor what these suggested limitations may have to do with > HTTP versus FastCGI. Â The slowness of the application will matter far > more than the protocol used. It’s not the protocol, it is the design. Most dynamic-language web servers I’ve used seem to be focused on being a development sever, and not a production HTTP server. I am thinking of things like Cassini or one if the many Python web servers. Is there a stable, simple perl-based HTTP sever that can handle a lot of concurrent requests? I don’t think such a thing exists for PHP, .NET, or Python, maybe perl is different. – RPM ---
**Author:** ![cls](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e68b1a/32.png) [@cls](https://www.ruby-forum.com/u/cls)\ **Post date:** [April 19, 2010, 6:17pm UTC](https://www.ruby-forum.com/t/nginx-caching/187033/9 "2010-04-19T18:17:57Z")
On Sun, 2010-04-18 at 22:21 -0500, Ryan M. wrote: > > There are plenty of fast HTTP servers written in interpreted languages. > > In fact, I can not think of a single example that has your described > > limitations nor what these suggested limitations may have to do with > > HTTP versus FastCGI. The slowness of the application will matter far > > more than the protocol used. > > It’s not the protocol, it is the design. Most dynamic-language web > servers I’ve used seem to be focused on being a development sever, and > not a production HTTP server. I am thinking of things like Cassini or > one if the many Python web servers. Can you name one of these Python web servers? I’ve only used a few (CherryPy, Tornado, FAPSWS), but these easily handle thousands of requests per second. Some frameworks, like Django and Pylons, come with a “development” server that’s designed for testing, but that is special-purpose software, not some general statement about the capabilities of Python web servers. See [http://nichol.as/benchmark-of-python-web-servers](http://nichol.as/benchmark-of-python-web-servers) for a nice summary of the current breed of Python HTTP servers. Note that some of the servers (notably Tornado and Twisted) don’t perform as well as they could since the benchmarks here are WSGI-oriented and WSGI and async don’t mix well. > Is there a stable, simple perl-based HTTP sever that can handle a lot > of concurrent requests? I don’t think such a thing exists for PHP, > .NET, or Python, maybe perl is different. Python certainly has them. I can’t speak for Perl, PHP, or .NET, but I don’t see any reason it wouldn’t be reasonable to write one. If they don’t exist, I assume the reason would be their long-term integration with larger HTTP servers (Apache, IIS) which would make development of a standalone server appear moot. The key thing to remember here is that a standalone “hello, world” program can easily achieve thousands of requests per second with any of these servers, but the minute you start querying databases, handling sessions, etc, your performance will fall through the floor regardless of whether your use FastCGI or HTTP. If you are basing your scalability planning around FastCGI vs HTTP then you are worrying about the wrong part of the stack. Regards, Cliff – > **[Google Search](https://www.google.com/search?q=vonage+sucks)** ---
**Author:** ![cls](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e68b1a/32.png) [@cls](https://www.ruby-forum.com/u/cls)\ **Post date:** [April 20, 2010, 6:09am UTC](https://www.ruby-forum.com/t/nginx-caching/187033/10 "2010-04-20T06:09:10Z")
On Mon, Apr 19, 2010 at 11:17 AM, Cliff W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Can you name one of these Python web servers? Â I’ve only used a few > (CherryPy, Tornado, FAPSWS), but these easily handle thousands of > requests per second. Â Some frameworks, like Django and Pylons, come > with a “development” server that’s designed for testing, but that is > special-purpose software, not some general statement about the > capabilities of Python web servers. The built-in web server in Python had terrible concurrency behavior in our tests, especially when database calls were involved. Not sure why waiting for a DB response would block or severely hamper other requests, but it certainly seemed to be the case. The other Python development servers were of course not considered. I didn’t look much for other pure-Python servers, as Apache and mod\_wscgi was popular and seemed to be the path of least resistance. I looked a bit at Twisted, but it was clearly too much added complexity for too little gain. > Python certainly has them. Â I can’t speak for Perl, PHP, or .NET, but I > don’t see any reason it wouldn’t be reasonable to write one. Â If they > don’t exist, I assume the reason would be their long-term integration > with larger HTTP servers (Apache, IIS) which would make development of a > standalone server appear moot. Nanoweb exists for PHP, but it actually has to fork to service a PHP request. Go figure. As for .NET, there is no real choice besides IIS except mod\_mono or FastCGI. > The key thing to remember here is that a standalone “hello, world” > program can easily achieve thousands of requests per second with any of > these servers, but the minute you start querying databases, handling > sessions, etc, your performance will fall through the floor regardless > of whether your use FastCGI or HTTP. Â If you are basing your > scalability planning around FastCGI vs HTTP then you are worrying about > the wrong part of the stack. I already agreed with you about the _protocol_ not being an issue. It’s the architecture of the back-end service that matters. In my (admittedly limited experience), all of the dynamic-language HTTP servers I’ve tried have concurrency behavior, and/or require running a bunch of instances to utilize mutli-core hardware because of underlying issues in the language interpreter. I used the imprecise word “slow” to encompass that for the sake of brevity. Managing and monitoring say, two dozen Mongrel instances on one box seems, well, stupid. If you need lots of single-threaded back-end processes, FastCGI is widely supported, has good existing process management tools, and is designed for the task. It’s also probably more manageable as you scale up, which is why I made the suggestion. If scale and performance isn’t a concern, why would the OP ask about load-balancing? – RPM ---
**Author:** ![cls](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e68b1a/32.png) [@cls](https://www.ruby-forum.com/u/cls)\ **Post date:** [April 20, 2010, 6:15pm UTC](https://www.ruby-forum.com/t/nginx-caching/187033/11 "2010-04-20T18:15:41Z")
On Mon, 2010-04-19 at 23:08 -0500, Ryan M. wrote: > waiting for a DB response would block or severely hamper other > requests, but it certainly seemed to be the case. If by “built-in” you are referring to BaseHTTPServer in the standard library, then I am not surprised. First of all, it is single-threaded, so if you have a blocking operation (e.g. accessing a database) then it will not be able to serve any other requests until that operation finishes. If you utilize the ThreadingMixin (or something better), then it can handle concurrent requests. That being said, it’s still quite simplistic and Python’s threading model isn’t the best. If you want real performance you’ll have to look beyond the standard library. Depending on your needs, I’d suggest Tornado (async) or CherryPy (threaded). > > standalone server appear moot. > > of whether your use FastCGI or HTTP. If you are basing your > > Managing and monitoring say, two dozen Mongrel instances on one box > seems, well, stupid. If you need lots of single-threaded back-end > processes, FastCGI is widely supported, has good existing process > management tools, and is designed for the task. It’s also probably > more manageable as you scale up, which is why I made the suggestion. > If scale and performance isn’t a concern, why would the OP ask about > load-balancing? Well, this is a different concern altogether. You made a blanket statement claiming “most interpreted HTTP servers are slow, single threaded, and generally don’t work great at scale”, which I consider patently false. Now you’ve shifted to “FastCGI is easier to manage”. This may be true, depending on your application stack and experience. It may also be more difficult if your stack doesn’t natively support it or requires 3rd party libraries to be integrated. Had the discussion been about a particular application or framework and you claimed that this particular stack was simpler using FastCGI, then I would have probably had no argument (unless I also used that particular stack and felt otherwise, of course). I personally don’t find it difficult to deploy and manage load-balanced HTTP servers (on the contrary, I find them more transparent than FastCGI), but clearly this is going to be a matter of personal preference and experience. Regards, Cliff – > **[Google Search](https://www.google.com/search?q=vonage+sucks)** ---
**Author:** ![cls](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e68b1a/32.png) [@cls](https://www.ruby-forum.com/u/cls)\ **Post date:** [April 21, 2010, 5:40am UTC](https://www.ruby-forum.com/t/nginx-caching/187033/12 "2010-04-21T05:40:04Z")
Python Tornado server is blisteringly fast when set up properly. ---
**Author:** ![cls](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e68b1a/32.png) [@cls](https://www.ruby-forum.com/u/cls)\ **Post date:** [February 20, 2011, 1:19am UTC](https://www.ruby-forum.com/t/nginx-caching/187033/13 "2011-02-20T01:19:44Z")
## john.wang507 Wrote: > Hi, Gabriel , > > Could you help show me some help links on how to > config nginx to reverse proxy youtube videos ? or > may it possibile to show you nginx proxy config to > youtube here ? i tried unblocking using proxy sites > from [http://proxy-zone.net](http://proxy-zone.net) I need my nginx configured to proxy > youtube video for my users who are blocked for > that site. But I have not googled and helpful info > on how to do that. Please help. Yeah or go to google and search for something like “newest proxy sites” Posted at Nginx Forum: [http://forum.nginx.org/read.php?2,4216,176768#msg-176768](http://forum.nginx.org/read.php?2,4216,176768#msg-176768) ---
**Author:** ![cls](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e68b1a/32.png) [@cls](https://www.ruby-forum.com/u/cls)\ **Post date:** [February 20, 2011, 12:40am UTC](https://www.ruby-forum.com/t/nginx-caching/187033/14 "2011-02-20T00:40:37Z")
Hi, Gabriel , Could you help show me some help links on how to config nginx to reverse proxy youtube videos ? or may it possibile to show you nginx proxy config to youtube here ? I need my nginx configured to proxy youtube video for my users who are blocked for that site. But I have not googled and helpful info on how to do that. Please help. Posted at Nginx Forum: > **[Re: nginx caching](https://forum.nginx.org/read.php?2,4216,176714#msg-176714)** > > Hi, I've been using nginx for a while now to proxy flv videos via youtube, to good effect. However, the site that I'm accessing to proxy videos, I'm having problems being able to access their site in bulk, so I've decided to start caching things...