Search results

it is a memory leak bug. we may need temp root access to figure it out.

You must be using OpenLiteSpeed, those directives are not supported in .htaccess with OpenLiteSpeed.

We will have a new release soon. It sounds like a memory leak somewhere. if you restart it, keeping the current data in /dev/shm, the memory usage starting low and going up gradually? We can login to the server to trouble shoot this, if you want.

Please do grep QUIC /usr/local/apache/logs/error_log send us the output if got a lot errors.

Yes, it is safe to remove those.

Which build of 5.2 are you using?

When I access the site, the second refresh will change the color to green. If there is a failure with QUIC, chrome will remember it and not try QUIC when you refresh. close chrome completely, then start again, chrome will try QUIC again. We need to figure out the invalid ACK issue if it happen...

force refresh, or click a link to reload, the page maybe cached by the browser, you need to press "CTRL" or "SHIFT" to load the page.

chrome remember to use QUIC for a domain for a day or so. The next day, you try access the site, the first request could be in HTTP/2, next request will switch to QUIC protocol.

Looks like google is doing something to the chrome. my chrome's QUIC was disabled all of sudden. You can go to chrome://flags/, change "Experimental QUIC protocol" from "Default" to "On" . If you use different IP, you need to check "netstat -anp" to make litespeed is listen on UDP <IP>:443 .

Are the working one and the two non working domains using the same IP?

sometimes, you need to close chrome and open again. it remember the last QUIC failure and wont try again.

it usually takes another refresh to let chrome switch from HTTP/2 to QUIC.

Yes, if you are using cPanel, you may need to use the vhost level include file for the custom_log configuration.

I think, at vhost level you can add another custom access log config, using the same log file name to create a combined log file.

How do you benchmark it and come to conclusion that simple-cache is faster?

If you are using "ab " to do the benchmark test, you should use "ab -H 'Accept-Encoding: gzip' ..." to fetch the compress cache data. Internally, litespeed cache every page in compressed format, without that, server need to decompress the compressed cache for each request.

Please update the latest build of 5.2, currently build 4, with command /usr/local/lsws/admin/misc/lsup.sh -f -v 5.2 Please install gdb: yum install gdb If the crash continues, we may need to login to your server to figure out the root cause.

Actually, I just uploaded 5.2 build 2, it should fix the crash related to QUIC.

It should work the same way as if Apache is used.