Re: [twsocket] Bandwidth control at the root (TCustomWSocket)
Arno Garrels wrote: > Arno Garrels wrote: > >>> I don't think it could be a problem. But f it does, GetQueueStatus >>> can be called to know if there is a WM_TIMER message already in the >>> queue. > > Did some testing with sending 1000 SendNotifyMessages to the main > thread per second. Then I paused message processing for 10 seconds > by holding the [X] system button pressed. CPU use increased to ~50% > and entire system became very slow, almost non-responsive, I had to > kill the process which took me several minutes while CPU temperature > was in the red area. > > Same test with PostMessage works without this effect however > the queue size is limited (10.000 messages) by default, so any > subsequent call to PostMessage fails, which was a disaster as well. I found an easy workaround, please forget this message. -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Bandwidth control at the root (TCustomWSocket)
Arno Garrels wrote: >> I don't think it could be a problem. But f it does, GetQueueStatus >> can be called to know if there is a WM_TIMER message already in the >> queue. Did some testing with sending 1000 SendNotifyMessages to the main thread per second. Then I paused message processing for 10 seconds by holding the [X] system button pressed. CPU use increased to ~50% and entire system became very slow, almost non-responsive, I had to kill the process which took me several minutes while CPU temperature was in the red area. Same test with PostMessage works without this effect however the queue size is limited (10.000 messages) by default, so any subsequent call to PostMessage fails, which was a disaster as well. > GetQueueStatus returns the status of the calling thread's queue only. > I have not yet found a way to examine the message queue of another > thread, seems impossible. Even the was possible, I think it won't work because of ICS sharing windows :( -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Bandwidth control at the root (TCustomWSocket)
Francois PIETTE wrote: >> What do you think? > > It looks good. > >> However any thread solution cannot behave exactly as a timer since >> it will post the message in any case. WM_TIMER messages however, >> are only sent/posted when the destination message queue is empty. > > I don't think it could be a problem. But f it does, GetQueueStatus > can be called to know if there is a WM_TIMER message already in the > queue. GetQueueStatus returns the status of the calling thread's queue only. I have not yet found a way to examine the message queue of another thread, seems impossible. -- Arno Garrels > > -- > francois.pie...@overbyte.be > The author of the freeware multi-tier middleware MidWare > The author of the freeware Internet Component Suite (ICS) > http://www.overbyte.be > > > - Original Message - > From: "Arno Garrels" > To: "ICS support mailing" > Sent: Monday, July 20, 2009 8:39 PM > Subject: Re: [twsocket] Bandwidth control at the root (TCustomWSocket) > > >> Francois PIETTE wrote: >>>> I'm still not sure what was the best implementation in >>>> TCustomWSocket. Anything speaking against your timer-based code in >>>> HttpProt.pas? Since W2K there are plenty of timers possible. >>> >>> For cilent application, there should be no problem. But for a server >>> application with potentially hundreds or thousands of simultaneous >>> users, a solution with a single timer (whatever it is) would >>> probably preserve system resources. System resources is currently >>> the main limiting factor in the number of concurrent connections. >>> This is why I designed TIcsWndControl in the first place. >> >> I played a bit today and derived a TIcsThreadTimer from TIcsTimer. >> When an instance is created and enabled it subscribes to a so called >> TIcsClock instance which simply runs a loop in its thread and >> SendNotifyMessage WM_TIMER to all subscribers when their interval >> elapsed. >> The number of subscribers(Timers) TIcsClock instance can be set as >> well as the minimum resolution which currently defaults to 100 ticks >> (lazy timer). There's a TIcsClockPool as well. >> >> This solution results in one handle per TIcsClock instance for the >> thread and currently another one for an event to signal thread >> termination. SendNotifyMessage() calls the window procedure directly >> so the message queue won't be flooded. >> >> However any thread solution cannot behave exactly as a timer since >> it will post the message in any case. WM_TIMER messages however, >> are only sent/posted when the destination message queue is empty. >> >> What do you think? >> >> -- >> Arno Garrels >> >> >>> >>> -- >>> francois.pie...@overbyte.be >>> http://www.overbyte.be >> -- >> To unsubscribe or change your settings for TWSocket mailing list >> please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket >> Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Bandwidth control at the root (TCustomWSocket)
What do you think? It looks good. However any thread solution cannot behave exactly as a timer since it will post the message in any case. WM_TIMER messages however, are only sent/posted when the destination message queue is empty. I don't think it could be a problem. But f it does, GetQueueStatus can be called to know if there is a WM_TIMER message already in the queue. -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be - Original Message - From: "Arno Garrels" To: "ICS support mailing" Sent: Monday, July 20, 2009 8:39 PM Subject: Re: [twsocket] Bandwidth control at the root (TCustomWSocket) Francois PIETTE wrote: I'm still not sure what was the best implementation in TCustomWSocket. Anything speaking against your timer-based code in HttpProt.pas? Since W2K there are plenty of timers possible. For cilent application, there should be no problem. But for a server application with potentially hundreds or thousands of simultaneous users, a solution with a single timer (whatever it is) would probably preserve system resources. System resources is currently the main limiting factor in the number of concurrent connections. This is why I designed TIcsWndControl in the first place. I played a bit today and derived a TIcsThreadTimer from TIcsTimer. When an instance is created and enabled it subscribes to a so called TIcsClock instance which simply runs a loop in its thread and SendNotifyMessage WM_TIMER to all subscribers when their interval elapsed. The number of subscribers(Timers) TIcsClock instance can be set as well as the minimum resolution which currently defaults to 100 ticks (lazy timer). There's a TIcsClockPool as well. This solution results in one handle per TIcsClock instance for the thread and currently another one for an event to signal thread termination. SendNotifyMessage() calls the window procedure directly so the message queue won't be flooded. However any thread solution cannot behave exactly as a timer since it will post the message in any case. WM_TIMER messages however, are only sent/posted when the destination message queue is empty. What do you think? -- Arno Garrels -- francois.pie...@overbyte.be http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Bandwidth control at the root (TCustomWSocket)
Francois PIETTE wrote: >> I'm still not sure what was the best implementation in >> TCustomWSocket. Anything speaking against your timer-based code in >> HttpProt.pas? Since W2K there are plenty of timers possible. > > For cilent application, there should be no problem. But for a server > application with potentially hundreds or thousands of simultaneous > users, a solution with a single timer (whatever it is) would probably > preserve system resources. System resources is currently the main > limiting factor in the number of concurrent connections. This is why > I designed TIcsWndControl in the first place. I played a bit today and derived a TIcsThreadTimer from TIcsTimer. When an instance is created and enabled it subscribes to a so called TIcsClock instance which simply runs a loop in its thread and SendNotifyMessage WM_TIMER to all subscribers when their interval elapsed. The number of subscribers(Timers) TIcsClock instance can be set as well as the minimum resolution which currently defaults to 100 ticks (lazy timer). There's a TIcsClockPool as well. This solution results in one handle per TIcsClock instance for the thread and currently another one for an event to signal thread termination. SendNotifyMessage() calls the window procedure directly so the message queue won't be flooded. However any thread solution cannot behave exactly as a timer since it will post the message in any case. WM_TIMER messages however, are only sent/posted when the destination message queue is empty. What do you think? -- Arno Garrels > > -- > francois.pie...@overbyte.be > http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Bandwidth control at the root (TCustomWSocket)
Yeah, I guess so. I had to look LSP - Layered Service Provider... :) I have used it myself to limit some applications bandwidth to a max limit. But it makes sense that it's an LSP-app. -Original Message- > I know that a permanent fix at componentlevel is desired but until > that is sorted out perhaps you would want to use something such as > http://www.netlimiter.com/ to limit the traffic the application uses? Interesting tool, I guess it's a LSP isn't it? -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Bandwidth control at the root (TCustomWSocket)
I'm still not sure what was the best implementation in TCustomWSocket. Anything speaking against your timer-based code in HttpProt.pas? Since W2K there are plenty of timers possible. For cilent application, there should be no problem. But for a server application with potentially hundreds or thousands of simultaneous users, a solution with a single timer (whatever it is) would probably preserve system resources. System resources is currently the main limiting factor in the number of concurrent connections. This is why I designed TIcsWndControl in the first place. -- francois.pie...@overbyte.be http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Bandwidth control at the root (TCustomWSocket)
Francois PIETTE wrote: >> I've got it working without a timer by calling >> MsgWaitForMultipleObjects to defer subsequent call of Resume >> after Pause, however that seems to be a dangerous game. What do >> you thing? > > Not good, the message pump must be called. Do you think it was possible without using a timer? I don't think so. >>> >>> Yes, it is possible and even easy ! >>> You create a thread which sleeps the required time and then post a >>> message. This would be much like a TTimer without an actual TTimer. >> >> OK, but was it cheaper than TIcsTime? > > I have not TIcsTime code in my head... Sorry typo, should read "TIcsTimer". It works like TTimer however does not create a window to receive WM_TIMER messages but uses an existing ICS-window instead. I'm still not sure what was the best implementation in TCustomWSocket. Anything speaking against your timer-based code in HttpProt.pas? Since W2K there are plenty of timers possible. -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Bandwidth control at the root (TCustomWSocket)
Fredrik Larsson wrote: > Hi, > > I know that a permanent fix at componentlevel is desired but until > that is sorted out perhaps you would want to use something such as > http://www.netlimiter.com/ to limit the traffic the application uses? Interesting tool, I guess it's a LSP isn't it? -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Bandwidth control at the root (TCustomWSocket)
I've got it working without a timer by calling MsgWaitForMultipleObjects to defer subsequent call of Resume after Pause, however that seems to be a dangerous game. What do you thing? Not good, the message pump must be called. Do you think it was possible without using a timer? I don't think so. Yes, it is possible and even easy ! You create a thread which sleeps the required time and then post a message. This would be much like a TTimer without an actual TTimer. OK, but was it cheaper than TIcsTime? I have not TIcsTime code in my head... -- francois.pie...@overbyte.be http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Bandwidth control at the root (TCustomWSocket)
Francois PIETTE wrote: I've got it working without a timer by calling MsgWaitForMultipleObjects to defer subsequent call of Resume after Pause, however that seems to be a dangerous game. What do you thing? >>> >>> Not good, the message pump must be called. >> >> Do you think it was possible without using a timer? I don't think so. > > Yes, it is possible and even easy ! > You create a thread which sleeps the required time and then post a > message. This would be much like a TTimer without an actual TTimer. OK, but was it cheaper than TIcsTime? -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Bandwidth control at the root (TCustomWSocket)
I've got it working without a timer by calling MsgWaitForMultipleObjects to defer subsequent call of Resume after Pause, however that seems to be a dangerous game. What do you thing? Not good, the message pump must be called. Do you think it was possible without using a timer? I don't think so. Yes, it is possible and even easy ! You create a thread which sleeps the required time and then post a message. This would be much like a TTimer without an actual TTimer. -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Bandwidth control at the root (TCustomWSocket)
Francois PIETTE wrote: >> I've got it working without a timer by calling >> MsgWaitForMultipleObjects to defer subsequent call of Resume after >> Pause, however that seems to be a dangerous game. What do you thing? > > Not good, the message pump must be called. Do you think it was possible without using a timer? I don't think so. If it was impossible it's probably better to add bandwidth control to the upper level protocol components only, copying existing code from the FTP and HTTP clients? -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Bandwidth control at the root (TCustomWSocket)
Hi, I know that a permanent fix at componentlevel is desired but until that is sorted out perhaps you would want to use something such as http://www.netlimiter.com/ to limit the traffic the application uses? Regards, Fredrik. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Bandwidth control at the root (TCustomWSocket)
I've got it working without a timer by calling MsgWaitForMultipleObjects to defer subsequent call of Resume after Pause, however that seems to be a dangerous game. What do you thing? Not good, the message pump must be called. -- francois.pie...@overbyte.be http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] Bandwidth control at the root (TCustomWSocket)
Hi, I've got it working without a timer by calling MsgWaitForMultipleObjects to defer subsequent call of Resume after Pause, however that seems to be a dangerous game. What do you thing? -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
