Search results

Admin interface use the pre-built PHP binary, so it has the timeout problem. Not sure about the graceful restart problem though, may be some thing wrong with Solairs 10, does it work without chroot? Is your server 64-bit or 32-bit?

This problem will be fixed in 2.1.19

Interesting product. :-) Benchmarked it a little bit, LiteSpeed Enterprise is about 15%-30% faster than Rock on a simple small static file test, for both non-keepalive and keepalive.

OK, we will investigate, thanks for the bug report. In the meantime, please use rewrite rule instead.

We will improve the process manager see if we can come up with a better solution. This kind of attack can be easily fend off with our request rate throttling feature. That's because "ab" cancels the extra requests it sent at the end of the test. If you try "ab -c 1", the child process is alive...

Are you testing this from a browser by clicking "refresh" button quickly and repeatedly? Or using a load testing software like "ab"? The former way may cause what you observed, that because the request has been canceled in the middle, so LSWS has to close the connection on its side before the...

should increase the "Process Soft/Hard limit" to a more reasonable value, like "50-100". "Back log" should be increase to something like "10".

Are you using 2 cpu enterprise? Has "instances" been set to "1", has "Initial request timeout" been set to be greater than the time that the slowest ruby request will take?

because there is no need for reload, litespeed graceful restart does not cause any downtime. :-)

Looks like it is a permission problem, try start the server with "root" user. You probably install litespeed into user A's home directory, while let litespeed run on behalf of user B. User A cannot access configure file owned by user B, so when you start the server as user A, you will get above...

The stock lsphp is 4.4.2, do not use libxml etc. You don't need to statically link to those libs, as you don't need to distribute the binary on different OS environment. do "strip lsphp" will shirk the size of the executable by removing debug symbols, but you better leave them along, just in...

Yes, that's enough. Restart the web server, you should see data/ conf/ subdirectory got created in the working directory, if the web server is able to write to it. Otherwise, double check the premission of the parent directory of the working directory.

Mostly likely is a file/directory permission problem. There might be some logging regard this problem. Turn on debug logging and check error.log.

Thanks, I will add them. Actually, the script tries to copy nss_dns.so.* and nss_files.so.* from /lib/ directory, they are in /usr/lib/ on your server. :-)

Maybe some dll needed for DNS lookups are missing in the chroot jail, you can use ktrace to find out by comparing the system calls from a normal PHP and a jailed PHP from command line.

Is the timeout consistent after it starts to happen? Or randomly? A few tips to identify the problem, set "max connection" to "1", enable debug logging, "ktrace" lsphp and lshttpd when that happened and compare the trace result when it is normal.

Yes, it is out dated. :-)

Sometimes, a persistent mysql connection may hang PHP process and causes various trouble. So we recommend turning it off. You can turn it on if you want to.

The problem is in your lsphp configuration, "Memory soft limit (Bytes)" and "memory hard limit (Bytes)" is too low, should set to "100M" and "150M", by appending a "M". Should work.

I don't think your chroot environment has been configured properly, it is not some thing would work by just setting the chroot path to an arbitrary path without substantial work involved. You need to learn more about setting up a chroot environment manually if you want to chroot at vhost level...