Gallery2 rewrite rules

[mike]

On Tue, Sep 16, 2008 at 5:10 PM,  <nginx at donsbox.com> 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 :-)
> http://php-fpm.anight.org/docs.html

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)