We did go to Hostingcon 09

August 28th, 2009

This is a delayed post. Yes, we did go to Hostingcon in DC this year. We first attended it on 07 at Chicago, when LSWS 3.0 released. Last year, we didn’t make it. This year, since in DC so close, we drove down directly.

Because of the conference, we had to delay our 4.0.10 release for a few days. We did not join the last evening session and went back directly to continue working on those 503 errors. Finally, after serveral round of build and test run on end users’ environment, 4.0.10 seems quite stable for now. We feel a little bit relief.

It was great pleasure that we were able to meet some LiteSpeed users there, all are very sharp, young and energetic guys. It’s nice feeling to work together with smart users. Well, I have to say all LiteSpeed users are smart …, they know that by using LiteSpeed actually save a lot for them, not only on support, maintenance, but also worries and sleepless night.

National Harbor has very good facility, still under development. While in DC, most places will have a name with “national”. We did not go around this time, since most places in DC we are pretty familiar. We just went out dining once at a local Thai restaurant, which kind of compensated all other junk food meals. Talking about food, George like Thai food a lot, of course, the best one we like still Chinese food, not American Chinese food, but genuine Chinese food. That’s why we already got our tickets to “Just EAT” on Sept. 21 in NYC – International Chinese Culinary Competition. You can watch them cook and taste at same time. If anyone in metropolitan area like authentic Chinese food, come and join us for fun!

Back to work, we will finish up a few to-dos for 4.0.x, and then will fully focus on 4.1RC2 release. Yes, new features will be added for RC2, but I’ll leave that for later post.

Tags: ,
Posted in Miscellaneous | No Comments »

Going to switch this blog to wordpress

July 29th, 2009

Now it’s time to be more active on this blog site and put more useful stuff here, we decide to switch to wordpress.

Wordpress is easier and more popular than current RoR based Typo. Besides that, wordpress.org and wordpress.com still use LiteSpeed.

One funny site if you need a short break: icanhascheezburger.com

If you like gadgets, you may also like slashgear.com.

They are both LiteSpeed powered wordpress based sites. Some people may get confused by server header, you can read more info here. I guess this may due to no free version of LSLB.

Posted in General | Comments Off

Trouble Shooting for high load php driven site

July 22nd, 2009

Hello, everyone,

Time pasts so fast, it has been over 2 years since last blog post. Now we are back and will use this blog regularly. It’s good way to communicate with each other, as you, LiteSpeed users, may also wonder what we are doing.

Our daily life at LiteSpeed is very busy. Trouble shooting problematic server is a routine: if it is LiteSpeed related, we usually will fix it in a day or two and have a pre-release build for a particular client; many times it is not LiteSpeed bug, but configuration/tuning related.

We would like to post here and hopefully benefit others. Back to today’s story, one client report urgently:
> Server Load is very high

> Server configration : Opteron 8350 16 cores , 8gb ram , 300gb SA-SCSI 15.000 RPM .

> Look at top command output : Cpu idle %80 and MYSQL cpu very low %10 because database is a INNODB and very stable optimized.

> But load averega too high. and I can see Litespeed admin console — Realtime Stats too many EAWaitQ process (300-500 )

Logged to that server, did the following steps

  1. Top shows at the moment Server load is 75.
  2. Check what php is busy with.
    • ps -ef | grep php
    • find a php process with long CPU, for e.g. 2767.
    • strace -p 2767
    • from output, it is spending most of time cleaning up session files.
  3. Look at php session files, under /tmp/sess_*, too many cannot be displayed by ls directly.
    • find . | grep sess_ | wc, return count > 190K
    • check df, enough space left on file system.
    • Check phpinfo output, session auto start is off, no problem.
    • Move session path to tempfs:

      create a directory under /dev /shm/phpsess
      modify .htaccess under public_html/ of the problematic client, add php saved path /dev/shm/phpsess

  4. In a few minutes, got session write error.
    • Hit the limit of files that can be created under one directory of tempfs
    • use 2 directory level of php session files. (see details here)
  5. In a few minutes, got error again: “No space left on device”.
    • df -k , only use 1% of file system
    • df  -i, usage is 100%, used up all the inode.
    • Increase the inode limit:
      mount -o remount,nr_inodes=1G /dev/shm
      modify /etc/fstab mount, so next time server reboot will keep the change.
  6. Server load is around 3, no more errors.

