Am 08.12.2010 15:02, schrieb Grzegorz Nosek:
> It goes to hell by using PHP (or whatever heavy backend) anyway. Nginx
> wins by serving static content extremely fast and by proxying with
> very low overhead. If you use Apache for PHP mostly (I'm not sure
> rewriting URLs to static content is at all popular), you're
> effectively using Apache2+mod_php as a HTTP SAPI for PHP (with built
> in htaccess support). It's more flexible than php_fcgi too (though
> php-fpm offers some more options).
Apache is currently running as mpm-worker with php over fcgi anyway.
> You (usually) only do it once when deploying the app and given the
> typical user you'll get a ticket anyway (teh htaccess is no worky!).
I myself am developing on a apache xampp configuration and testing with
nginx and then documenting setup on nginx and apache. It's true most
apps don't do this because nginx is not that wide spread with hosters at
the moment but I think if nginx would support some things the users need
(or think they need) and this is usable nginx would be used more and
this would be documented more.
And with the tickets it's not that much a problem since I already
informed the users that this will no longer work once I completly
convert all vhosts to nginx (it's planned for the next weeks) and they
should work on that themselves and only submit tickets like "please add
rewrite rule xy" 'cause I will ignore questions like "Y is teh htaccess
not worky?" - Who don't read my mails don't deserves an answer I think.
I'm now suggessting this feature to automate this a little.
> They'd need a way to reload nginx then (looking for htaccess-like
> files upon every request would kill performance). How about deploying
> an Nginx instance per user then?
nginx is reloaded every five minutes by the master cron of froxlor
anyhow so this is not the problem. And everyone using it can just set up
a cron reloading nginx periodically.
Furthermore I didn't mean to have configuration abilities in every file
- just in one file (eg. .custom-config in the root dir or something)
where they cut put their own additional configuration (it's better for
maintrance too I think.
If this would be possible I think the great apps (Wordpress, Joomla etc)
would have documentation on how to setup if using nginx really fast and
the more nginx will be used by hostes the more documentation on that
Deploying more then one instance of nginx isn't really what I think is a
good idea since this would be many in no time (at this point around 50
or 60 )
Also it's working at the moment it's just a pain in the ass to have to
set up this many things for users who just could do this themselves and
then wouldn't need to wait hours until I can change the configuration
and issue a reload (I am not available 24/7 and most people don't
understand this and then complain "How long do you plan on making me
wait?").
> You'd need a very thorough security audit of Nginx code because
> (AFAIR) the setup is done in the master process while still
> potentially running as root, so every vulnerability (in user-supplied
> config files) at that stage equals immediate root. Nginx is written
> far better than most software I've seen so this is less of a concern
> but instead of full privilege separation, you're now this -><- close
> to a compromise.
Therefore I would suggest to only allow directives which don't take you
at risk like location, rewrite, expires... nothing actually changing
directories outside the vhost or something... But I think you are right.
It's kind of risky if it runs as root - which I don't think is a good
method anyway it should run as an unprivileged user like ex. www-data
(as on debian)At the moment the lack of some kind of possibility to add
rewrites etc.
> Apache as a webserver sucks (compared to Nginx) but Apache as an
> application server (mod_* container) isn't that bad.
Maybe true, but nginx is faster even with php-cgi. I tested this with a
Zend application I wrote.
On apache the requests did take up to 5s (about 1.5s on average) and on
nginx the average loading time was about 800ms (0.8s)
I tried with 50 requests each. (The times are a bit high both I think
but the app was still in development and it's Zend Framework so it will
go down when performance will be optimized anyway)
Also I do not like running dual-httpd setups really well because there
are two configs to maintain then. And apache does not support proxying
to a unix socket set (I tried with thin for redmine since I don't like
passenger and I don't liike blocking 4 TCP ports for each thin
application instance.)
So I think nginx is still better then apache even if apache isn't that
bad a application server as you say.
> Best regards,
> Grzegorz Nosek
Best regards,
Pascal Nitsche
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://nginx.org/mailman/listinfo/nginx-devel
