mod_perl with epoll

[Xiao Lan <pr...@gmail.com>]

Hi list,

Apache 2.2 supports the epoll event driver.
Does epoll have any performance improvement to mod_perl application?

Thanks.

Re: mod_perl with epoll

[Xiao Lan <pr...@gmail.com>]

2010/12/5 Torsten Förtsch <to...@gmx.net>:

> I rather think you are asking if an event driven or thread based MPM (like the
> event-MPM) can improve your application.
>

Thanks Torsten.

Yep, I did mean if the event driven MPM as event-MPM can improve the
performance of modperl application.
For threads I never used it under modperl.

Regards.

Re: mod_perl with epoll

[Torsten Förtsch <to...@gmx.net>]

On Saturday, December 04, 2010 16:16:36 Xiao Lan wrote:
> Apache 2.2 supports the epoll event driver.
> Does epoll have any performance improvement to mod_perl application?

I believe you are not asking whether epoll as a device for waiting for 
requests can improve your application since epoll is used even in my prefork 
environment:

$ strace -p 26570
Process 26570 attached - interrupt to quit
semop(7766017, {{0, -1, SEM_UNDO}}, 1)  = 0
epoll_wait(14, {{EPOLLIN, {u32=24080208, u64=24080208}}}, 6, 10000) = 1
accept4(4, {sa_family=AF_INET, sin_port=htons(59505), 
sin_addr=inet_addr("127.0.0.1")}, [16], SOCK_CLOEXEC) = 15
semop(7766017, {{0, 1, SEM_UNDO}}, 1)   = 0
...

I rather think you are asking if an event driven or thread based MPM (like the 
event-MPM) can improve your application.

I doubt it. Here are a few thoughts:

- Modperl in a threaded environment is still quite unstable. Be prepared for 
segfaults.

- In a threaded environment one process uses multiple copies of the perl 
interpreter. That means that RAM that in a multi-process environment can be 
shared by copy-on-write will be allocated to every single interpreter. Hence, 
apache becomes a memory hog this way.

- Further, perl itself if compiled without threads is noticeable faster.

- modperl applications normally spend much time in waiting for databases and 
generating documents dynamically. So a possible gain from a sightly faster 
context switch would hardly be noticeable.

Also, you have to define "performance improvement" more thoroughly:

- do you want to save CPU cycles per request?

- do you want to shorten the time the user has to wait for the answer?

- do you want to maximize the number of concurrent requests your server is 
able to digest?

Certainly there are more aspects to consider.

Torsten Förtsch

-- 
Need professional modperl support? Hire me! (http://foertsch.name)

Like fantasy? http://kabatinte.net