Re: siege failing and so on

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

On Sun, Oct 12, 2003 at 08:50:06PM +0400, Dmitry P. Schegolev wrote:

<snip>
> 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!? 

hmm, IIRC on Linux, threads are normal processes, but sharing almost 
evrything but stack and and registers. So it shouldnt make things worse 
using threads instead of separate processes. But MT makes some things
a little bit difficult due shared memory (so locking is required).

<snip>
> 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?
hmm, it normally should normally have one process per uid/gid, which itself
has an listen thread and as many worker threads as required. (if idle, only
the listen thread should exist) ... dont know why you get 3 ones.

> 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.
At this point we should think about an start-on-call mechanism, which 
forks processors as needed. But its a little bit tricky.
For lower amount of users it should not be so dramatic having many
sleeping processes, since they consume almost nothing on linux.

<snip>
> 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. 
We already filter, but only the first request. Further request should be 
received directly from the processor. As long as clients dont try to request
different vhosts over the same tcp link, it shouldnt make any problem.
If a client really does so, an attacker could ptrace its own processor and
wait for a client requesting an other user's vhost.

> 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. 
Well, if the wrong vhost is requested, we simply emit an error (5xx).
We now only have to rely in every sane client, not to request the wrong
vhost over a persistent link.

<snip>
> 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.
What should the user be able to do ? 
He can ptrace his processor and put new code into it, so he can virtually
do evrything thats possible with a the socket. But as long as the client
is sane enough, not requesting foreign vhosts over this link, the attacker
couldnt hurt anybody but himself.

Did I miss something ?


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

 phone:     +49 36207 519931         www:       http://www.metux.de/     
 fax:       +49 36207 519932         email:     [email protected]
 cellphone: +49 174 7066481	     
---------------------------------------------------------------------
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/