Happy Ending for everyone. :)

Note here: strace is also quite useful for trouble shooting php script problem.

Tags: , ,
Posted in Trouble Shooting | Comments Off

Using LiteSpeed Web Server for shared hosting environment

April 19th, 2007

LiteSpeed 3.0 release offer full compatibilities with commonly used web hosting control panels like cPanel, DirectAdmin and Plesk, etc.

We expect LiteSpeed will at least double the server capacity and reduce server load by 5-10 times when Apache was replace, just because of LiteSpeed’s high performance .htaccess implementation alone.

Hosting companies start to take advantage of this now.

[www.mediaLayer.com](http://www.medialayer.com), they even put up a press release [here](http://www.medialayer.com/pr.html).

Also, [www.eleven2.com](http://www.eleven2.com) starts to deploy LiteSpeed Web Server on their shared hosting servers with cPanel.

The feedbacks we got are all positive, pages get loaded faster, reduced memory usage and server load.

One of the feedback we got from one customer of eleven2.com, 30 minutes after the switch, the customer called eleven2, saying “What the crap, our site like a million times faster now!”, that’s a pretty large vBulletin forum. :-)

We expect to hear a lot more feedbacks like this. 8-)

Posted in Web Server | No Comments »

Azureus/Zudeo and LiteSpeed

December 4th, 2006

A new and soon to be released product from LiteSpeed is part of the networking/application foundation for Zudeo. Azureus, the maker of the popular p2p file sharing client has officially lunched their attack on YouTube with Zudeo.

Check out the announcement coverage here:

