Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of dckerber@verizon.net
 designates 206.46.173.19 as permitted sender)
Message-id: <4A097863.5070001@verizon.net>
Date: Tue, 12 May 2009 09:23:47 -0400
From: David kerber <dckerber@verizon.net>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Performance with many small requests
References: <4A034AFB.7070009@verizon.net>
 <6715CF65287F8F408DA109EC03AC6C0DBCA5C4C67B@puma.melandra.net>
 <BLU0-SMTP58D74B3D0B3D380D0DDEF3C5670@phx.gbl> <4A036927.1000604@verizon.net>
 <6715CF65287F8F408DA109EC03AC6C0DBCA5C4C680@puma.melandra.net>
 <4A0890BB.5090104@christopherschultz.net> <4A08B94E.1030307@verizon.net>
 <6715CF65287F8F408DA109EC03AC6C0DBCA5C4C68F@puma.melandra.net>
 <4A096392.6050308@verizon.net>
 <6715CF65287F8F408DA109EC03AC6C0DBCA5C4C695@puma.melandra.net>
 <4A096EBC.20502@verizon.net>
 <6715CF65287F8F408DA109EC03AC6C0DBCA5C4C698@puma.melandra.net>
In-reply-to: <6715CF65287F8F408DA109EC03AC6C0DBCA5C4C698@puma.melandra.net>
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7bit

Peter Crowther wrote:
>> From: David kerber [mailto:dckerber@verizon.net]
>> Just over 1000 total, 810 to the port that this application is using.
>>     
>
> "Should" be fine on Windows.
>   
That was my gut feeling too, but I'm glad to have it confirmed.

>   
>> The vast majority are showing a status of TIME_WAIT, a dozen or so in
>> ESTABLISHED and one (I think) in FIN_WAIT_1.
>>     
>
> Sounds fair enough.  The ESTABLISHED ones are active both ways and able to transfer data; the one in FIN_WAIT_1 has been closed at one end but the other end's still open; and the ones in TIME_WAIT are closed but tombstoned so the TCP stack knows to throw away any data that arrives for them.  None of those are a surprise.
>
>   
>> That's our corporate connection, so it's shared across all
>> users.  I can
>> easily run it up to 100%  it by doing a large d/l from
>> somewhere (I need
>> to plan my patch Tuesday updates to avoid trouble), so my router and
>> firewall have no trouble handling the full bandwidth.
>>     
>
> Ah, OK.
>
>   
>> However, those
>> are low numbers of high-throughput connections.  This app
>> produces large
>> numbers of connections, each with small amounts of data, so
>> it may scale differently.
>>     
>
> It may, but I'd be a little surprised - IP is IP, and you have enough concurrency that latency shouldn't be a problem.
>   
I was wondering about that.  I knew total data throughput wasn't a major 
issue here, but wasn't sure how latency would affect it.

> 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?
>   
A typical client will have 2 to 5 items to send per transaction (they're 
actually lines from a data logger's data file), and each line is done in 
a separate POST request.  The frequency of transactions varies widely, 
but typically won't exceed one every 10 or 15 seconds from any given 
site.  As I mentioned earlier, each data line is small, 20 to 50 bytes. 

We had looked at batching up the transmissions before, and it's still an 
option.  However that adds a bit of complexity to the software on both 
ends, though the gain would be far fewer individual requests to 
process.  For now, we prefer the simplicity of line-by-line 
transmission, but if we start running into network limitations we'll 
probably start batching them up.

D


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