Hello Fastream,

> pump data to client connection

How do you pump ? Maybe that's the reason of 100% CPU ?

---
Rgds, Wilfried [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
http://www.mestdagh.biz

Sunday, January 29, 2006, 16:37, Fastream Technologies wrote:

> I stopped the timer and it still uses 100%CPU!!! I wonder if this is a
> leftover bug from old betas. The algorithm is this:

> Create a THttpCli in THttpConnection context. Then make them both 
> multithreaded and in the same worker thread. In ondocdata of httpclient,
> pump data to client connection. Check for completeness in 
> ConnectionDataAvailableCleartext of THttpConnection descendent. It's getting
> more strange every day!!! :(((

> Best Regards,

> SZ

> ----- Original Message ----- 
> From: "Francois PIETTE" <[EMAIL PROTECTED]>
> To: "ICS support mailing" <twsocket@elists.org>
> Sent: Sunday, January 29, 2006 4:56 PM
> Subject: Re: [twsocket] THttpConnection throttling problem with timer


>> The problem I see is 100 mS.
>> Just for fun, try with 2000 mS and evaluate the mean bandwidth on a 10 sec
>> period.
>> When it works, you may lower the numbers.
>> --
>> [EMAIL PROTECTED]
>> http://www.overbyte.be
>>
>> ----- Original Message ----- 
>> From: "Fastream Technologies" <[EMAIL PROTECTED]>
>> To: "ICS support mailing" <twsocket@elists.org>
>> Sent: Sunday, January 29, 2006 1:37 PM
>> Subject: Re: [twsocket] THttpConnection throttling problem with timer
>>
>>
>>> Hello,
>>>
>>> Perhaps we should think at the algorithm level. Here it is for your eyes
>>> only: ;)
>>>
>>> I want to throttle bandwidth of my reverse proxy which uses
>>> THttpConnection
>>> and inside it an associated THttpCli.
>>>
>>> Bandwidth and consumed bandwidth is per domain and protected by critical
>>> sections.
>>> There is a serverThread for the listener of THttpServer and there are the
>>> worker threads.
>>>
>>> This is the algorithm:
>>> In the worker thread:
>>> -once a data is sent or received, inc the countOfDataForLast100ms
>>> -every 100ms, a message is passed from the serverThread so that the value
>>> of
>>> countofDataForLast100ms is added to consumedBW
>>>
>>> In the server thread:
>>> -if msecs % 800 == 0
>>> resetConsumedAmount();
>>> resume all paused connections();
>>> -else
>>> for each connection
>>>  if it's not paused
>>>   if the consumed bandwidth has exceeded the total bandwidth in a total
>>> period of 8 secs
>>>    pause();
>>>
>>> Do you see a problem with this algorithm? I cannot but it does not work.
>>> It
>>> has the following problems:
>>> - TryToSend in WSocket consumes 100% CPU
>>> - Bandwidth is not limited much (my test kBps is 100 but it downloads at
>>> 4.2MBps!
>>>
>>> Best Regards,
>>>
>>> SZ
>>>
>>> ----- Original Message ----- 
>>> From: "Francois PIETTE" <[EMAIL PROTECTED]>
>>> To: "ICS support mailing" <twsocket@elists.org>
>>> Sent: Sunday, January 29, 2006 2:02 PM
>>> Subject: Re: [twsocket] THttpConnection throttling problem with timer
>>>
>>>
>>>>>> Not really. Each time I see a TTimer triggered every 100 mSec (or any
>>>>>> very
>>>>>> short time period), I know this will cause CPU problem. And bandwidth
>>>>>> limitation defenitely doesn't require a so short period of time. What
>>>>>> is
>>>>>> useful, regarding bandwidth limitation - is to have bandwidth limited
>>>>>> on
>>>>>> a
>>>>>> reasonable time period (a few second IMO).
>>>>>
>>>>>
>>>>> Francois,
>>>>>
>>>>> I disagree with this ,
>>>>>
>>>>> When a user has a very high bandwidth (100 Mbs), sampling every second
>>>>> is
>>>>> way too slow.
>>>>> I you use 1000 msec sampling period, the throttle does not work work at
>>>>> all.
>>>>> Most likely, all data has been sent before the the throttle becomes
>>>>> active.
>>>>
>>>> Indeed. But nothing will be sent before the pause period has elapsed.
>>>> The
>>>> net effect is the actual bandwidth being limited to the programmed 
>>>> level.
>>>> Of
>>>> course the instantaneous speed is _always_ the line speed. You can't
>>>> slow
>>>> down a packet, it is always sent at wire speed. But you can slow down
>>>> the
>>>> mean bandwidth computed on a given time interval. I pretend this time
>>>> interval should be at least a few seconds. Making this time interval
>>>> shorter
>>>> would impose a high CPU load without significant advantage.
>>>>
>>>> If you don't use persistant connection, then you should probably also
>>>> delay
>>>> the new connection while still in pause period (I'm not sure about the
>>>> pause
>>>> effect when connection is closed. I think it is simply ignored).
>>>>
>>>> --
>>>> [EMAIL PROTECTED]
>>>> http://www.overbyte.be
>>>>
>>>> -- 
>>>> To unsubscribe or change your settings for TWSocket mailing list
>>>> please goto http://www.elists.org/mailman/listinfo/twsocket
>>>> Visit our website at http://www.overbyte.be
>>>
>>> -- 
>>> To unsubscribe or change your settings for TWSocket mailing list
>>> please goto http://www.elists.org/mailman/listinfo/twsocket
>>> Visit our website at http://www.overbyte.be
>>
>> -- 
>> To unsubscribe or change your settings for TWSocket mailing list
>> please goto http://www.elists.org/mailman/listinfo/twsocket
>> Visit our website at http://www.overbyte.be 


-- 
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to