Gallery2 rewrite rules

mike mike503 at
Wed Sep 17 04:42:39 MSD 2008

On Tue, Sep 16, 2008 at 5:10 PM,  <nginx at> wrote:
>> I'm wondering if some of those are even needed.
> They're used by the rewrite module to allow "friendly" URLS.  For example:

Yes I know, but by default a lot of these apps put a lot of excess
rewrite URLs that aren't really needed.

> The rewriting is only to produce human readable, friendly URLs.  PHP
> PathInfo is supported, too, so I can definitely do away with the
> rewrites... but PathInfo is more expensive (and slower), so I was hoping
> to convert the rewrite rules.  Unfortunately, my regex prowess is
> apparently not up to snuff, as I can't make nginx happy.

Pathinfo shouldn't be that bad. I use pathinfo stuff all over and it's
never been the bottleneck as far as I can tell. :)

> What makes php-fpm superior?  The doc is, umm, a bit light :-)

It matures fastcgi inside of PHP, makes it much easier and centrally
controlled to start PHP engines without needing some custom script to
launch a bunch of spawn-fcgi commands; spawn-fcgi has not worked
properly for me in the past (are you sure it's -really- rotating your
processes at PHP_FCGI_MAX_REQUESTS? mine wasn't), php-fpm includes
better process termination/request timeouts, per-pool php.ini
overrides (although php 5.3 will help a lot with that) and works well
in conjunction with nginx... it's too difficult to name them all. I
evaluated a lot of options for PHP engines + adaptive spawning +
ability to run as a user (suexec-ish style) and PHP-FPM meets all of
those (except for adaptive spawning which is one of last remaining
things for it to be feature complete. it's already planned and plumbed
for it)

More information about the nginx mailing list