different sizes for same php-page returned?

[ts77]

hey there,

I'm just trying out litespeed 2.0RC3.
I'm using it with php via fast-cgi and turck-mmcache and my app is a forum-software.

I enabled compression ... maybe thats the problem?

Here is the situation:
While running with ab (for benchmarking) I see failed requests reported (failed by size), i.e. around 30 requests of 1000. Yeah, I disabled hardlimit/softlimit and the pages don't change ;-).
If I look at the access-logs the different size is logged there too, i.e. 3002 instead of 2976 bytes or similar small differences.
That makes me curious about the accuracy of the compression.

Any ideas?

BTW. another question: would I see any performance increase in this configuration with the Professional-version as the most load is on the fast-cgi/php-side?


TIA,

thomas

 

[mistwang]

Thomas,

That's normal, lsws compress the response body on the fly, the result may vary due to the timing when response was received from PHP fast cgi, it will not cause any problem in real world usage.

would I see any performance increase in this configuration with the Professional-version as the most load is on the fast-cgi/php-side?

You definitely will see performance increases, but how big the increase is depends on your php side, the faster your php code runs, the bigger increase s you will see. Also, you will get better scalability and better protection against DoS attacks. ;-)

Best regards,
George

 

[ts77]

That's normal, lsws compress the response body on the fly, the result may vary due to the timing when response was received from PHP fast cgi, it will not cause any problem in real world usage.

Strange though as I get the same sizes with other webservers ;-).

 

[mistwang]

In order to reduce the latency introduced by the compression layer, LiteSpeed may flush the compression buffer after a big chunk of data being compressed, so it is sensitive to the timing and chunk size of received data.

We believe it is an advantage instead of draw back comparing to other web server's "compress the whole response body then start sending" algorithm. 8)

George