I'm forwarding this little note from the typica 'EC2 client API' group, regarding httpclient performance. I never knew this stuff and will have to go back to my code to see where httpclients are being created; it may be of relevance to restlet too.
Speaking of which, what performance testing set up is there? or is that something you are looking for assistance on? ---------- Forwarded message ---------- From: sstreet Date: Fri, Mar 7, 2008 at 8:54 AM Subject: Too many connections To: typica <[EMAIL PROTECTED]> I was doing some work that required a tight loop... basically moving data from MySQL over to SDB. On my Windows machine, after about 8000 records, I started getting bind exceptions. I figured that this must mean we're running out of sockets, and after doing a little snooping I realized that we had thousands of sockets open. I did some searching, and found this comment on the http-client mailing list (http://www.opensubscriber.com/message/commons-httpclient- [EMAIL PROTECTED]/83294.html): "We recommend to have only one HttpClient instance per application/ component." So, I dug a bit into the code, and found that in makeRequest, typica does, indeed,create a new HttpClient instance on each request. So I made this change to AWSQueryConnection: private static HttpClient hc; public AWSQueryConnection(String awsAccessId, String awsSecretKey, boolean isSecure, String server, int port) { ... if (hc == null) { hc = new HttpClient(); } .... } However, this resulted in even more errors, because I'm calling this from lots of different threads, so I switched to use the MultiThreadedHttpConnectionManager: ... if (hc == null) { MultiThreadedHttpConnectionManager connman = new MultiThreadedHttpConnectionManager(); hc = new HttpClient(connman); } .... This now worked, but was really slow. Since we're now only using a single connection manager, the limitations on the number of total connections (and connections per host) came into play. I fixed this with: if (hc == null) { MultiThreadedHttpConnectionManager connman = new MultiThreadedHttpConnectionManager(); HttpConnectionManagerParams params = new HttpConnectionManagerParams(); params.setMaxTotalConnections(500); params.setMaxConnectionsPerHost(HostConfiguration.ANY_HOST_CONFIGURATION, 500); connman.setParams(params); hc = new HttpClient(connman); } This was the magic. Things were back to top performance, and there were no longer any more exceptions (even after 10s of thousands of puts). I just hard coded 500, but I suppose some sort of configuration property should be used. I haven't done a lot of testing to determine the optimal value, but it seems like modern systems should easily be able to handle 500 connections or more. For high traffic apps, I think this fix is very important, as those apps will quickly have connection problems (as I've been seeing). Currently, I do not believe that typica reuses connections, since each request uses a separate connection manager. There's not much more to the code changes, but I'm sure it could be a little cleaner. I hope this helps! Jon --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "typica" group. To post to this group, send email to [EMAIL PROTECTED] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/typica?hl=en -~----------~----~----~----~------~----~------~--~---
