You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jmeter-dev@jakarta.apache.org by "BAZLEY, Sebastian" <Se...@london.sema.slb.com> on 2003/08/12 17:29:43 UTC
RE: AW: JMeter 2.0 - socket factory [Re: Source dist build]
I agree with replacing the default socket factory; apart from lack of
statistics, there is no proper control over re-use of connections with the
default Sun version.
We looked at a possible replacement a while ago:
HTTPClient 0.3-3 http://www.innovation.ch/java/HTTPClient/
[Because of the licence, this cannot be bundled with Apache.]
But it might be possible to write an external wrapper to gather the
statistics - perhaps it would be worth having a look at the implementation?
Then there's Apache HttpClient:
http://jakarta.apache.org/commons/httpclient/index.html
I've not looked at this in any detail. Unlike the first HTTPClient it does
not fully support the HttpUrlConnection API, so it cannot be used as a
drop-in replacement. However, that is not necessarily a bad thing, as the
HttpURLConnection API is not very flexible.
Might be worth seeing what the Apache HttpClient team think about adding
statistics to their version - if they don't already exist?
===
Aside: some of these e-mail trails are getting quite long - how about using
the Wiki to collate the information?
--
The opinions expressed herein are my own, and are not necessarily endorsed
by my employer ...
-----Original Message-----
From: Jordi Salvat i Alabart [mailto:jsalvata@atg.com]
Sent: 12 August 2003 12:36
To: JMeter Developers List
Subject: Re: AW: JMeter 2.0 [Re: Source dist build]
Following Mike's prompt, I've been reading a little bit about socket
factories, etc. and I now believe it can be done -- although it's
probably difficult (or even very difficult).
Here's my view of it:
We replace the socket factory with one producing our own sockets. These
sockets should do the same thing the current ones do, except they would
leave trace of the times when relevant events happened:
- Connection initiation
- Connection established
- 1st byte transmitted
- last byte transmitted
- 1st byte received
- last byte received
...
Having this data reach the sampler is not easy -- we'll probably need
something hackish -- but I'm sure it can be done. Possibly keeping a
registry of sockets in use by the current thread and having the app
search for the right one. For protocols in which you can issue several
requests over the same socket, there should also be a callback mechanism
to reset the measuring and start over.
This would provide, at the very least, the separation between 1+2+3+4
and 5, which is the most important. As I said, separating 1, 2 and 3 is
probably not JMeter's role, but I'm sure we can still separate DNS
resolution time by using the InetAddress class to do the resolution
explicitly. With some more research, we can probably even reach some
more detail...
I'll start working on a proof-of-concept now: a socket that will output
all those recorded times to stdout when it is closed.
Salut,
Jordi.
Rittmeyer, Wolfram wrote:
> Hi all,
>
> great ideas getting exchanged here between Mike, Jordi and Jeremy...
>
> I think seperation of tasks like Jordi mentioned would be a good think. I
also highly welcome the idea of datasources by Mike. This would increase
flexibility a lot.
>
> ----by Jordi:
>
>>Totally agree. The complete split would be:
>>1- DNS resolution time
>>2- Connection set-up time (SYN to SYN ACK)
>>3- Request transmission time (SYN ACK to ACK of last request packet)
>>4- Latency (ACK of last request packet to 1st response data packet)
>>5- Response reception time
>>I'm not sure JMeter is the tool to separate 1,2,3 (this is more of an
>>infrastructure-level thing rather than application-level),
>>but 1+2+3+4
>>separate from 5 is a must. Top commercial tools separate them all.
>
>
> To my knowledge this will not be possible. DNS resolution time is not
available with Java. Java does not give us access to these lowlevel data. No
IP-flags as well. I once thought about it myself. The one and only solution
I could think of was using JNI. But I didn't like the idea because we would
loose platform independence with it. If I am wrong here I'd be glad to learn
better...
>
> Anyway, future plans sound promising.
>
> Greetings,
>
> Wolfram Rittmeyer
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
--
Salut,
Jordi.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: AW: JMeter 2.0 - socket factory [Re: Source dist build]
Posted by ms...@apache.org.
Regarding Wiki, here's my thoughts:
A lot of the old stuff is probably not worth updating, and should probably be put into some
"obsolete" area.
As far as team planning goes, I'd like to encourage people to be aggressive and fearless in
pursuing changes. With some caveats:
1. Things that are possible now should remain possible unless the team agrees otherwise in a
more formal decision making format.
2. Long term things you're working on should be described on a wiki page - I think a page per
developer would be the best way to organize it. That way, if I want to work on X, I can check
everyone's page to find out if anyone else has already started working on it.
3. Make an effort to write unit tests. I've started making PackageTest classes to collect all
unit tests from a package together, and I think it is a better option than the inner classes I've
been using.
4. If you pick a large area/idea to work on, start with some refactoring as it helps you learn the
code and pick up on something of the more subtle aspects of what's going on before you dive
in.
I think that attitude will result in the best combination of a)getting stuff done, and b)getting stuff
done right. If someone starts going off the deep end, someone should notice it from the wiki
page and draw the team's attention to it.
So, I suggest everyone make a wiki page for themselves (see:
http://nagoya.apache.org/wiki/apachewiki.cgi?JMeterDevelopment) and make some notes
about what you're thinking about doing, and what you are actually doing.
And, even for projects that several people will want input on, there should still be a project
leader on who's development page the information would go (ie, everyone should feel free to
edit everyone else' wiki pages).
======================================
On another note, I think I'd like to make a release branch of 1.9 so that simple bug fix releases
can be made without impacting new development. I would very much like anyone who does
bug fixes to make their fixes to BOTH branches, so that no merge ever needs to be done.
-Mike
On 12 Aug 2003 at 17:48, Jordi Salvat i Alabart wrote:
>
>
> BAZLEY, Sebastian wrote:
> > Aside: some of these e-mail trails are getting quite long - how about using
> > the Wiki to collate the information?
> >
>
> Not at this stage -- we did that in the past and was fun, but not very
> successful. It looks like a good place to create documentation, but not
> quite a good one for discussion.
>
> When time comes to transform discussion into a plan, the Wiki may help.
>
> BTW, would be nice if we went there and did some cleanup of obsolete
> information and discussions.
>
> --
> Salut,
>
> Jordi.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: AW: JMeter 2.0 - socket factory [Re: Source dist build]
Posted by ms...@apache.org.
Regarding Wiki, here's my thoughts:
A lot of the old stuff is probably not worth updating, and should probably be put into some
"obsolete" area.
As far as team planning goes, I'd like to encourage people to be aggressive and fearless in
pursuing changes. With some caveats:
1. Things that are possible now should remain possible unless the team agrees otherwise in a
more formal decision making format.
2. Long term things you're working on should be described on a wiki page - I think a page per
developer would be the best way to organize it. That way, if I want to work on X, I can check
everyone's page to find out if anyone else has already started working on it.
3. Make an effort to write unit tests. I've started making PackageTest classes to collect all
unit tests from a package together, and I think it is a better option than the inner classes I've
been using.
4. If you pick a large area/idea to work on, start with some refactoring as it helps you learn the
code and pick up on something of the more subtle aspects of what's going on before you dive
in.
I think that attitude will result in the best combination of a)getting stuff done, and b)getting stuff
done right. If someone starts going off the deep end, someone should notice it from the wiki
page and draw the team's attention to it.
So, I suggest everyone make a wiki page for themselves (see:
http://nagoya.apache.org/wiki/apachewiki.cgi?JMeterDevelopment) and make some notes
about what you're thinking about doing, and what you are actually doing.
And, even for projects that several people will want input on, there should still be a project
leader on who's development page the information would go (ie, everyone should feel free to
edit everyone else' wiki pages).
======================================
On another note, I think I'd like to make a release branch of 1.9 so that simple bug fix releases
can be made without impacting new development. I would very much like anyone who does
bug fixes to make their fixes to BOTH branches, so that no merge ever needs to be done.
-Mike
On 12 Aug 2003 at 17:48, Jordi Salvat i Alabart wrote:
>
>
> BAZLEY, Sebastian wrote:
> > Aside: some of these e-mail trails are getting quite long - how about using
> > the Wiki to collate the information?
> >
>
> Not at this stage -- we did that in the past and was fun, but not very
> successful. It looks like a good place to create documentation, but not
> quite a good one for discussion.
>
> When time comes to transform discussion into a plan, the Wiki may help.
>
> BTW, would be nice if we went there and did some cleanup of obsolete
> information and discussions.
>
> --
> Salut,
>
> Jordi.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
Re: AW: JMeter 2.0 - socket factory [Re: Source dist build]
Posted by Jordi Salvat i Alabart <js...@atg.com>.
BAZLEY, Sebastian wrote:
> Aside: some of these e-mail trails are getting quite long - how about using
> the Wiki to collate the information?
>
Not at this stage -- we did that in the past and was fun, but not very
successful. It looks like a good place to create documentation, but not
quite a good one for discussion.
When time comes to transform discussion into a plan, the Wiki may help.
BTW, would be nice if we went there and did some cleanup of obsolete
information and discussions.
--
Salut,
Jordi.
Re: AW: JMeter 2.0 - socket factory [Re: Source dist build]
Posted by Jordi Salvat i Alabart <js...@atg.com>.
BAZLEY, Sebastian wrote:
> Aside: some of these e-mail trails are getting quite long - how about using
> the Wiki to collate the information?
>
Not at this stage -- we did that in the past and was fun, but not very
successful. It looks like a good place to create documentation, but not
quite a good one for discussion.
When time comes to transform discussion into a plan, the Wiki may help.
BTW, would be nice if we went there and did some cleanup of obsolete
information and discussions.
--
Salut,
Jordi.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org