NGINX Caching

Server NGINX
#1

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:
http://forum.nginx.org/read.php?2,75533,75533#msg-75533

#2

On Thu, Apr 15, 2010 at 5:32 PM, cls [email protected] 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:
http://wiki.nginx.org/NginxHttpFcgiModule
http://wiki.nginx.org/NginxModules#HTTP_Proxy

  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

RPM

#3

Hi,

since version 0.7.48 NginX provide caching to :
http://wiki.nginx.org/NginxHttpProxyModule#proxy_cache

Olivier

#4

On Thursday, April 15, 2010, cls [email protected] 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

#5

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

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

#6

On Sun, 2010-04-18 at 21:25 -0500, Ryan M. wrote:

On Thursday, April 15, 2010, cls [email protected] 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

#7

On Sun, Apr 18, 2010 at 10:21 PM, Ryan M. [email protected]
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/

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

#8

On Sunday, April 18, 2010, Cliff W. [email protected] 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

#9

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 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

–
http://www.google.com/search?q=vonage+sucks

#10

On Mon, Apr 19, 2010 at 11:17 AM, Cliff W. [email protected] 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

#11

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

–
http://www.google.com/search?q=vonage+sucks

#12

Python Tornado server is blisteringly fast when set up properly.

#13

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 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

#14

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:
http://forum.nginx.org/read.php?2,4216,176714#msg-176714