Re: [PATCH] Naive approach to HTTP-timeouts (Final?)

Hi again,

>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...
>  
>
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.
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