What settings for maximum speed on a large configuration ?

[NiteWave]

Static Requests/second :0
Dynamic Requests/second :0
Outbound Bandwidth (bytes/sec):0
Inbound Bandwidth (bytes/sec):0
Connection Soft Limit: very large number
Connection Hard Limit: very large number

will disable the Throttling

[Monarobase]

Hello,

With throttling disabled and keep-alive at zero it still happens

[NiteWave]

1)any improvement regarding the error rate before and after the change?

2)any URL pattern or method(GET or POST) which is easier to trigger the error or just random ?

3)will the same error happen between T-WAF proxy and other web server(apache, nginx etc)?

again, it'll be much helpful if can work out a test case which can easily reproduce the error.

[Monarobase]

1)any improvement regarding the error rate before and after the change?

No yesterday I got 10 errors between 0am and 7 pm
Today I got 9 errors from 0am and 7 pm

2)any URL pattern or method(GET or POST) which is easier to trigger the error or just random ?

It seems random, I don't have many POST requests so it's not likley to happen with a POST request. It happens randomly on images / html / PHP requests. (about 1 for every 1000 requests)

3)will the same error happen between T-WAF proxy and other web server(apache, nginx etc)?

An ASL developper has just told me that they have never seen this issue before and protect nginx servers without issues. Apache servers generaly integrate mod_security directly so they don't need the T-WAF.

again, it'll be much helpful if can work out a test case which can easily reproduce the error

Yes it would, but I've even tried benchmarking (siege) it without managing to create an error. It doesn't seem to happen so much when the server is under more stress.

Apache docs mention a race condition :

http://httpd.apache.org/docs/2.2/en/...roxy_http.html

proxy-initial-not-pooled
If this variable is set no pooled connection will be reused if the client connection is an initial connection. This avoids the "proxy: error reading status line from remote server" error message caused by the race condition that the backend server closed the pooled connection after the connection check by the proxy and before data sent by the proxy reached the backend. It has to be kept in mind that setting this variable downgrades performance, especially with HTTP/1.0 clients.

[NiteWave]

proxy-initial-not-pooled

so can you set the environment variable on T-WAF ?

the frontend and backend litespeed better to set to keep alive
i.e., set litespeed
Max Keep-Alive Requests
to default value

[Monarobase]

so can you set the environment variable on T-WAF ?

I'm giving it a try to see if it makes any difference. I will let you know if it removes the errors.

ASL said I should set the T-WAF (mod_security) to enforce non compressed data because this could cause issues and also prevent mod_security from analysing the data transmitted.

I've given this (disabling compression) a try but it doesn't help either (I still get errors). I think I will activate gzip compression in the T-WAF so it can analyze the data given by litespeed and see what the performance impact is.

I wil reactive keep-alive once I've finished the test with

setEnv proxy-initial-not-pooled 1

[Monarobase]

setEnv proxy-initial-not-pooled 1

solves the problem

I've now got to test compressing with mod_deflate to see how much latency it adds. Otherwise I think I will just tell my customers they can't compress their data.