Is mod_php walking on its road?

Server NGINX
1

Hi, all
Does anybody here have a plan or already be writing a nginx
version mod_php that similar with apache’s?
If nobody does, we are try to write one.

regards,

Steve C.
http://www.sina.com

2

Hi,

On Die 23.10.2007 17:02, Steve C. wrote:

Hi, all
Does anybody here have a plan or already be writing a nginx version
mod_php that similar with apache’s? If nobody does, we are try to
write one.

Due the fact that nginx have fastcgi why do you think that this is
necessary?!

Cheers

Aleks

3

Worse than that. As requests per second grow nginx’ performance will
then degrade because the entire server would be blocked.

Use PHP over fastcgi for optimum performance. If you want to hurt
performance, write a php module.

4

On Tue, Oct 23, 2007 at 05:02:09PM +0800, Steve C. wrote:

Does anybody here have a plan or already be writing a nginx

version mod_php that similar with apache’s?
If nobody does, we are try to write one.

I do not think that built-in nginx PHP will be better than Apache’s one.
For example, thttpd has PHP support, but all connections are blocked
while PHP processes an request.

5

Igor S. ha scritto:

On Tue, Oct 23, 2007 at 05:02:09PM +0800, Steve C. wrote:

Does anybody here have a plan or already be writing a nginx

version mod_php that similar with apache’s?
If nobody does, we are try to write one.

I do not think that built-in nginx PHP will be better than Apache’s one.
For example, thttpd has PHP support, but all connections are blocked
while PHP processes an request.

It should be possible to run the PHP code in a separate thread.
This is what I’m planning to to with mod_wsgi, in order to support
“legacy” applications.

Here is the idea:

  1. mod_wsgi creates a pipe and register the file descriptor with the
    event module; it also creates a read event
  2. mod_wsgi creates a worker thread (only one thread per worker process)
    where the Python code will be executed
  3. when the request handler is called, mod_wsgi setups the read event,
    dispatches the “job” to the worker thread and returns control to
    Nginx
  4. when the code execution is terminated, the thread writes a character
    to the pipe.
    This will calls an handler in the main thread that will retrieve the
    “job” result, sending it to the client.
    The “job” result is protected with a lock (the worker thread will
    wait until the lock is released by the main thread).

Regards Manlio P.

6

On Tue, Oct 23, 2007 at 11:46:48AM +0200, Manlio P. wrote:

  1. when the request handler is called, mod_wsgi setups the read event,
    dispatches the “job” to the worker thread and returns control to
    Nginx
  2. when the code execution is terminated, the thread writes a character
    to the pipe.
    This will calls an handler in the main thread that will retrieve the
    “job” result, sending it to the client.
    The “job” result is protected with a lock (the worker thread will
    wait until the lock is released by the main thread).

The threads are required thorough programming if you want production
grade server, but not toy.

7

Definitively mod_php isn’t a good solution at all.
I’ve used php as an apache module for a long time and now with ngnix i
turned to a pure cgi solution, the benchmarks with the nginx fastcgi
mode are very similar, but the server doesn’t get bloated at the short
time.
I recommend you to forget mod_php, i think the fastcgi architecture is
more flexible and scalable.

Steve C. escribió:

8

On Tue, Oct 23, 2007 at 07:42:54AM -0200, Alejandro V. wrote:

Definitively mod_php isn’t a good solution at all.
I’ve used php as an apache module for a long time and now with ngnix i
turned to a pure cgi solution, the benchmarks with the nginx fastcgi
mode are very similar, but the server doesn’t get bloated at the short time.
I recommend you to forget mod_php, i think the fastcgi architecture is
more flexible and scalable.

FastCGI support in PHP currently leaves much to be desired.
You may try to use PHP FastCGI Process Manager
http://php-fpm.anight.org/

9

Sorry,all
I made a mistake, nginx is using epoll, so blocked I/O will be a
big problem. The same problem we meet when we write
memcachedb(Google Code Archive - Long-term storage for Google Code Project Hosting.).

10

Igor S. escribió:

FastCGI support in PHP currently leaves much to be desired.
You may try to use PHP FastCGI Process Manager
http://php-fpm.anight.org/

Very interesting project, thanks.

11

Steve C. ha scritto:

Sorry,all
I made a mistake, nginx is using epoll, so blocked I/O will be a
big problem.

Not a “really big” problem, since nginx can use multiple worker
processes.

Of course mod_wsgi should not be used in the “main” http server, but
it should be used “standalone”, as a replacement for a “builtin” server
and behind another nginx proxy if possible.

With Python this is very effective, since all Python http servers are
written in pure Python and use a thread based model.

With PHP the builtin server is written in C, and uses a prefork model
(if I’m right) so I don’t know is a nginx mod_php is worth the effort.

Regards Manlio P.

12

Igor S. ha scritto:

On Tue, Oct 23, 2007 at 11:46:48AM +0200, Manlio P. wrote:

Igor S. ha scritto:

On Tue, Oct 23, 2007 at 05:02:09PM +0800, Steve C. wrote:

[…]

The threads are required thorough programming if you want production
grade server, but not toy.

This is the reason why I’m writing mod_wsgi.

All the pure Python HTTP servers (with the exception of Twisted) are
threads based.
Indeed, I can only consider them as toys (with the exception, again, of
Twisted).

I will add thread support only when I will be sure of what I’m doing.
If possible, I would like to be able to handle threads in the Python
application and not in mod_wsgi.

Regards Manlio P.

13

On 10/23/07, Igor S. [email protected] wrote:

You may try to use PHP FastCGI Process Manager
http://php-fpm.anight.org/

I pointed this website to the PHP developers. The immediate feedback
was that the license (GPL) was a deal breaker since patches to be
accepted to PHP core have to be of the PHP license

The author Andrey doesn’t seem to be willing to reconsider a license
change

Regards, Yusuf

14

On Wed, Oct 24, 2007 at 10:14:19AM +0800, Steve C. wrote:

What about mod_perl?

There is experimenatl ngx_http_perl_module:
http://wiki.codemongers.com/NginxEmbeddedPerlModule

15

I mean, why mod_perl not blocked?

16

What about mod_perl?

17

The doc-page tells for the module below:
“If a Perl module performs protracted operation, (for example DNS
lookups, database queries, etc), then the process that is running the
Perl script is completely tied up for the duration of script. Therefore
embedded Perl scripts should be extremely careful to limit themselves to
short, predictable operations.”

So it blocks too.

thomas

Steve C. schrieb:

18

Igor S. ha scritto:

and
$r->sleep(milliseconds, handler)

Use of $r->has_request_body() you may see here:
http://wiki.codemongers.com/NginxEmbeddedPerlModule

mod_wsgi has a similar feature.
If there is a request body, the handler is called only after the entire
body has been read.

Moreover Python supports generators:

This means that the iteration can be suspended when nginx is busy
sending data.

In a future revision I will had an extension, so that the WSGI
application can voluntarily suspend its execution.

[…]

Manlio P.

19

On Wed, Oct 24, 2007 at 08:22:52AM -0700, Steve C. wrote:

I mean, why mod_perl not blocked?

As it was already said, ngx_http_perl_module of course blocks too.
However, ngx_http_perl_module allows to create call-back handlers
that will be called lately. Currently ngx_http_perl_module support
two such handlers only:

$r->has_request_body(handler)
and
$r->sleep(milliseconds, handler)

Use of $r->has_request_body() you may see here:
http://wiki.codemongers.com/NginxEmbeddedPerlModule