It does not sound right, for file that large, it should be network bandwidth bounded no matter which server is used, even with 1Gb link in our lab.
What is your test environment? What is the CPU utilization when you are testing both servers? Is there any disk I/O intensive application running the server when you were testing?

What is the concurrent level of the the test? For standard edition, it should not go beyond 300 for large file test.

I can test with my own setup but it would be best with a perfect mirror.

Xorlev, there is no bandwidth cap for the standard version of any version for that fact. The 160KB/s limit is the download cap set by us when you download binary packages from litespeedtech.com so people don't crash our bandwidth . =) We need to remove or reword that line so more people don't get confused.

There is no speed "cap"/limit in Standard or any of the LiteSpeed versions. Want to make sure others reading this post are not mistaken. Xorlev is referring to the "download" cap we have set to limit how fast people can download litespeed releases from our website.

Found that it is true Apache can serve large static file a little faster (upto about 30%) than properly configured lsws std.

The reason is Apache uses sendfile() for static file, lsws std just use plain read() or MMAP() + writev(), which is not as efficient as sendfile(). That's the main factor for serving large static file.

For most user it is not a big concern unless you have a Gb connection serving pure static large files. However, our Enterprise edition is highly recommended for this kind of application, it definitely beats Apache on both pure serving speed and scalability.

The sendfile setting within professional does not take effect. If you click on help witin the admin gui, it will detail that sendfile settings is only applied for enterprise licenses.

Please note this "bottleneck" witin std/pro version is only applicable in a bi-directional GigE setup where both the client and server on a GigE connection which is not often the case if at all, in most real world siutations.

On a 100mb/s pipe, you will hit the 9.9MB/s pipe limit before hitting any i/o limit and apache has no advantage what so ever. The same goes to a real-world scenario where you have a much less than GigE interconnect to the internet and your web clients are on a < 10mb/s pipe to the inernet.

I as well have this issue. If the sendfile issue is what is causing this to occur, it is a shame. I'll be forced to switch back to apache, since I just can't afford the price of the enterprise server and the pro does not enable sendfile either.

im still confused how you can claim that the std edition is FASTER than apache when it hands-down is not.

I had to switch back to apache for our http traffic, but i left lsws in place for our ssl traffic and the difference is blatant.
if i wget a 521k file, im getting average thruput here of 314.77K/s with apache. using lsws for the same exact file it goes at 12.07K/s.

With or without sendfile() support in the Standard version of LSWS, your result appears to be out of wack. 12KB/s vs 314KB/s? Not saying your result is wrong, but there appears to be something broken with your configuration.

With that said, Standard Edition of LiteSpeed is not optimized for raw static output due to the advantage of lack of sendfile() support that is available in Enterprise edition. Again, sendfile()'s advantage is not 30X so we need more info to replicate your test result.

Despite all that, the LiteSpeed Standard Edition IS more scalable than Apache given load. Try to compare LiteSpeed, any edition, vs Apache under 200+ requests per second (mix dynamic content and static), and the difference in speed and latency is without questioned.

If you can provide us with more details of your configuration, we can try to see what went wrong with you. Due to possible sensitive info in your configuration, you can email the LiteSpeed xml config files plus Apache config file to bug@litespeedtech.com. Please note the Apache + LiteSpeed version and the size of the the static file from your test.