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" <[email protected]> > 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" <[email protected]> >> 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" <[email protected]> >>> 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