[http://www.techcrunch.com/2006/12/03/azureus-launches-zudeo/](http://www.techcrunch.com/2006/12/03/azureus-launches-zudeo/)

On behalf of everyone at LiteSpeed, we wish the best for Zudeo.

If you are curious at what new LiteSpeed product Zudeo is using, please stay tuned. What we can say right now is that LiteSpeed is not just a web “server” company a full web “platform” company. Our new product will address the scalable needs for all web 2.0 startups at a decisive price-point that will turn heads.

Tags: ,
Posted in General | No Comments »

LiteSpeed Web Server 3.0 Beta

November 21st, 2006

In tune to our mantra of releasing often and releasing early, here at LiteSpeed we are happy to announce the public beta of our Web Server 3.0 product.

With 3.0 comes major improvements:

*Request Filtering*: compatible with SecFilterSelective directives of mod_security. Our enterprise users have requested this feature and as always, we listen to our customers. You can filtering incoming request data and even inspect the full request body. Security is the heart of any serious web-facing deployment and LiteSpeed is here to cater to the most demanding users.

*IP to GeoLocation* support: full support of all [MaxMind's](http://www.maxmind.com/app/products?rId=litespeedtech) free/commercial GeoIP database products. If you are running an ad server, this feature is indispensable. Select “memory cache” within settings and LiteSpeed will cache IP to Geo lookups to maximize performance and several magnitudes faster than if you have to do it dynamically via an script such as PHP/Ruby.

Revamped Web GUI/Console: we decided it was time to refresh our web administrative interface to improve both Ease Of Use, and performance which now supports up to over 1000+ virtual hosts on a single instance. This is only the foundation of what is to come. Our goal is to have the perfect blend of Ease of Use and Technology. Too many hours are wasted on inefficient interfaces.

64bit support: self-explanatory. LiteSpeed is already extremely memory efficient so going to 64bit has little to do with memory usage but to future proof our product. Within the next 6 months, main-stream 32bit server level CPUs will no longer exist in the market. We will obviously continue our 32bit product line for the millions of 32bit server users out there.

We have also enabled sendfile() support for Standard Edition users.

Test drive 3.0 today and send us your feedbacks!

[More info/download: LiteSpeed Web Server 3.0beta](http://www.litespeedtech.com/support/forum/showthread.php?t=750)

Tags: , ,
Posted in General, Web Server | No Comments »

Power outage trumps holiday

September 4th, 2006

LiteSpeed’s colocation provider lost power for 5 hours very early Thursday morning: hosed electrical feed to the UPS.

In direct response, we relocated our servers to another facility in the same building. The new data-center room has redundant UPS and Power plus twice the cooling capacity as the previous one.

The relocation didn’t come without cost. LiteSpeed’s site was down for much of late Sunday to late afternoon of Labor Day Monday. We figured anyone who really wanted to visit our site on Labor Day weekend was probably just lost and was a good time to make the move with least impact to our customers.

In summary: Electricity 1, LiteSpeed 0.

Posted in General | No Comments »

Why I don’t believe Ruby FCGI can beat LSAPI (Benchmark Ruby LSAPI vs FCGI)

August 31st, 2006

I simply couldn’t believe it when I saw a benchmark result that FCGI beats LSAPI, because we have spent quite amount of time optimizing our LSAPI protocol and implementation, it is much faster than FastCGI protocol according to our benchmark. Then how much faster LSAPI can be? Here is our benchmark for LSWS Enterprise.

This time we only tested Ruby FCGI and LSAPI alone, just simple CGI scripts, no Rails framework involved.

Our test environment is same as the one used in previous post except that we booted our test server into a non-SMP kernel, so only one CPU is used. Why? Because LSAPI is so fast, our simple test script cannot max out all the CPU power, and there are about 20% idle CPU during the test, while almost all CPU power has been used during FCGI test, only have 0.5-1% idle CPU. When we booted into a non-SMP kernel, only 1 CPU is used, which has been maxed out during both tests, the result should make more sense.

Test scripts:

testlsapi.rb

\#!/usr/local/bin/ruby

require ‘lsapi’

while LSAPI.accept != nil
print “HTTP/1.0 200 OK\r\nContent-type: text/html\r\n\r\nHello, World!\n”
end

testfcgi.rb

\#!/usr/local/bin/ruby
require “fcgi”

FCGI.each {|request|
out = request.out
out.print “Content-Type: text/html\r\n\r\nHello, World!\n”
request.finish
}

Both FCGI and LSAPI has been configured to start 10 instances. Here is the result:

Ruby LSAPI:

$ ab -n 100000 -c 100 http://192.168.0.60:8080/testlsapi
…
Server Software: LiteSpeed
Server Hostname: 192.168.0.60
Server Port: 8080

Document Path: /testlsapi
Document Length: 14 bytes

Concurrency Level: 100
Time taken for tests: 13.600 seconds
Complete requests: 100000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 15300459 bytes
HTML transferred: 1400042 bytes
Requests per second: 7352.94 [#/sec] (mean)
Time per request: 13.60 [ms] (mean)
Time per request: 0.14 [ms] (mean, across all concurrent requests)
Transfer rate: 1125.03 [Kbytes/sec] received

Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.2 0 14
Processing: 6 13 2.9 13 280
Waiting: 1 13 2.9 12 280
Total: 6 13 2.9 13 283

Percentage of the requests served within a certain time (ms)
50% 13
66% 13
75% 13
80% 14
90% 15
95% 17
98% 18
99% 19
100% 283 (last request)

FCGI:

$ab -n 100000 -c 100 http://192.168.0.60:8080/testfcgi
…
Server Software: LiteSpeed
Server Hostname: 192.168.0.60
Server Port: 8080

Document Path: /testfcgi
Document Length: 14 bytes

Concurrency Level: 100
Time taken for tests: 20.069 seconds
Complete requests: 100000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 15300153 bytes
HTML transferred: 1400014 bytes
Requests per second: 4982.81 [#/sec] (mean)
Time per request: 20.07 [ms] (mean)
Time per request: 0.20 [ms] (mean, across all concurrent requests)
Transfer rate: 762.38 [Kbytes/sec] received

Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 3
Processing: 16 19 2.7 18 195
Waiting: 16 19 2.7 18 195
Total: 16 19 2.8 18 195

Percentage of the requests served within a certain time (ms)
50% 18
66% 18
75% 19
80% 20
90% 23
95% 27
98% 27
99% 27
100% 195 (last request)

Ruby LSAPI is about 50% faster than Ruby FCGI for the simple “Hello, World” test.

How about other web servers’ FCGI engine? OK, let’s try the same test with nginx then.

nginx configuration:

…
upstream fcgi {
server unix:/tmp/fcgi1.sock;
server unix:/tmp/fcgi2.sock;
server unix:/tmp/fcgi3.sock;
server unix:/tmp/fcgi4.sock;
server unix:/tmp/fcgi5.sock;
server unix:/tmp/fcgi6.sock;
server unix:/tmp/fcgi7.sock;
server unix:/tmp/fcgi8.sock;
server unix:/tmp/fcgi9.sock;
server unix:/tmp/fcgi0.sock;

}
…
location /testfcgi {
fastcgi_pass fcgi;
include conf/fastcgi_params;
}
…

Result:

$ ab -n 100000 -c 100 http://192.168.0.60:80/testfcgi
…
Server Software: nginx/0.4.0
Server Hostname: 192.168.0.60
Server Port: 80

Document Path: /testfcgi
Document Length: 14 bytes

Concurrency Level: 100
Time taken for tests: 21.317 seconds
Complete requests: 100000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 13500000 bytes
HTML transferred: 1400000 bytes
Requests per second: 4691.09 [#/sec] (mean)
Time per request: 21.32 [ms] (mean)
Time per request: 0.21 [ms] (mean, across all concurrent requests)
Transfer rate: 633.30 [Kbytes/sec] received

Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 6
Processing: 6 21 3.3 20 47
Waiting: 2 20 3.3 19 47
Total: 6 21 3.3 20 47

Percentage of the requests served within a certain time (ms)
50% 20
66% 20
75% 20
80% 20
90% 26
95% 31
98% 31
99% 31
100% 47 (last request)

Don’t believe my test result, try it yourself!

Tags: , , , , ,
Posted in Performance | No Comments »

My Rails Benchmark results: LSWS + LSAPI vs nginx + FCGI

August 31st, 2006

After reading [Scoundrel's blog "Looking for Optimal Solution: Benchmark Results Summary and Findings"](http://blog.kovyrin.net/2006/08/28/ruby-performance-results/), I am pretty surprised that LSWS + LSAPI falls behind. The best performer in his tests is nginx + FCGI. “All right, let me spend some time benchmarking them.” I said to myself.

Here is our test environment:

Server: Dell PowerEdge SC1425

CPU: Dual Intel Xeon 3.0GHz/800MHz FSB/2MB L2 Cache
Memory: 1024MB DDR2 400MHz(2X512MB) ECC DIMM
Hard Drive: 80GB 7200RPM SATA drive
NIC: on board Intel PRO/1000 Gigabit Adapter
Cent OS: CentOS 4.2

Client: Custom Built

Motherboard: MSI K7D
CPU: Dual Athlon MP 2000+/266FSB/256KB L2 Cache
Memory: 1GB PC2100
Hard Drive: 36GB 1000RPM SCSI drive
NIC: Intel PRO/1000 Gigabit
OS: RedHat 8.0/Kernel 2.4.22smp

Benchmark Tool:
ApacheBench (ab) 1.3.33

We found that ab in Apache 2.x is not as fast as that in Apache 1.3.x release.

On the server we installed the latest software packages, they are:
Ruby: 1.8.5
Rails: 1.1.6
Ruby-LSAPI: 1.6
Ruby FCGI: 0.8.7
nginx: 0.4.0
LSWS Enterprise: 2.2

We created a simple “Hello world” application like Scoundrel did, the URL is like
http://192.168.0.60: /hello
We use our easy configuration approach to configure the Rails application with 4 LSAPI worker processes, took me about 1 minute, fire up
ab -n -c http://192.168.0.60:8080/hello

Got:

Server Software: LiteSpeed
Server Hostname: 192.168.0.60
Server Port: 8080

Document Path: /hello
Document Length: 47 bytes

Concurrency Level: 100
Time taken for tests: 26.667 seconds
Complete requests: 10000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 2650360 bytes
HTML transferred: 470000 bytes
Requests per second: 375.00 [#/sec] (mean)
Time per request: 266.67 [ms] (mean)
Time per request: 2.67 [ms] (mean, across all concurrent requests)
Transfer rate: 99.39 [Kbytes/sec] received

Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 3
Processing: 35 265 90.9 246 1730
Waiting: 31 265 90.9 246 1730
Total: 35 265 90.9 246 1730

Percentage of the requests served within a certain time (ms)
50% 246
66% 257
75% 268
80% 275
90% 300
95% 392
98% 658
99% 696
100% 1730 (last request)

Tried a couple times, the result is pretty consistent, all are around 370 rps.

OK, it is nginx’s turn. compile, install and start it. Good, the index page is accessible, it works. Next is to figure out how to configure the Rails FCGI. After digging on the internet for a quite while, finally made it work.

Fist, I need start Rails dispatch.fcgi manually with a FCGI spawning tool, I found that only “cgi-fcgi” coming with FCGI SDK can spawn multiple FCGI instances sharing the same listening socket, which is required for nginx, for this test. I use command

cgi-fcgi -start -connect 127.0.0.1:4001 ./dispatch.fcgi 4

to start 4 instances of dispatch.fcgi, all listen on the same server socket.
OK, dispatch.fcgi started. Before start dispatch.fcgi, I remember to do “export RAILS_ENV=production” to make sure dispatch.fcgi will run in production mode.

What about nginx configured. After some digging, I end up with adding following configuration to the default configuration to make it work.

location /hello {
fastcgi_pass 127.0.0.1:4001;
include conf/fastcgi_params;
}

Clear the session cache directory then fire up:
ab -n -c http://192.168.0.60:8080/hello

Got

Server Software: nginx/0.4.0
Server Hostname: 192.168.0.60
Server Port: 80

Document Path: /hello
Document Length: 47 bytes

Concurrency Level: 100
Time taken for tests: 35.416 seconds
Complete requests: 10000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 2590000 bytes
HTML transferred: 470000 bytes
Requests per second: 282.36 [#/sec] (mean)
Time per request: 354.16 [ms] (mean)
Time per request: 3.54 [ms] (mean, across all concurrent requests)
Transfer rate: 73.13 [Kbytes/sec] received

Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 3
Processing: 8 203 1677.3 20 32021
Waiting: 8 203 1677.2 20 32021
Total: 8 203 1677.4 20 32023

Percentage of the requests served within a certain time (ms)
50% 20
66% 23
75% 26
80% 27
90% 31
95% 43
98% 1170
99% 5857
100% 32023 (last request)

Tried a couple times, the results is not very consistent, falls in the range of 250-330 rps.

OK, let’s try UNIX domain socket hoping for better performance, fire up another group of dispatch.fcgi listening at /tmp/rails.sock, change nginx configuration to

location /hello {
fastcgi_pass unix:/tmp/rails.sock;
include conf/fastcgi_params;
}

Restart nginx, and run ‘ab’

Server Software: nginx/0.4.0
Server Hostname: 192.168.0.60
Server Port: 80

Document Path: /hello
Document Length: 383 bytes

Concurrency Level: 100
Time taken for tests: 17.883 seconds
Complete requests: 10000
Failed requests: 5835
(Connect: 0, Length: 5835, Exceptions: 0)
Broken pipe errors: 0
Non-2xx responses: 4165
Total transferred: 3735375 bytes
HTML transferred: 1869440 bytes
Requests per second: 559.19 [#/sec] (mean)
Time per request: 178.83 [ms] (mean)
Time per request: 1.79 [ms] (mean, across all concurrent requests)
Transfer rate: 208.88 [Kbytes/sec] received

Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.2 0 10
Processing: 5 177 135.9 257 1632
Waiting: 1 177 136.0 257 1631
Total: 5 177 135.8 258 1632

Percentage of the requests served within a certain time (ms)
50% 258
66% 280
75% 295
80% 302
90% 327
95% 345
98% 372
99% 382
100% 1632 (last request)

It looks good at first glance, but when you take a closer look, you will find that there are many failed requests. Tried a couple times, results are similar.

My conclusion is that using UNIX domain socket with nginx is not reliable at all. I think it is because nginx does not pipeline requests like what LSWS does, but attempts to make 100 concurrent connections to upstream, while upstream is only capable of handling 4 concurrent connections when UNIX domain socket is used. Using TCP socket is more reliable as TCP server socket backlog can buffer a few pending connections, but I bet problem will occur when concurrent level is higher than the backlog buffer.

You may think I am biased, may be, because I knew our product inside out and LSWS has been properly tuned for sure, but for nginx, I can only use the default setting without much tuning.

All right, so much for the benchmarking. It is not possible to have a exactly same test environment and configuration for everyone who does benchmark tests, the result may vary dramatically. So, it is better to do your own benchmark before making decisions, I only trust my own results.

———————————-

Update:

I benchmark nginx again using configuration post in Alexey Kovyrin’s comments below, start 4 dispatch.fcgi listening on 4 UNIX domain sockets.

Here are the results:

$ ab -n 10000 -c 100 http://192.168.0.60/hello
This is ApacheBench, Version 1.3d <$Revision: 1.73 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.0.60 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Finished 10000 requests
Server Software: nginx/0.4.0
Server Hostname: 192.168.0.60
Server Port: 80

Document Path: /hello
Document Length: 47 bytes

Concurrency Level: 100
Time taken for tests: 31.128 seconds
Complete requests: 10000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 2590000 bytes
HTML transferred: 470000 bytes
Requests per second: 321.25 [#/sec] (mean)
Time per request: 311.28 [ms] (mean)
Time per request: 3.11 [ms] (mean, across all concurrent requests)
Transfer rate: 83.20 [Kbytes/sec] received

Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.3 0 26
Processing: 5 309 148.4 284 1436
Waiting: 5 309 148.4 284 1436
Total: 5 309 148.4 284 1436

Percentage of the requests served within a certain time (ms)
50% 284
66% 300
75% 313
80% 331
90% 425
95% 456
98% 658
99% 1195
100% 1436 (last request)
$ ab -n 10000 -c 100 http://192.168.0.60/hello
This is ApacheBench, Version 1.3d <$Revision: 1.73 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.0.60 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Finished 10000 requests
Server Software: nginx/0.4.0
Server Hostname: 192.168.0.60
Server Port: 80

Document Path: /hello
Document Length: 47 bytes

Concurrency Level: 100
Time taken for tests: 31.915 seconds
Complete requests: 10000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 2590000 bytes
HTML transferred: 470000 bytes
Requests per second: 313.33 [#/sec] (mean)
Time per request: 319.15 [ms] (mean)
Time per request: 3.19 [ms] (mean, across all concurrent requests)
Transfer rate: 81.15 [Kbytes/sec] received

Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 3
Processing: 5 317 155.1 284 1449
Waiting: 5 317 155.1 284 1449
Total: 5 317 155.0 284 1449

Percentage of the requests served within a certain time (ms)
50% 284
66% 298
75% 312
80% 341
90% 424
95% 465
98% 819
99% 1241
100% 1449 (last request)
$ ab -n 10000 -c 100 http://192.168.0.60/hello
This is ApacheBench, Version 1.3d <$Revision: 1.73 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.0.60 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Finished 10000 requests
Server Software: nginx/0.4.0
Server Hostname: 192.168.0.60
Server Port: 80

Document Path: /hello
Document Length: 47 bytes

Concurrency Level: 100
Time taken for tests: 31.057 seconds
Complete requests: 10000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 2590000 bytes
HTML transferred: 470000 bytes
Requests per second: 321.99 [#/sec] (mean)
Time per request: 310.57 [ms] (mean)
Time per request: 3.11 [ms] (mean, across all concurrent requests)
Transfer rate: 83.40 [Kbytes/sec] received

Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 3
Processing: 8 305 62.2 288 553
Waiting: 5 305 62.2 288 552
Total: 8 305 62.1 288 553

Percentage of the requests served within a certain time (ms)
50% 288
66% 306
75% 317
80% 335
90% 421
95% 437
98% 453
99% 477
100% 553 (last request)

The results is much better than previous test when UNIX domain socket is used, at least there is no failed requests. OK, it should be good for production use in this way. The result is consistent, at about 320 rps.
The best score I got using the TCP socket is about the same, it is still lower than the 370 rps I got with LSWS + LSAPI.

Tags: , , , , , ,
Posted in Performance | No Comments »

Trac SCM how-to and upgraded Live Demos

August 30th, 2006

[Trac](http://trac.edgewall.org/) SCM/Project Management software is one of the most popular Python-based application available today. Many open-source projects are hosting their developement source, bug tracker, and wiki all using a single Trac install. It goes to show how much feature has been crammed into Trac and how well integrated it is with its sub-features.

Frankly, it’s pretty amazing to see how many Trac users there are currently. A year ago, I saw a few Trac installations. Today, it would be strange not to see a Trac install for every 5 software project I come accross.

I just posted a new Trac SCM + FastCGI + LiteSpeed how-to for all the Trac lovers out there and to also illustrate how easy it is to integrate any FastCGI application with LiteSpeed. Trac SCM has been added to our live demos.

Lastly, I have also updated many of the configuration for our LiteSpeed [Live Demos](http://www.litespeedtech.com/products/webserver/demo/). The configurations have been simplified/streamlined, when applicable, so new users get a sense of the shortest-way possible of integrating their their apps with LiteSpeed web server.

Tags: ,
Posted in General | No Comments »

« Older Entries