[
https://issues.apache.org/jira/browse/TS-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627287#comment-13627287
]
Leif Hedstrom edited comment on TS-1405 at 4/9/13 11:57 PM:
------------------------------------------------------------
I just tested this, and I still have quite dramatic performance problems. See
the numbers below. One thing to notice is that with the patch, my box can only
use 400% CPU, whereas without it, about 600% (which probably explains some of
the difference). Also notice the much, much higher latency even at much lower
throughput:
Current master:
{code}
http_load -parallel 100 -seconds 60 -keep_alive 100 /tmp/URL
9502994 fetches on 94235 conns, 300 max parallel, 9.502990E+08 bytes, in 60
seconds
100 mean bytes/fetch
158383.2 fetches/sec, 1.583832E+07 bytes/sec
msecs/connect: 0.471 mean, 4.960 max, 0.048 min
msecs/first-response: 1.263 mean, 385.282 max, 0.102 min
{code}
With v11jp.patch
{code}
http_load -parallel 100 -seconds 60 -keep_alive 100 /tmp/URL
6352139 fetches on 63036 conns, 300 max parallel, 6.352130E+08 bytes, in 60
seconds
100 mean bytes/fetch
105869.1 fetches/sec, 1.058691E+07 bytes/sec
msecs/connect: 0.181 mean, 7.087 max, 0.049 min
msecs/first-response: 2.704 mean, 244.925 max, 0.080 min
{code}
was (Author: zwoop):
I just tested this, and I still have quite dramatic performance problems.
See the numbers below. One thing to notice is that with the patch, my box can
only use 400% CPU, whereas without it, about 600% (which probably explains some
of the difference). Also notice the much, much higher latency even at much
lower throughput:
Current master:
{code}
tinkerballa (17:37) 265/0 $ ~/benchit.sh 100 60 100 /tmp/URL
http_load -parallel 100 -seconds 60 -keep_alive 100 /tmp/URL
9502994 fetches on 94235 conns, 300 max parallel, 9.502990E+08 bytes, in 60
seconds
100 mean bytes/fetch
158383.2 fetches/sec, 1.583832E+07 bytes/sec
msecs/connect: 0.471 mean, 4.960 max, 0.048 min
msecs/first-response: 1.263 mean, 385.282 max, 0.102 min
{code}
With v11jp.patch
{code}
http_load -parallel 100 -seconds 60 -keep_alive 100 /tmp/URL
6352139 fetches on 63036 conns, 300 max parallel, 6.352130E+08 bytes, in 60
seconds
100 mean bytes/fetch
105869.1 fetches/sec, 1.058691E+07 bytes/sec
msecs/connect: 0.181 mean, 7.087 max, 0.049 min
msecs/first-response: 2.704 mean, 244.925 max, 0.080 min
{code}
> apply time-wheel scheduler about event system
> ----------------------------------------------
>
> Key: TS-1405
> URL: https://issues.apache.org/jira/browse/TS-1405
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
> Affects Versions: 3.2.0
> Reporter: Bin Chen
> Assignee: Bin Chen
> Fix For: 3.3.2
>
> Attachments: linux_time_wheel.patch, linux_time_wheel_v10jp.patch,
> linux_time_wheel_v11jp.patch, linux_time_wheel_v2.patch,
> linux_time_wheel_v3.patch, linux_time_wheel_v4.patch,
> linux_time_wheel_v5.patch, linux_time_wheel_v6.patch,
> linux_time_wheel_v7.patch, linux_time_wheel_v8.patch,
> linux_time_wheel_v9jp.patch
>
>
> when have more and more event in event system scheduler, it's worse. This is
> the reason why we use inactivecop to handler keepalive. the new scheduler is
> time-wheel. It's have better time complexity(O(1))
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
