Re: Proposed changes to HTTP Samplers [long]
I think this is all a great idea. My suggestion would be to separate the data from the execution (oi, not OO!) and here's why: If you had a class that just held the data for a web request, independent of Sun's HTTP Client or Apache's, then that would solve your last problem by having everything in JMeter just talk about the data - ie createUrlFromAnchor() would return data, not a particular implementation. The sampling code would use the data and return a SampleResult, and it could be a factory in the sense that the web request data also includes information on what implementation to use, or that could be a separate argument into the "sample" method. -Mike On Sat, 2004-07-03 at 09:58, Sebastian Bazley wrote: > As can be seen from the recent commits, I've been looking at the HTTP > package structure in some detail just lately when fixing bug 29884. > > There are still quite a few classes that assume that there is only one HTTP > Sampler (i.e. using the standard Java classes). I'd like to generalize this, > to make it easier for users to choose which implementation they want to use. > > The proposed changes fall under several areas. > > HTTP GUI > > It seems to me that it would be useful to combine the GUIs, and add a means > to select the implementation on the default page or the sampler itself, > probably as a drop-down list showing the handler types. I propose to do this > by extending the original GUI class, and removing the new one. > > This will mean that saved test plans using the new GUI would no longer work, > but I think that can be overcome by using the upgrade.properties file to > change the class name, and including some special handling to change the > value of the HTTP handler field accordingly. > > I also propose to add a property to select the default handler, so that > users could use existing original test plans and have them automatically use > a new handler. This would only apply if the test plan did not specify the > value. [I suppose there could also be a handler override property.] > > Static Factory > == > It would probably be useful to have a static factory to create an instance > of the appropriate handler. > This would contain various methods for chosing the appropriate sampler, e.g. > by name, by class, by instance. > It can also have a default handler that is decided at run-time. [Could be > part of HTTPSamplerBase, I suppose.] > > Samplers that extend or use HTTPSampler > = > These are AccessLog, Soap, and WebService. > It seems to me that rather than extending HTTPSampler, these could create an > instance of the an HTTP sampler and use that. > This would allow the existing HTTPSamplers to be made final. Then it would > be possible to change which handler to use. [I've not looked into how one sh > ould present the option to the user.] > > The class StandardGenerator currently creates an instance of HTTPSampler; > this could/should also be made changeable. > > The Proxy classes currently assume that it generates only HTTPSampler > classes; this could be made variable fairly easily. > > The trickier bit > == > At least it seems to be the trickiest part: > > The HtmlParsingUtils.createUrlFromAnchor() method needs to create an HTTP > Sampler; this is currently the original sampler. > > As far as I can see, this needs to create a sampler of the same type as the > one the caller is using, but there does not seem to be any way to obtain > this information currently, and there is no guarantee that the same handler > will be used throughout a test. > > It would be possible to pass in the original instance of the class (or at > least the class name), but the hierarchy is quite complicated (it includes a > recursive call), so before proceeding further, it would be useful to know if > I'm correct in thinking that it needs to choose the correct sampler? > > What do you all think? > > It's not necessary to do any of it; and some parts can be done in isolation. > > I've not *tried* any of it yet, so I may have overlooked something > obvious... > > Sebastian > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Michael Stover <[EMAIL PROTECTED]> Apache Software Foundation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed changes to HTTP Samplers [long]
I believe commons.HTTPClient uses sockets, so extending it with performance metrics should be simple technically. the trick will be to get the commons developers to accept the patch. Most people do not use HTTPClient to measure performance, so having it as part of HTTPClient may be questionable. I don't know HTTPClient well enough, but one approach might be to extend the class locally for JMeter and add the necessary performance metrics. peter On Wed, 7 Jul 2004 09:22:21 -0400, Jonathan Easterling <[EMAIL PROTECTED]> wrote: > Ok, after some poking around in code, the > org.apache.jmeter.protocol.http.sampler.HTTPSampler, it appears to use the standard > java.net.URL stuff (IMHO is a very poor effort on Sun's part) It does not allow for > lower level control of the IO. For example you only know of a disconnect when you > are listening (in a single threaded send/response model) only when you try to send > more data down the line, then it pop's the exception. The internals however are not > to shabby (the Sun.io.*) but it's non-[(standard)(supported)(reconized)(stable)] so > it's not a good choice either. (btw, try to do FTP that does multiple gets using the > URL stuff, it's not easy). Instead of re-implementing the java.net.URL for this, I > agree it may be a more benifital approch to first switch over to the Apache > HTTPClient stuff (at least won't have to do all the manual re-direction stuff), and > then as a seperate task see what it would take to extend the HTTPClient, when that's > working right it would be a simple class replacement. > If this approch sounds reasonable, let me know and I will start to pull together > what would have to change (and learn how the commons.net stuff does it's IO) > Thanks > Jon. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Proposed changes to HTTP Samplers [long]
Ok, after some poking around in code, the org.apache.jmeter.protocol.http.sampler.HTTPSampler, it appears to use the standard java.net.URL stuff (IMHO is a very poor effort on Sun's part) It does not allow for lower level control of the IO. For example you only know of a disconnect when you are listening (in a single threaded send/response model) only when you try to send more data down the line, then it pop's the exception. The internals however are not to shabby (the Sun.io.*) but it's non-[(standard)(supported)(reconized)(stable)] so it's not a good choice either. (btw, try to do FTP that does multiple gets using the URL stuff, it's not easy). Instead of re-implementing the java.net.URL for this, I agree it may be a more benifital approch to first switch over to the Apache HTTPClient stuff (at least won't have to do all the manual re-direction stuff), and then as a seperate task see what it would take to extend the HTTPClient, when that's working right it would be a simple class replacement. If this approch sounds reasonable, let me know and I will start to pull together what would have to change (and learn how the commons.net stuff does it's IO) Thanks Jon. -Original Message- From: BAZLEY, Sebastian [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 06, 2004 11:39 AM To: 'JMeter Developers List' Subject: RE: Proposed changes to HTTP Samplers [long] It is easy enough to enhance the Sample Result class(es) to include fields to hold the extra information, and some of it is easy to collect, e.g. the sizes. However, some of the timings may not be available without changes to the underlying http protocol. This will need to be investigated - maybe you can help here? In fact, apart from the sizes, it is probably not possible to collect any of the extra information from the default http implementation (one of the reasons we are trying HTTPClient). == AFAIK, connections can already be re-used with HTTPClient (set keep-alive); it's not possible to do this with the standard http implementation. [The reasons have been discussed several times in the lists.] As you say, the GUIs would need to be enhanced as well to make use of the new information. S. -Original Message- From: Jonathan Easterling [mailto:[EMAIL PROTECTED] Sent: 06 July 2004 13:45 To: JMeter Developers List Subject: RE: Proposed changes to HTTP Samplers [long] While changes are going on, may I make a few suggestions about making JMeter more robust in the HTTP Statistics area: Record the time to the first byte in the request. Record the time to the first byte in the response. Record the time to the last byte in the request. Record the time to the last byte in the response. Record the time to the connect. Record the time to the disconnect. Record the size of the request. Record the size of the response. Option to re-use connections (like IE does). By a brief look at the code, it would appear the GUI would also have to change to handle this area. Right now it would appear that the GUI only knows how to handle one timer event. We could add a hashtable to have all the timer events and still have the Sampler return the current implementation as default but if the gui can extract the data, then it could get a reference to the hashtable and start plotting/calulating/displaying based on all the hashtable. Suggestions, comments? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. ___ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Proposed changes to HTTP Samplers [long]
It is easy enough to enhance the Sample Result class(es) to include fields to hold the extra information, and some of it is easy to collect, e.g. the sizes. However, some of the timings may not be available without changes to the underlying http protocol. This will need to be investigated - maybe you can help here? In fact, apart from the sizes, it is probably not possible to collect any of the extra information from the default http implementation (one of the reasons we are trying HTTPClient). == AFAIK, connections can already be re-used with HTTPClient (set keep-alive); it's not possible to do this with the standard http implementation. [The reasons have been discussed several times in the lists.] As you say, the GUIs would need to be enhanced as well to make use of the new information. S. -Original Message- From: Jonathan Easterling [mailto:[EMAIL PROTECTED] Sent: 06 July 2004 13:45 To: JMeter Developers List Subject: RE: Proposed changes to HTTP Samplers [long] While changes are going on, may I make a few suggestions about making JMeter more robust in the HTTP Statistics area: Record the time to the first byte in the request. Record the time to the first byte in the response. Record the time to the last byte in the request. Record the time to the last byte in the response. Record the time to the connect. Record the time to the disconnect. Record the size of the request. Record the size of the response. Option to re-use connections (like IE does). By a brief look at the code, it would appear the GUI would also have to change to handle this area. Right now it would appear that the GUI only knows how to handle one timer event. We could add a hashtable to have all the timer events and still have the Sampler return the current implementation as default but if the gui can extract the data, then it could get a reference to the hashtable and start plotting/calulating/displaying based on all the hashtable. Suggestions, comments? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. ___ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Proposed changes to HTTP Samplers [long]
While changes are going on, may I make a few suggestions about making JMeter more robust in the HTTP Statistics area: Record the time to the first byte in the request. Record the time to the first byte in the response. Record the time to the last byte in the request. Record the time to the last byte in the response. Record the time to the connect. Record the time to the disconnect. Record the size of the request. Record the size of the response. Option to re-use connections (like IE does). By a brief look at the code, it would appear the GUI would also have to change to handle this area. Right now it would appear that the GUI only knows how to handle one timer event. We could add a hashtable to have all the timer events and still have the Sampler return the current implementation as default but if the gui can extract the data, then it could get a reference to the hashtable and start plotting/calulating/displaying based on all the hashtable. Suggestions, comments? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed changes to HTTP Samplers [long]
I've been slacking off this 4th of july weekend. I'll try to post something resembing useful comments later in the week. I just skimmed the commits, but so far it seems useful. peter On Sat, 3 Jul 2004 14:58:19 +0100, Sebastian Bazley <[EMAIL PROTECTED]> wrote: > As can be seen from the recent commits, I've been looking at the HTTP > package structure in some detail just lately when fixing bug 29884. > > There are still quite a few classes that assume that there is only one HTTP > Sampler (i.e. using the standard Java classes). I'd like to generalize this, > to make it easier for users to choose which implementation they want to use. > > The proposed changes fall under several areas. > > HTTP GUI > > It seems to me that it would be useful to combine the GUIs, and add a means > to select the implementation on the default page or the sampler itself, > probably as a drop-down list showing the handler types. I propose to do this > by extending the original GUI class, and removing the new one. > > This will mean that saved test plans using the new GUI would no longer work, > but I think that can be overcome by using the upgrade.properties file to > change the class name, and including some special handling to change the > value of the HTTP handler field accordingly. > > I also propose to add a property to select the default handler, so that > users could use existing original test plans and have them automatically use > a new handler. This would only apply if the test plan did not specify the > value. [I suppose there could also be a handler override property.] > > Static Factory > == > It would probably be useful to have a static factory to create an instance > of the appropriate handler. > This would contain various methods for chosing the appropriate sampler, e.g. > by name, by class, by instance. > It can also have a default handler that is decided at run-time. [Could be > part of HTTPSamplerBase, I suppose.] > > Samplers that extend or use HTTPSampler > = > These are AccessLog, Soap, and WebService. > It seems to me that rather than extending HTTPSampler, these could create an > instance of the an HTTP sampler and use that. > This would allow the existing HTTPSamplers to be made final. Then it would > be possible to change which handler to use. [I've not looked into how one sh > ould present the option to the user.] > > The class StandardGenerator currently creates an instance of HTTPSampler; > this could/should also be made changeable. > > The Proxy classes currently assume that it generates only HTTPSampler > classes; this could be made variable fairly easily. > > The trickier bit > == > At least it seems to be the trickiest part: > > The HtmlParsingUtils.createUrlFromAnchor() method needs to create an HTTP > Sampler; this is currently the original sampler. > > As far as I can see, this needs to create a sampler of the same type as the > one the caller is using, but there does not seem to be any way to obtain > this information currently, and there is no guarantee that the same handler > will be used throughout a test. > > It would be possible to pass in the original instance of the class (or at > least the class name), but the hierarchy is quite complicated (it includes a > recursive call), so before proceeding further, it would be useful to know if > I'm correct in thinking that it needs to choose the correct sampler? > > What do you all think? > > It's not necessary to do any of it; and some parts can be done in isolation. > > I've not *tried* any of it yet, so I may have overlooked something > obvious... > > Sebastian > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
