HttpClient time measurement

[Florent Blondeau <fb...@pingwy.com>]

Hi there,

I've got a *real* need on Time Measurements in HttpClient, like Dns, 
connect, pre transfer, start transfer and download times.
I've seen there was an improvement request (HTTPCLIENT-68) scheduled for 
4.0 beta1 .

I've managed to add my own time collection tool, but it's really an ugly 
hack (changing socket factory, and collecting times when calling
to socket methods) and I'm not sure it will works well in multithreaded 
connections...

So, is there a known workaround to cope with that thing ? I was thinking 
about creating a socketListener with a dynamic proxy to intercept
socket method call to collect time before and after execution, but 
intercepting all socket method calls will lead my app to a performance  
loose, no ?

I would like to share with you on this subject...

If I can't avoid my ugly hack,  how much time will I have to wait before 
seeing the httpclient 4.0 beta1 (or better the 4.0 final) running ?

Thanks for reading me

florent

-- 
Pingwy
27, rue des arènes
49100 Angers


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

Re: HttpClient time measurement

[Florent Blondeau <fb...@pingwy.com>]

Thanks for your clear response,

Sorry for the response time (close to TimeOutException, no ? ;-) ), but 
I dived into
the internet searching for a method to collect time with sockets. I 
can't find any... that doesn't
lead to a new socket Implementation !!
I think that the only workaround with HttpClient (as it isn't 
core-implemented) is to create a new
SocketFactory since it is possible to declare it in the Protocol 
constructor.

This socketFactory has to be in charge of collecting time datas.

You're right for the dynamic proxies, I thought there was a Socket 
interface elsewhere, I don't know why.

I really thought it was too low lewel, but SocketFactory seems to be the 
only place where you can collect some dns resolution time,
socket connect time, that is to say all socket methods related stuff... 
without breaking the HttpClient "philosophy"

I have to wait for the version 4.0. If I have some time, I'll check if I 
can help

Thanks again for your comments

florent

Roland Weber a écrit :
> Hello Florent,
>
>   
>> I've got a *real* need on Time Measurements in HttpClient, like Dns,
>> connect, pre transfer, start transfer and download times.
>> I've seen there was an improvement request (HTTPCLIENT-68) scheduled for
>> 4.0 beta1 .
>>
>> I've managed to add my own time collection tool, but it's really an ugly
>> hack (changing socket factory, and collecting times when calling
>> to socket methods)
>>     
>
> That's what I would have done, too. If you feel that is too low in
> the abstraction hierarchy, you may want to add some code on the
> connection level.
>
>   
>> and I'm not sure it will works well in multithreaded
>> connections...
>>     
>
> Why should it not? You'll have to pass the thread context into
> your output, or keep the output within the thread context. But
> I don't see where the problem should be. The TSCCM uses only a
> cleanup thread (which will become optional), everything else is
> handled by your application threads and accessible there.
>
>   
>> So, is there a known workaround to cope with that thing ?
>>     
>
> Nothing known to me, but maybe others have some ideas.
>
>   
>> I was thinking
>> about creating a socketListener with a dynamic proxy
>>     
>
> What do you mean with socketListener? A thread listens on
> server-side sockets, that won't help on the client side.
> Dynamic proxy might refer to java.lang.reflect.Proxy, but
> that works only for interfaces, while java.net.Socket is
> a class.
>
>   
>> to intercept
>> socket method call to collect time before and after execution, but
>> intercepting all socket method calls will lead my app to a performance 
>> loose, no ?
>>     
>
> Depends on how much overhead the interception adds. You'll never
> get around the calls to System.currentTime(), no matter where
> you add your timing calls. Compared to the overhead for network
> I/O, I'd say a few more Java method calls won't hurt too bad.
> If there are some methods where the timing calls get in the way,
> you can still skip the timing for those.
>
>   
>> If I can't avoid my ugly hack,  how much time will I have to wait before
>> seeing the httpclient 4.0 beta1 (or better the 4.0 final) running ?
>>     
>
> Client beta in the second half of 2008, the final about one year
> later. These are my personal guesses. You can speed up the process
> or improve the final API by contributing.
>
> cheers,
>   Roland
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>   


-- 
Pingwy
27, rue des arènes
49100 Angers

Re: HttpClient time measurement

[Roland Weber <os...@dubioso.net>]

Hello Florent,

> I've got a *real* need on Time Measurements in HttpClient, like Dns,
> connect, pre transfer, start transfer and download times.
> I've seen there was an improvement request (HTTPCLIENT-68) scheduled for
> 4.0 beta1 .
> 
> I've managed to add my own time collection tool, but it's really an ugly
> hack (changing socket factory, and collecting times when calling
> to socket methods)

That's what I would have done, too. If you feel that is too low in
the abstraction hierarchy, you may want to add some code on the
connection level.

> and I'm not sure it will works well in multithreaded
> connections...

Why should it not? You'll have to pass the thread context into
your output, or keep the output within the thread context. But
I don't see where the problem should be. The TSCCM uses only a
cleanup thread (which will become optional), everything else is
handled by your application threads and accessible there.

> So, is there a known workaround to cope with that thing ?

Nothing known to me, but maybe others have some ideas.

> I was thinking
> about creating a socketListener with a dynamic proxy

What do you mean with socketListener? A thread listens on
server-side sockets, that won't help on the client side.
Dynamic proxy might refer to java.lang.reflect.Proxy, but
that works only for interfaces, while java.net.Socket is
a class.

> to intercept
> socket method call to collect time before and after execution, but
> intercepting all socket method calls will lead my app to a performance 
> loose, no ?

Depends on how much overhead the interception adds. You'll never
get around the calls to System.currentTime(), no matter where
you add your timing calls. Compared to the overhead for network
I/O, I'd say a few more Java method calls won't hurt too bad.
If there are some methods where the timing calls get in the way,
you can still skip the timing for those.

> If I can't avoid my ugly hack,  how much time will I have to wait before
> seeing the httpclient 4.0 beta1 (or better the 4.0 final) running ?

Client beta in the second half of 2008, the final about one year
later. These are my personal guesses. You can speed up the process
or improve the final API by contributing.

cheers,
  Roland


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org