You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Pascal S. de Kloe (JIRA)" <ji...@apache.org> on 2007/10/26 15:35:50 UTC
[jira] Created: (HTTPCLIENT-699) Performance tuning
Performance tuning
------------------
Key: HTTPCLIENT-699
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-699
Project: HttpComponents HttpClient
Issue Type: Improvement
Components: HttpClient
Affects Versions: 4.0 Alpha 1
Reporter: Pascal S. de Kloe
Priority: Minor
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Commented: (HTTPCLIENT-699) Performance tuning
Posted by "Pascal S. de Kloe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537975 ]
Pascal S. de Kloe commented on HTTPCLIENT-699:
----------------------------------------------
> I really wonder what kind of use case creates that many instances of HttpState
How about SOAP?
> It replaces the use of a CookieIdentityComparator with a static method.
It eliminates two class casts within a loop too. Creating a class for 6 lines of code if it is only used once doesn't seem right.
> I can't see any savings in the changes to getCookies().
Again, a class cast.
None of these changes are major but if you accept them I'll go through the whole codebase and improve things bit by bit. That is the way I usually work.
> Performance tuning
> ------------------
>
> Key: HTTPCLIENT-699
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-699
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient
> Affects Versions: 4.0 Alpha 1
> Reporter: Pascal S. de Kloe
> Priority: Minor
> Attachments: HttpState.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: Performance tuning
Posted by Ortwin Glück <od...@odi.ch>.
Pascal S. de Kloe wrote:
> Hi Ortwin,
>
> The team has created a test case.
>
> The ThreadSafeClientConnectionManager is locking up. Is this a known problem in
> alhpa 1? If not, could you please show me how to properly get a good instance
> of a thread safe HttpClient?
>
>
> Could you or Oleg please send me a CVS ZIP becouse I'm behind a firewall? :(
Hi Pascal,
This looks like a bug. Please open a JIRA ticket. A minimal test case
would help a lot.
Ortwin
--
[web] http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp] key 0x81CF3416
finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: Performance tuning
Posted by Ortwin Glück <od...@odi.ch>.
Pascal S. de Kloe wrote:
> You made your point clear: find the problem and eliminate it.
> However performance isn't that black and white. The thing is that every resource
> spend on org.apache.http.** is too much. They asked me if we can improve things
> and I think we can.
>
> Yes, synchronized methods *do* slow things down. Yes, creating unnecessary
> objects for each connection is bad.
>
> This HttpState was simply the first class out of a random pick to test the
> willingness to improve on the performance subject. It took me a few minutes to
> write...
I agree that perfomance is the sum of many things. So fixing many small
things does add up. Still you better start with the ones that give you
the most benefits. So I suggest to use a profiler to identify the places
where the most time is spent (I dare to doubt it's synchronization and
class casts) and which objects are collected the most. Then tackle
these. A "random pick" is hardly the best. Feel free to send us profiler
data (screenshots may suffice) to backup your patches or if you need
advice with their interpretation.
I do support your effort to review and improve the HttpClient code base
in this respect. At the same time I would like you to focus on the most
severe time/memory wasters. I have no interest in sacrificing code
clarity for übertuning for instance. I would also like to point out that
the 3.x code base is virtually end of life. That means that patches have
the greatest chance of being accepted if they are minimally intrusive.
Ortwin
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: Performance tuning
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2007-10-26 at 16:23 +0200, Pascal S. de Kloe wrote:
> You made your point clear: find the problem and eliminate it.
> However performance isn't that black and white. The thing is that every resource
> spend on org.apache.http.** is too much. They asked me if we can improve things
> and I think we can.
>
> Yes, synchronized methods *do* slow things down. Yes, creating unnecessary
> objects for each connection is bad.
>
> This HttpState was simply the first class out of a random pick to test the
> willingness to improve on the performance subject. It took me a few minutes to
> write...
>
Pascal
I agree with Odi. We will undoubtedly incorporate your changes into the
Httpclient 4.0 codeline, but we ought to be a little systemic about the
process. It does make sense to concentrate on those things that result
in more noticeable performance gains first and leave local performance
optimization until late BETA. It is pointless to optimize those classes
that are bound to change frequently.
Besides, you may want to use some sort of benchmark to quantify
differences in performance before and after changes. I did a lot of
optimization on HttpCore (the low level set of components HttpClient 4.0
is based on) a while ago but I was using JProfiler to find critical
performance bottlenecks.
Cheers
Oleg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: Performance tuning
Posted by "Pascal S. de Kloe" <pa...@quies.net>.
You made your point clear: find the problem and eliminate it.
However performance isn't that black and white. The thing is that every resource
spend on org.apache.http.** is too much. They asked me if we can improve things
and I think we can.
Yes, synchronized methods *do* slow things down. Yes, creating unnecessary
objects for each connection is bad.
This HttpState was simply the first class out of a random pick to test the
willingness to improve on the performance subject. It took me a few minutes to
write...
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Commented: (HTTPCLIENT-699) Performance tuning
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537959 ]
Oleg Kalnichevski commented on HTTPCLIENT-699:
----------------------------------------------
Pascal,
There has been a great deal of changes since alpha1. We are pretty much about to release alpha2. Could you please build your patches off the SVN trunk?
Oleg
> Performance tuning
> ------------------
>
> Key: HTTPCLIENT-699
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-699
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient
> Affects Versions: 4.0 Alpha 1
> Reporter: Pascal S. de Kloe
> Priority: Minor
> Attachments: HttpState.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Updated: (HTTPCLIENT-699) Performance tuning
Posted by "Pascal S. de Kloe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pascal S. de Kloe updated HTTPCLIENT-699:
-----------------------------------------
Attachment: HttpState.patch
> Performance tuning
> ------------------
>
> Key: HTTPCLIENT-699
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-699
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient
> Affects Versions: 4.0 Alpha 1
> Reporter: Pascal S. de Kloe
> Priority: Minor
> Attachments: HttpState.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Resolved: (HTTPCLIENT-699) Performance tuning
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski resolved HTTPCLIENT-699.
------------------------------------------
Resolution: Fixed
Pascal
I am closing this issue as WONTFIX for now. Feel free to re-open it if you port your patch to the latest SVN snapshot.
Oleg
> Performance tuning
> ------------------
>
> Key: HTTPCLIENT-699
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-699
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient
> Affects Versions: 4.0 Alpha 1
> Reporter: Pascal S. de Kloe
> Priority: Minor
> Fix For: 4.0 Alpha 3
>
> Attachments: HttpState.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Updated: (HTTPCLIENT-699) Performance tuning
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski updated HTTPCLIENT-699:
-----------------------------------------
Fix Version/s: 4.0 Alpha 3
> Performance tuning
> ------------------
>
> Key: HTTPCLIENT-699
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-699
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient
> Affects Versions: 4.0 Alpha 1
> Reporter: Pascal S. de Kloe
> Priority: Minor
> Fix For: 4.0 Alpha 3
>
> Attachments: HttpState.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Commented: (HTTPCLIENT-699) Performance tuning
Posted by "Ortwin Glück (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537965 ]
Ortwin Glück commented on HTTPCLIENT-699:
-----------------------------------------
So what this patch is trying to do is save on Object instances. I really wonder what kind of use case creates that many instances of HttpState that this is a problem :-)
It replaces the use of a CookieIdentityComparator with a static method. That's the part I disgust. It would be nicer to require CookieIdentityComparator to be thread-safe (Comparators are stateless almost always, so no big deal) and provide a static instance.
It tries to do the cookie expiry without iterator. It's a bit fragile like that, but should work. Just needs proper test coverage.
I can't see any savings in the changes to getCookies().
matchCredentials has been inlined, because the static method has no access to initialize the non-static field. Could just as well make the method non-static.
> Performance tuning
> ------------------
>
> Key: HTTPCLIENT-699
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-699
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient
> Affects Versions: 4.0 Alpha 1
> Reporter: Pascal S. de Kloe
> Priority: Minor
> Attachments: HttpState.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org