On Tue, Sep 16, 2008 at 5:10 PM, <ngi...@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. :)
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)