[Libwebsockets] trouble with external POLL array handling

"Andy Green (林安廸)" andy at warmcat.com
Tue Jan 15 09:17:09 CET 2013


On 15/01/13 13:36, the mail apparently from "Andy Green (林安廸)" included:
> On 15/01/13 02:39, the mail apparently from Edwin van den Oetelaar
> included:
...
>> Percentage of the requests served within a certain time (ms)
>>    50%     22
>>    66%     24
>>    75%     25
>>    80%     27
>>    90%     29
>>    95%     31
>>    98%     33
>>    99%     37
>>   100%   4777 (longest request)
>
> I can reproduce this and I see what's going on, I'll work on some
> improvements now.


Well, I pushed up to d280b6ecb318, however the problem isn't what I 
thought it was.

I rationalized the extpoll server into the main test server sources 
(http://git.libwebsockets.org/cgi-bin/cgit/libwebsockets/commit/?id=a50dd1af40c4cb6add355a1ff7db2637361e650b 
) and broke up the http file sending stuff so it goes through the main 
poll loop for each fragment of the file 
(http://git.libwebsockets.org/cgi-bin/cgit/libwebsockets/commit/?id=d280b6ecb318ba008cb618b510a3e8ae887800c1 
) - I thought that would be something to do with it.

However even with those changes I can reproduce it quite reliably, eg

$ ab -t 100 -n 5000 -c 300 'http://127.0.0.1:7681/'
This is ApacheBench, Version 2.3 <$Revision: 1373084 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 500 requests
Completed 1000 requests
Completed 1500 requests
Completed 2000 requests
Completed 2500 requests
Completed 3000 requests
Completed 3500 requests
Completed 4000 requests
Completed 4500 requests
Completed 5000 requests
Finished 5000 requests


Server Software:        libwebsockets
Server Hostname:        127.0.0.1
Server Port:            7681

Document Path:          /
Document Length:        8447 bytes

Concurrency Level:      300
Time taken for tests:   10.820 seconds
Complete requests:      5000
Failed requests:        0
Write errors:           0
Total transferred:      42680000 bytes
HTML transferred:       42235000 bytes
Requests per second:    462.10 [#/sec] (mean)
Time per request:       649.206 [ms] (mean)
Time per request:       2.164 [ms] (mean, across all concurrent requests)
Transfer rate:          3852.06 [Kbytes/sec] received

Connection Times (ms)
               min  mean[+/-sd] median   max
Connect:        0  143 621.6      0    7019
Processing:   147  304 471.4    240    7390
Waiting:       12  252 474.0    212    7384
Total:        160  447 885.5    241   10171

Percentage of the requests served within a certain time (ms)
   50%    241
   66%    244
   75%    246
   80%    249
   90%    536
   95%   1247
   98%   3250
   99%   4688
  100%  10171 (longest request)

I also noticed that it slowed down a lot according to the number of 
connections... running it with logging, it seems to complete almost 
everything in a rush and then slow right down solving the last few... 
again the worst guy is one of the earliest attempts, since the whole 
test was over in 10.8s, but he found a way to stall for 10.1s.

At any rate the patches are good news in themselves in terms of stopping 
latency for other connections and improving maintainability of extpoll, 
so it's all to the good.

I'll continue to study this later today.

-Andy




More information about the Libwebsockets mailing list