Re: siege failing and so on

-                                                 [email protected]
---------------------------------------------------------------------

<snip>

> So, Dmitry, could you try to run it again with a higher file-max? (echo
> 1000000 > /proc/sys/fs/file-max or something like that) and see if it
> resolves anything.

Yes, I will try it tomorrow. 

I read the book "Linux Socket Programming", Sean Walton, and I have some 
questions within metuxmpm optimisation.

1. It clone many threads inside one process ~ 50 threads. Is it right way to 
serve concurrent requests? In the book, mensioned above, tells that many 
threads or processes result in bad server work: it must switch tasks and it's 
time consuming operation. Sean Walton write that 200 processes on one 
processor is critical value. If number of processes/theads >> than  200, 
processor all its time will waste on switching between tasks. If we have ~ 
100 vhosts * 10 threads = 1000 clones. It's bad!? 

1a.
I set up in httpd.conf
 
StartThreads 1 

On each uid/gid pair it clones at least 3 instances of httpd. If we have ~ 500 
vhosts it results in 1500 clones. What function carries out that instances? 
Can we configure httpd so that it has only one instance on uid/gid pair and 
can clone itself if it nesessary to number of threads <= MaxSpareThreads, and 
cut down itself if it stands idle?

It' is nessesary to do so because on web-hosting providers many vhosts has 
very low number of queries per second. Ususally it's << 1. That hosts do not 
need many threads wasted system resources.

2. How do you think, what loss in perfomance we will get if we will pass all 
data from port 80 through multiplexer into httpd-unix socket? It will be 
about ~10% or more above?
I think, that if we want a really secure web-server,  it's nesessary to filter 
all data from port 80. Keep-alive is an example. 
a) 
Keep-alive on

Even if we assume, that keep-alive in clients can be to only one vhost 
accoding to some standart, nothing prevent hacker to make his own 
"inplementation" of keep-alive. It will be a hole. 

b) If we forbid keep-alive at all, we will lose current apache functionality.
And I think, that even in this case(keep-alive off) we can construct some 
schema to break security, because connection socket passes to vhost-httpd 
process and it close connection. So user can potentially manipulate with 
connection socket.

Best regards,
Dmitry.