Re: [twsocket] Problems writing tester with connection counts
Thanks much. I will look through it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Fastream Technologies Sent: Sunday, August 26, 2007 7:54 AM To: ICS support mailing Subject: Re: [twsocket] Problems writing tester with connection counts One additional note from me: If you use single ICS worker thread for the server, then you won't be able to utilize multiple CPU-cores. That's the same for client as well. To see how we cope with this problem on the client side, see the source of my WebStressTester at http://www.fastream.com/ics/Web%20Stress%20Tester%20SRC.zip It's in BCB2006. Best Regards, SZ -- 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
Re: [twsocket] Problems writing tester with connection counts
Hello, again, Francois. Thanks for the additional input. Please forgive me, I don't mean to be pesty, but I am confused by how I could be reinventing the wheel?!?! Obviously, the challenge with exchanging information via this email format is that I am quite limited as to the scope of detail I can provide. I think the confusion is that I am trying to explain what I am doing in an abbreviated form, which makes it hard to communicate the actual details of the issue. Let me clarify a few things: > As I understand, you are using a single connection to evaluate the time. Actually, the client tester is designed to be run simultaneously on multiple machines, as well as multiple instances on one machine. Yes, this version is single threaded itself and uses one connection. But, obviously, aggregating concurrent connections for a more appropriate result is the goal. I am simply using one single client as a base testing core, but am able to run multiple clients concurrently. This allows me to see the actual and effective performance points in response to seperate client streams on the same CPU, different host, etc. Additionally, just to make sure I am clear, I am not evaluating "the time", but rather various types of lifecycles over a period of time. > What you do in your code between OnClientConnected and the graceful close, > and how you do it will drastically change the results. Fully understanding > how Windows handle messages will help interpreting the results. Therein lies the rub. I do get how messages work in Windows; I have been coding in them back to the Borland C++ OWL framework. That is why I was confused as to why the TWSocket internal messages would own the app's thread manager like it is in my tester, especially when I am not calling ProcessMessages. The test code uses out-of-line messages to prevent this very problem. Inserting ProcessMessages is not a fix, but a test of the symptom. My lack of understanding lies in the TWSocket internals, not in Windows messaging, albeit I imagine that I do not have the grasp of it that you do... :) > And if you use simultaneous connections, using a thread for the processing of each > connection could change the numbers a lot (In both directions !) I agree. The server is built in two modes: One uses a managed thread pool for packet handling, the other uses a single threaded packet handler. By packet, I mean my transport packetizing entities, not IP units. Additionally, the client can be built in either of these two modes as well. These will allow me to compare threaded vs. inline processing. When I ran into this problem, I built both as single threaded handlers, so that I can remove the threading logic from the equation. > You do as you like, but believe me, you are reinventing the wheel. The ClientCount property that you are referring to simply returns the number of concurrent connections and has no cummulative bearing over time. I am confused by your recommendation to use the ClientCount property to determine any of the metrics I am looking for. Perhaps, I am greatly confused, which I guess is possible. But, given your component pattern, I do not see the relevance of this property for my test. I have been building TCP/IP apps for quite a number of years, as well as using your great components for years as well, so I don't think I am a complete newbie. However, I definitely do not want to reinvent the wheel, but I was simply stumped by the simplicity of what I was doing and why I was having a problem with it. I am sure the problem lies in my code, not ICS. Anyway, thanks for the input. Perhaps this explains what I am doing more clearly. I did not mean to take so much of your time or generate so many emails. I was hoping there was a quick, short, illuminating answer to my delimma. I will figure this out. Thanks... Hoby -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Francois PIETTE Sent: Sunday, August 26, 2007 7:49 AM To: ICS support mailing Subject: Re: [twsocket] Problems writing tester with connection counts > However, TWSocketServer does not have what I need for these tests. I am > not > wanting to know concurrent or contiguous client connections. If I was, > then > yes, ClientCount would be sufficient. Rather, I am trying to determine > how > many connection lifecycles can occur over a period of time. This includes > connect, build session (TWSOcketServer) and disconnect. As I understand, you are using a single connection to evaluate the time. This will give a different time tahn if you used several parrallel connections. You must be aware of that. This is because of low level TCP/IP protocol negociation which can take place in parallel for several connections. So having many simultaneous connections result in an overall better result. Setting up a TCP connection and gracefully closing a TCP connection are proc
Re: [twsocket] Problems writing tester with connection counts
One additional note from me: If you use single ICS worker thread for the server, then you won't be able to utilize multiple CPU-cores. That's the same for client as well. To see how we cope with this problem on the client side, see the source of my WebStressTester at http://www.fastream.com/ics/Web%20Stress%20Tester%20SRC.zip It's in BCB2006. Best Regards, SZ - Original Message - From: "Francois PIETTE" <[EMAIL PROTECTED]> To: "ICS support mailing" Sent: Sunday, August 26, 2007 3:49 PM Subject: Re: [twsocket] Problems writing tester with connection counts >> However, TWSocketServer does not have what I need for these tests. I am >> not >> wanting to know concurrent or contiguous client connections. If I was, >> then >> yes, ClientCount would be sufficient. Rather, I am trying to determine >> how >> many connection lifecycles can occur over a period of time. This >> includes >> connect, build session (TWSOcketServer) and disconnect. > > As I understand, you are using a single connection to evaluate the time. > This will give a different time tahn if you used several parrallel > connections. You must be aware of that. This is because of low level > TCP/IP > protocol negociation which can take place in parallel for several > connections. So having many simultaneous connections result in an overall > better result. > > Setting up a TCP connection and gracefully closing a TCP connection are > processes which involve several packets to be exchanged between client and > server. There is a round trip time depending on the hardware and network > you > have. This is why having simultaneous connections will result in a better > global result. Depending on a lot of factors, establishing 10 or 100 > simultaneous connections mays take the same time as establishing only one. > Same for graceful close. > > What you do in your code between OnClientConnected and the graceful close, > and how you do it will drastically change the results. Fully understanding > how Windows handle messages will help interpreting the results. And if you > use simultaneous connections, using a thread for the processing of each > connection could change the numbers a lot (In both directions !). > >> This is not something that TWSocketServer will tell me. Ergo, my test is >> designed to determine this. > > Yes, TWSocketServer will tell you exactly the same thing as what you could > reinvent. TWSocketServer /is/ a TWSocket and instanciate a new TWSocket > for > each incomming connection. You can tell TWSocketServer to use your own > TWSocket derived class. You do as you like, but believe me, you are > reinventing the wheel. > > > -- > [EMAIL PROTECTED] > 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://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
Re: [twsocket] Problems writing tester with connection counts
> However, TWSocketServer does not have what I need for these tests. I am > not > wanting to know concurrent or contiguous client connections. If I was, > then > yes, ClientCount would be sufficient. Rather, I am trying to determine > how > many connection lifecycles can occur over a period of time. This includes > connect, build session (TWSOcketServer) and disconnect. As I understand, you are using a single connection to evaluate the time. This will give a different time tahn if you used several parrallel connections. You must be aware of that. This is because of low level TCP/IP protocol negociation which can take place in parallel for several connections. So having many simultaneous connections result in an overall better result. Setting up a TCP connection and gracefully closing a TCP connection are processes which involve several packets to be exchanged between client and server. There is a round trip time depending on the hardware and network you have. This is why having simultaneous connections will result in a better global result. Depending on a lot of factors, establishing 10 or 100 simultaneous connections mays take the same time as establishing only one. Same for graceful close. What you do in your code between OnClientConnected and the graceful close, and how you do it will drastically change the results. Fully understanding how Windows handle messages will help interpreting the results. And if you use simultaneous connections, using a thread for the processing of each connection could change the numbers a lot (In both directions !). > This is not something that TWSocketServer will tell me. Ergo, my test is > designed to determine this. Yes, TWSocketServer will tell you exactly the same thing as what you could reinvent. TWSocketServer /is/ a TWSocket and instanciate a new TWSocket for each incomming connection. You can tell TWSocketServer to use your own TWSocket derived class. You do as you like, but believe me, you are reinventing the wheel. -- [EMAIL PROTECTED] 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://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Problems writing tester with connection counts
> 2. Even though I use local messages to start and stop the connections, the > Client application will not process any other messages unless I call > Application.Processmessages, which I call in the OnSessionConnected event. That is probably your problem. NEVER call ProcessMessages or any other form of the message pump from an event handler. You'll have events re-entered and this is generally very bad (even with a simple TButton !). btw: Use TWSocketServer for your server program. It already has most of what you need, for example ClientCount. -- [EMAIL PROTECTED] 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: "Hoby Smith" <[EMAIL PROTECTED]> To: Sent: Saturday, August 25, 2007 3:04 PM Subject: [twsocket] Problems writing tester with connection counts > Hello... > > I am really stumped. I am attempting to write some testing applications > that will test the performance of some TCP/IP transport components that I > have written. My components use TWSocket components for the TCP/IP > interface and implement an encrypted, packetizing stream over TCP/IP. > > The test is real simple. I am just trying to see how many connections per > second I can make with the components. The problem is that the server and > the client report different results for the number of connections and I > CAN > NOT figure out why?!?!?! I think the problem is my approach to writing > the > test applications, but I can't figure what where the problem is?!?!? > > Basically, there are two testing applications, one is a server and one is > client. The test is just to see how many connections (sessions) can be > generated during a given period, e.g. per second. The test is really > simple, actually, which is what is stumping me. > > The Server works this way: > 1. The server starts and immediately enters listening on a port. > 2. Whenever the server receives a client connection, I increment a connect > count. I do this in the Server's OnClientConnect event. > 3. Whenever the server receives a client disconnect, I increment a > disconnect count. I do this in the Server's OnClientDisconnect event. > > That is it for the server, other than a few minor functions, like letting > the user manually clear the counts via a button on the form. > > The Client works this way: > 1. The user sets a few controls (length of test, port, etc). > 2. The user starts the start via a button. > 3. A test flag is set and a system timer is started. > 4. The Client initiates a connection to the server. > 5. When the client gets a connection, I increment a connect counter and > close the connection. I do this in the OnSessionConnected event. I close > the connection by posting a message to my main form, which in turn closes > the connection. This way, I don't close the connection from the Client > Socket's message handler. > 6. In the Client's OnSessionClosed event, I check to see if the test has > finished. The test is finished when the timer has fired and a flag is > cleared. If it has not finished, then I initiate another connection to > the > server. I do this by posting a message to the main form, which in turn > starts the connection, so that I don't start the connection it in the > Client > Socket's message handler. > > There are two problems with this: > > 1. The count of connections on the server and the count of connections on > the client will sometimes be off by a few. Not always, but most of the > time. The first test will usually be same, say 128 on both ends. But, > subsequent tests will be off by two or three, like server = 131 and client > = > 129. I do not understand this. Is this just an inherent problem with > windows socket messages and how I have implemented the test? Perhaps, > there > are pending messages in the socket que that haven't been processed or > something? I am concerned that I am missing an event or something. > > 2. Even though I use local messages to start and stop the connections, the > Client application will not process any other messages unless I call > Application.Processmessages, which I call in the OnSessionConnected event. > If I do not call ProcessMessages, the timer event never fires and the test > just runs forever or until I close the Server, then the Client application > processes messages and stops the test. If I am doing the connects and > disconnects using posted messages to the form, then why don't other > messages > get processed as well? Why is it looping in the TWSocket event handlers > only? That is rather odd. > > I hope this makes sense. Is there a better way to implement this test? > Do > I just not understand the windows socket message handling enough to > understand why this isn't working? > > I am tempted to just ignore the difference in counts, but I am concerned > that there is an underlying flaw in how I am using the TWSocket components
