Search results

If those are from a few IPs, it means that they are trying to flood you server with junk requests, just block them with iptables. You can also reduce the "Max connections per IP" limit to ban them automatically if they try to establish 10+ concurrent connections to the server.

load at 10 -25 with 2000 people online is normal, comparing with load at 300 with Apache, it is a great improvement. Faster CPU could help if there is no idle CPU cycle at peak with your current CPU.

We are looking at the issue, are you using "i386-freebsd" build? i386-freebsd6 package will not work with freebsd5.4

No problem, we can add that feature easily.

It is not a problem of concurrent connections, it is how fast PHP/MySQL driven page can be served. It depends on where is the bottle neck of your application. CPU bound, disk I/O bound, network bound, etc. You need to identify and target the bottle neck. And the bottle neck may change from time...

I think that page is cached, clear your browser cache.

The root route should work well as there is a "/". If you use it in the sub-domain, you need to make sure the sub-domain has "User" or "suexecusergroup" directive in that vhost configuration.

32 bit Linux has 2GB limit in file size, if you need to serve file larger than that, you should use 64bit linux with LSWS x86_64 package.

The problem is on mongrel side. As shown in the strace output, file handle 5 is the reverse proxy connection from LSWS to mongrel. Mongrel read the request, then it closed the connection immediately without sending back anything, then try to close it again with result EBADF, because the file...

Strace output from the process with high CPU utilization should help identifying the problem. If LSWS keep sending the same request to mongrel without getting any valid response back, it probably a issue with mongrel. Have you tried restart mongrels when it heppens? The better solution...

Unfortunately, the I/O scheduler in Linux does not follow the process priority. A I/O intensive task will definitely affect other processes which need to perform disk I/O, even only a little bit. So, it is better to assign dedicate disks for I/O intensive tasks, Have you mount the partition...

The problem has been identified. fix has been added to 3.3 release package.

moved to http://www.litespeedtech.com/how-tos.html#qa_dos

The core dump is created by crashing ruby process, not lshttpd, so it is not controled by the configuration. you need to check the core file with gdb and report the bug to ruby community. gdb /usr/local/bin/ruby <core_file_name> bt

Thanks for the feedback, the wiki has been update. I think the problem you mentioned is the mapping URL, not the "App path". we will have it addressed in 3.3 release.

With Enterprise edition, you can limit the number of requests to dynamic generated content, set it to "1", so those files can be downloaded one by one. It is a better choice to let LiteSpeed serve those files directly.

Can you email us the core files under /tmp/lshttpd/bak_cores/ for analysis? If you are using enterprise, please copy bin/lshttpd.dbg binary in the installation package over to where lshttpd was installed to. The core file created with that binary is useful.

You configuration looks fine. We will verify this problem, if it is a bug, we will have it addressed in up coming 3.3 release.

If you would like, PM me temp login, I can take a quick look at your configuration. To convert back to Apache, just stop LSWS, then start Apache, and take care of the rc script.

How about adding headers['status']="200 OK"