I am using nginx to serve a dynamic (PHP) site, that saves generated
pages
statically for fast serving for anonymous users (Drupal + Boost module).
The expiration of these files is handled by a cron job that deletes
these
files when they are older than 10 minutes. This sounds like a good
scheme,
but on large amounts files, it takes time to go through all the files,
so
files may stay around longer (e.g. an hour).
Is it possible to implement in nginx some directive that will serve a
static
file only if it is recent? Something like:
I am using nginx to serve a dynamic (PHP) site, that saves generated pages
statically for fast serving for anonymous users (Drupal + Boost module).
…
If it is possible to implement it with the existing nginx, I have yet to
find how - if not, well, then this is my feature request
Wouldn’t it be better to just explicitly set Cache-Control headers for
anonymous calls to the dynamic pages, and then let nginx proxy_cache
handle serviing the static pages to anonymous users? That’s the way
Wikipedia does it (with Squid and Apache, not nginx).
Using proxy_cache, you get the same or better performance, and you’re
not generating and handling static versions of files that nobody is
looking for…
(sorry for not replying in place, I did not get your message as email)
On Fri, Dec 18, 2009 at 6:20 AM, Yuval H. wrote:
I am using nginx to serve a dynamic (PHP) site, that saves generated
pages
statically for fast serving for anonymous users (Drupal + Boost module).
…
If it is possible to implement it with the existing nginx, I have yet to
find how - if not, well, then this is my feature request
Wouldn’t it be better to just explicitly set Cache-Control headers for
anonymous calls to the dynamic pages, and then let nginx proxy_cache
handle serviing the static pages to anonymous users? That’s the way
Wikipedia does it (with Squid and Apache, not nginx).
Using proxy_cache, you get the same or better performance, and you’re
not generating and handling static versions of files that nobody is
looking for…
Will this approach work for fcgi too? I am trying to stay apache-free.
Also
the app (Drupal-5 hacked) does not support reverse proxy without careful
patching.
Is there any performance comparison for nginx with fcgi/php vs
apache/mod-
php?
My reasoning was that since I don’t need a full blown web server in the
back, it better just be a php processor, so I went the fcgi route. f
means
fast, doesn’t it?
A lot lof our in-house stuff had similar problems when we first
switched to a layer-7 load balancer, and cleanup was a pain. But the
apps are a lot
more portable and flexible as a result.
Nice thing about nginx is it can behave as a layer 7 load balancer -
for free. Just needs stronger healthchecking (you can do it right now
but it’s kind of manual/scripted/annoying)
Can also do your SSL offloading and decryption at the LB level, so
only install certs on the LB, will try multiple upstreams, can even
make it do all your gzipping if you want
Perfect place to do cache routing too if you desire
Will this approach work for fcgi too? I am trying to stay apache-free.
Also the app (Drupal-5 hacked) does not support reverse proxy without
careful patching.
I think proxy_cache works for fastcgi as well, but I am not positive.
But how? the docs say that proxy_pass is looking for a URL.
If your app doesn’t support reverse proxy, it is probably broken for
many people on the Internet,
That’s true.
Fix Drupal maybe? It is open source
This is already done in the latest version(7), and patches exist for my
(5)
version. However, since it was already pretty hacked when I came along,
patching it is not as easy as running ‘patch -p0’.
Is there any performance comparison for nginx with fcgi/php vs
apache/mod- php?
My reasoning was that since I don’t need a full blown web server in the
back, it better just be a php processor, so I went the fcgi route. f
means fast, doesn’t it?
I think it likely depends more on the perfoance of you fastcgi wrapper
for PHP than the web server. That’s where the bottleneck is usually.
What is a fastcgi wrapper? I am just running /usr/bin/php-cgi…
Will this approach work for fcgi too? I am trying to stay apache-free. Also
the app (Drupal-5 hacked) does not support reverse proxy without careful
patching.
I think proxy_cache works for fastcgi as well, but I am not positive.
We proxy via http to JBoss/Tomcat backend servers in our environment.
If your app doesn’t support reverse proxy, it is probably broken for
many people on the Internet, as it likely is broken in forward proxies
too. Doing some assumptions in redirects or imprperly assuming various
environmentals or the use of mod_php (such as http versus https, or
using hostnames copied from the Host header instead of relative URLs.)
A lot lof our in-house stuff had similar problems when we first
switched to a layer-7 load balancer, and cleanup was a pain. But the
apps are a lot
more portable and flexible as a result.
Fix Drupal maybe? It is open source
Is there any performance comparison for nginx with fcgi/php vs apache/mod-
php?
My reasoning was that since I don’t need a full blown web server in the
back, it better just be a php processor, so I went the fcgi route. f means
fast, doesn’t it?
I think it likely depends more on the perfoance of you fastcgi wrapper
for PHP than the web server. That’s where the bottleneck is usually.
This would suit your needs, along with the try_files directive.
You could also use two “layers” of nginx locations… one location
running fastcgi on localhost an oddball port, and one that does http
proxy_pass to that location with proxy_cache. More connections for
nginx to manage, but they’re all local, and this could be done without
any third-party modules I think.
–
RPM
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
