hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <ossf...@dubioso.net>
Subject Re: HttpClient time measurement
Date Thu, 20 Dec 2007 13:41:50 GMT
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.


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

View raw message