yep, but neither are the tests wrong nor inaccurate. Those failures happen even with a freshly checkedout kannel-version.... don't believe me => try it yourself.Test doesn't show anything interesting, since it's simply inaccurate or wrong. Have you notice this w/o YAT?: Failed requests: 570 (Connect: 0, Length: 570, Exceptions: 0)
Here is something wrong...
I have run some larger test-sets which seem to be more representative. All tests were run on a machine with a load <= 0.5. I have included the complete results as an attachment, but here is an excerpt:
concurrency-level: 20
---------------------
thread_bench1:Time taken for tests: 43.90294 seconds
thread_bench1:Requests per second: 116.04 [#/sec] (mean)
thread_bench2:Time taken for tests: 39.858602 seconds
thread_bench2:Requests per second: 125.44 [#/sec] (mean)
thread_bench3:Time taken for tests: 395.334556 seconds
thread_bench3:Requests per second: 12.65 [#/sec] (mean)
thread_bench4:Time taken for tests: 23.555762 seconds
thread_bench4:Requests per second: 212.26 [#/sec] (mean)
thread_bench5:Time taken for tests: 22.137040 seconds
thread_bench5:Requests per second: 225.87 [#/sec] (mean)
nothread_bench1:Time taken for tests: 1023.580521 seconds nothread_bench1:Requests per second: 4.88 [#/sec] (mean) nothread_bench2:Time taken for tests: 20.919207 seconds nothread_bench2:Requests per second: 239.01 [#/sec] (mean) nothread_bench3:Time taken for tests: 23.619329 seconds nothread_bench3:Requests per second: 211.69 [#/sec] (mean) nothread_bench4:Time taken for tests: 20.861073 seconds nothread_bench4:Requests per second: 239.68 [#/sec] (mean) nothread_bench5:Time taken for tests: 20.117666 seconds nothread_bench5:Requests per second: 248.54 [#/sec] (mean)
And the second set with a higher bearerbox load: concurrency-level 50 """""""""""""""""""" thread_bench1:Time taken for tests: 21.64724 seconds thread_bench1:Requests per second: 237.36 [#/sec] (mean) thread_bench2:Time taken for tests: 24.483007 seconds thread_bench2:Requests per second: 204.22 [#/sec] (mean) thread_bench3:Time taken for tests: 23.26302 seconds thread_bench3:Requests per second: 217.14 [#/sec] (mean) thread_bench4:Time taken for tests: 20.704621 seconds thread_bench4:Requests per second: 241.49 [#/sec] (mean) thread_bench5:Time taken for tests: 23.460451 seconds thread_bench5:Requests per second: 213.12 [#/sec] (mean)
nothread_bench1:Time taken for tests: 24.10748 seconds nothread_bench1:Requests per second: 208.24 [#/sec] (mean) nothread_bench2:Time taken for tests: 23.452899 seconds nothread_bench2:Requests per second: 213.19 [#/sec] (mean) nothread_bench3:Time taken for tests: 21.690826 seconds nothread_bench3:Requests per second: 230.51 [#/sec] (mean) nothread_bench4:Time taken for tests: 24.950612 seconds nothread_bench4:Requests per second: 200.40 [#/sec] (mean) nothread_bench5:Time taken for tests: 24.702856 seconds nothread_bench5:Requests per second: 202.41 [#/sec] (mean)
As you can see, the difference is ~0.73 in the c20 case and ~1.05 in the c50 case (performance ratio thread vs. no-thread). Thus one can say that performance-wise the no-thread version seems to be as good as (or even better) the threaded-version. BUT I think that the thread solution seems cleaner and easier to maintain then the other one, from an architectural point-of-view.
David
The only choice for it: patch occasionaly remove some bug or perfomance bottleneck from sources.
And can you explain about expected perfomance degradation in YAT aproach.
Do you mean thread's swithing once at 20 seconds? I don't think so.
IMHO kernel switches between threads _realy_ fast, because threads
share the same address space, stack, code, etc.
I agree with you that thread start time is very small (and is to be neglected), but the more threads are running the more expensive is the scheduling (ok, I know, Linux 2.6 has O(1) scheduler ;))...
But the really question is: can we reach the same performance w/o YAT?
and if we can't then yes I am ++1 for YAT! But we should try/test it first...
I remember the time when kannel created new thread for every outgoing http request. And even this worked pretty fast.
Alexander Malysh wrote:
hey, factor 50???? I want see a patch w/o YAT!!! It can't be soooo bad...
On Thursday 27 November 2003 17:24, David Schmitz wrote:
Hi,
your YAT-hatred ;) is well known and understood. See the attachment for some naive benchmarks. Please draw your own conclusions.
Regards, David
Alexander Malysh schrieb:
Hi David/Slava,
as you know, I do not like "yet another thread" (YAT) approach... Would you please try get some benchmark results w/ and w/o YAT, so we can see how is performance w/o YAT affected?
Thanks in advance...
On Thursday 27 November 2003 15:02, David Schmitz wrote:
Hi list,
attached is the IMHO final version of the timeout-patch. I took the thread-approach as discussed with Slava (thanks for your input and help
:)). If there are no objections/corrections I would like to commit the
patch.
Note: configuration of the timeout-values is done in http.h.
Best regards,
David
--
Mit freundlichen Gruessen/Best regards
David Schmitz Softwareentwicklung
----------------------------------------------------------------- Wapme Systems AG Vogelsanger Weg 80 40470 D�sseldorf
Tel.: + 49 -211-7 48 45 - 2708 Fax: + 49 -211-80-6-06-2801
E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de
c20_bench.tgz
Description: GNU Zip compressed data
Description: GNU Zip compressed data
