Return-Path: Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: (qmail 36523 invoked from network); 12 May 2009 13:28:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 12 May 2009 13:28:25 -0000 Received: (qmail 82691 invoked by uid 500); 12 May 2009 13:28:20 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 82665 invoked by uid 500); 12 May 2009 13:28:20 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 82654 invoked by uid 99); 12 May 2009 13:28:20 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 May 2009 13:28:20 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=FM_FAKE_HELO_VERIZON,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of dckerber@verizon.net designates 206.46.173.7 as permitted sender) Received: from [206.46.173.7] (HELO vms173007pub.verizon.net) (206.46.173.7) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 May 2009 13:28:09 +0000 Received: from [127.0.0.1] ([216.41.111.254]) by vms173007.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KJJ00BG09E0MXTF@vms173007.mailsrvcs.net> for users@tomcat.apache.org; Tue, 12 May 2009 08:27:38 -0500 (CDT) Message-id: <4A097945.2080905@verizon.net> Date: Tue, 12 May 2009 09:27:33 -0400 From: David kerber User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-version: 1.0 To: Tomcat Users List Subject: Re: Performance with many small requests References: <4A034AFB.7070009@verizon.net><6715CF65287F8F408DA109EC03AC6C0DB CA5C4C67B@puma.melandra.net>< 4A036927.1000604@verizon.net><6715CF65287F8F408DA109EC03AC6C0DBCA5C4C680@pu ma.melandra.net><4A0890BB.5090104@christopherschultz.net> <4A08B94E.1030307@verizon.net><6715CF65287F8F408DA109EC03AC6C0DBCA5C4C68F@p uma.melandra.net><4A096392.6050308@verizon.net><6715CF65287F8F408DA109EC03A C6C0DBCA5C4C695@puma.melandra.net><4A096EBC.20502@verizon.net> <6715CF65287F8F408DA109EC03AC6C0DBCA5C4C698@puma.melandra.net> <0AAE5AB84B013E45A7B61CB66943C17228D87E8DE1@USEA-EXCH7.na.uis.unisys.com> In-reply-to: <0AAE5AB84B013E45A7B61CB66943C17228D87E8DE1@USEA-EXCH7.na.uis.unisys.com> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Caldarale, Charles R wrote: >> From: Peter Crowther [mailto:Peter.Crowther@melandra.com] >> Subject: RE: Performance with many small requests >> >> That said, if a client has multiple data items to send in rapid >> succession, does it accumulate those and batch them, or does it send >> each one as a different request? Or does the situation never arise? >> > > Continuing with that thought, are the requests from a single client frequent enough to warrant using keepalives? Building and tearing down the TCP session on each request might be adding noticeable delay, although your analysis of the heap dumps hasn't shown that yet. > See the message I just sent. How difficult are keepalives to implement? Our app design is such that we are never supposed to go longer than 5 minutes without at least a status update transmission. Dave --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org