tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Skiba" <ski...@gmail.com>
Subject Re: backlog measurement
Date Thu, 10 Jan 2008 17:49:49 GMT
Hello Filip, thanks for your reply.

You are absolutely right.

I did this trick when I understood that it's not trivial to measure backlog
in Java. I called it backlog because a normal system would have backlog of
this size in the same conditions. For example, for maxThreads=10 and
acceptCount=30 and 25 client threads the backlog size will be 15, although
we cannot measure it.

If you use by socket factory in the same conditions, it will report
"backlog" size=15. Although now these 15 sockets are in totally different
state, from logical point of view, my blackbox behaves the same and now is
able to report this number.

About memory consumptions. In normally functioning system I expect threads
to be blocked on accept() 99% of the time. Backlog is a spare for short term
spikes. So my implementation will accept a socket and this socket will be
used by an other thread very soon. Also it's possible to configure a half of
a usual acceptCount because I create an additional buffer of this size.

I intend to use this socket factory to monitor and store the "backlog" size
once in a few minutes for all my servers. If I see that in last 3 hours this
size is always above zero, I know there is a problem. Or if users complain
that between 17:00  and 17:30 my application responded slower than usual, I
can check what were backlog readings at that time. Currently I can check
only timestamps when requests were processed, but requests could be delayed
in the backlog and I have no way to know.

If my solution is an overkill for this problem, can you please advice me a
more appropriate way.

Thank you

Andrew.

On 1/10/08, Filip Hanik - Dev Lists <devlists@hanik.com> wrote:
>
> I'm a bit confused on how you can measure backlog in Java. Backlog is a
> TCP stack implementation setting.
> Also, between TCP implementations, there is no firm definition of what
> backlog actually means. does it mean SYN_RCVD or ESTABLISHED but not yet
> accepted?
>
> If I read the implementation correct, this has nothing to do with
> backlog, since you are accepting the connections into the process, ie,
> the handshake is done, and the accept call has returned. this connection
> is no longer subject to the TCP backlog (IIRC).
>
> This implementation, would prematurely accept connections, causing the
> system to take up memory for send and receive buffers for the Java
> process.
> Filip
>
> Andrew Skiba wrote:
> > Hello,
> >
> > I want to contribute a custom SocketFactory allowing to analyze the
> > utilization of acceptConnection attribute of a Connector. In a
> > properly configured production system, there should be rare situations
> > where connections wait for a worker thread to be handled. Our client
> > complained on high latency of web requests, but the measurement on
> > servlet did not show high latency. So we wanted to know the number of
> > connections which wait in socket backlog and were not accepted yet.
> >
> > I solved this problem by writing a custom SocketFactory, which accepts
> > connections immediately and puts it in my queue until a call to
> > accept() will take them. So the number of waiting connections can be
> > monitored via JMX.
> >
> > To activate this factory, the declaration of the corresponding
> > Connector in server.xml should be changed like in the following example.
> >
> >  <Connector port="8080" maxHttpHeaderSize="8192"
> >                maxThreads="10" minSpareThreads="5" maxSpareThreads="7"
> >                enableLookups="false" redirectPort="8443"
> acceptCount="10"
> >                connectionTimeout="2000" disableUploadTimeout="true"
> >
> >
> > socketFactory="
> org.apache.tomcat.util.net.BacklogMeasuringServerSocketFactory"/>
> >
> >
> > No changes in existing classes are required.
> >
> > Please review the code in the attachment.
> >
> >
> > Andrew Skiba.
> > ------------------------------------------------------------------------
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> > ------------------------------------------------------------------------
> >
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.5.516 / Virus Database: 269.19.0/1216 - Release Date:
> 1/9/2008 10:16 AM
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message