Re: web server problem

[Ignatios Souvatzis <is%beverly.kleinbus.org@localhost>]

On Tue, Oct 31, 2000 at 06:51:40AM -0500, baileys wrote:
> Hi,
> 
> >  I have installed thttpd on my A2000 using the packaging
> >  system. (I also installed perl, pico, links, and ssh.)
                                ^^^
I guess used by cgi-scripts?

> >  I then thought that I should test the server before 
> >  putting it on the web. So I installed software to test
> >  the server on another computer that is on the network.
> >  I then tried to test it. I set the test software for 200
> >  parallel connections,

triggering perl cgi-scripts?

> >  After about 30 seconds into the test
> >  the server stopped serving web pages. However, the computer
> >  did not crash.

Hm, my guess is that you did run out of network buffers.
watch "netstat -m" to test, and start with less load. If you hit 
that limit, you should have seen 
"WARNING: mclpool limit reached; increase NMBCLUSTERS";
on the console or in some logfile. You should then add

options NMBCLUSTERS=1024

(as an example) to your kernel configuration file. The default value is
256 on normal, and 512 on "options GATEWAY" kernels.

Besides, if you start cgi-scripts, or if the http-server forks,
you might run into the limit on concurrent processes per userid. 
In csh, "limit maxproc" will show you the default limit. A process can
increase this itself up to the hard limit (which is compiled into the
kernel) using, e.g., the csh builtin command "limit", or the sh command
"ulimit". 

If running perl cgi scripts is really your limitation, you should rather
tell the http daemon to limit concurrent requests. perl5 can be a major
resource (especially memory) pig. I'm not familiar with thttpd, so I can't
advise you on the exact method to use. Read its documentation, there should
be some hint.

> >  ne0 warning: receiver ring buffer overrun

In this case, probably harmless. Some old packets from the test still coming
in before the system enabled the ne0 interupt handling might cause this, or
it might still be in the kernel message buffer from the old boot period.

Regards,
        Ignatios