[hobbit] performance tuning

[Jeff Newman]

Hi,

No firewall in between.

> Since the Hobbit client only runs once every 5 minutes,
> I don't understand why you have many of these on the clients.

I have 7 hosts that I am doing performance testing on. I have moved those
7 hosts to their own hobbit server. On those 7 hosts each host has
between 4-6 1 second interval tests.

By isolating them to their own server, that keeps the load off the
main hobbit server we have. As we have all discussed previously, there
is a difference between
monitoring and capacity planning, so I am pushing the limit with hobbit on this.

So when the socket is in TIME_WAIT, is it waiting on some response from
the hobbit server then? would increasing or decreasing the maximum life span
have any negative effects? I noticed in the alpha notification for the
new hobbit
it mentioned performace enhancements. Would these help do you think?

Thanks,
Jeff

On 4/5/06, Henrik Stoerner <henrik at hswn.dk> wrote:
> On Tue, Apr 04, 2006 at 06:11:57PM -0500, Jeff Newman wrote:
> >
> > I'm running Hobbit 4.1.2p1 on a Redhat AS 4 server.
> >
> > I currently have a number of server side scripts that post-process
> > incoming test results.
> >
> > My concern is a high number of "1984" sockets in TIME_WAIT condition
> > (upwords of 60 on the client at times) The clients are AIX boxes.
>
> I dont really understand why you see so many TIME_WAIT connections on
> the *client*. I could understand if they were on the Hobbit server, but
> not on the client...
>
> If there is a firewall between the clients and the server, it could be
> that the firewall terminates the connection tracking state before the
> final exchange of FIN/ACK packets has completed between the two sides.
> But then I'd expect it to be in FIN_WAIT_[1,2] ...
>
> What's TIME_WAIT anyway ... from
> http://www.ssfnet.org/Exchange/tcp/tcpTutorialNotes.html:
>
>  "The main thing to recognize about connection teardown is that a
>   connection in the TIME_WAIT state cannot move to the CLOSED state until
>   it has waited for two times the maximum amount of time an IP datagram
>   might live in the Inter net. The reason for this is that while the local
>   side of the connection has sent an ACK in response to the other side's
>   FIN segment, it does not know that the ACK was successfully delivered.
>   As a consequence this other side might re transmit its FIN segment, and
>   this second FIN segment might be delayed in the network. If the
>   connection were allowed to move directly to the CLOSED state, then
>   another pair of application processes might come along and open the same
>   connection, and the delayed FIN segment from the earlier incarnation of
>   the connection would immediately initiate the termination of the later
>   incarnation of that connection."
>
> So TIME_WAIT states should only stay around for a few minutes - I
> believe a common "2 x max lifetime" is 2 minutes, but this is somewhat
> OS dependant. Since the Hobbit client only runs once every 5 minutes,
> I don't understand why you have many of these on the clients.
>
>
> Henrik
>
>
>
> To unsubscribe from the hobbit list, send an e-mail to
> hobbit-unsubscribe at hswn.dk
>
>
>