Strange slowdowns

[Michael Smith <ms...@xn.com.au>]

Hi,

I'm experiencing some intermittent and rather strange slowdowns using
slide. I was hoping someone could shed some light on this.

It seems to only happen when a particular host is connecting to the
server for the first time in a while (i.e. if you do it from the same
host twice in a couple of hours, the second time never (or only rarely?)
seems to cause a problem). However, connecting from a new host only
SOMETIMES triggers this.

The symptoms are that, from the client side, nothing whatsoever happens
for 1-2 minutes. This includes a connection which fails (e.g. an
unauthenticated connection - it'll have this problem. Eventually things
will work, the user types in username/password, and the response is
quick the second time. It can also happen when the connection IS
authenticated, though)

I've mostly noticed this with clients doing a propfind through the
webdav servlet, but I've also seen it with a static html page a couple
of times.

I looked around quite a bit but didn't find anything conclusive. For a
while I was running a packet sniffer on the server, and I managed to
catch this happening once. It looked like the response (to a PROPFIND)
was going through fine (and reasonably quickly), but the final chunk
(the 5-byte 0-length terminating chunk) was sent almost 2 minutes later.
That was a little strange. 

I'm using tomcat 4.0-b1, which may well be relevent - it could as easily
be a tomcat problem as a slide problem, I suppose.

Thanks,

Michael

Re: Strange slowdowns

[Michael Smith <ms...@xn.com.au>]

> 
> That's a really wierd problem.
> Do you mean that it also happen with TC 4 built-in static page serving ? Or
> is it just with Slide ?

It's not easily reproducible on-demand, and at the moment everything is
going through slide, I think - so I can't really say. 

> 
> There is a setSoTimeout(60000) on the socket, so if something (Slide, the TC
> connector) hangs, or something really bad happens, the socket will be
> flushed and closed. I assume here, something really bad happens, but after
> 60s the remaining bytes are sent (here, it's the termination chunk).
> 

This would explain the problem, though not why something is happening to
begin with.

> 
> I would say it's a Tomcat 4 problem (bad luck, I still get to fix the bug,
> since I wrote most of the connector), and it would be very important to fix
> it.

I thought there was a good chance of it being a tc4 problem, but I'm not
on any of the tomcat lists, and there was a good chance that it was
slide at fault, so I asked here.

> 
> I think we should try to narrow the problem a little bit.
> I assume you're running the Slide version from CVS.

Yes, slide cvs from (I think) yesterday.

> Here's what you could try to help me isolate the problem :
> - Update to the latest nigthly build of TC 4.0. We're a couple days away
> from b2, so it's supposed to be stable, and it has a lot of very important
> fixes introduced since b1.

I was using m5, before upgrading to b1 yesterday, so it's not a new
problem - but I'll try the latest nightly build. Since it is hard to
reproduce it might be a couple of days before I can say anything for
sure.

> - If it still fails, try with the HTTP/1.0 connector. By default, it's
> commented out in the conf/server.xml. If it fixes the problem, then it's a
> problem somewhere in the HTTP/1.1 connector.

I'll try that too.

Michael

Re: Strange slowdowns

[Remy Maucherat <re...@apache.org>]

> Hi,
>
> I'm experiencing some intermittent and rather strange slowdowns using
> slide. I was hoping someone could shed some light on this.
>
> It seems to only happen when a particular host is connecting to the
> server for the first time in a while (i.e. if you do it from the same
> host twice in a couple of hours, the second time never (or only rarely?)
> seems to cause a problem). However, connecting from a new host only
> SOMETIMES triggers this.
>
> The symptoms are that, from the client side, nothing whatsoever happens
> for 1-2 minutes. This includes a connection which fails (e.g. an
> unauthenticated connection - it'll have this problem. Eventually things
> will work, the user types in username/password, and the response is
> quick the second time. It can also happen when the connection IS
> authenticated, though)
>
> I've mostly noticed this with clients doing a propfind through the
> webdav servlet, but I've also seen it with a static html page a couple
> of times.

That's a really wierd problem.
Do you mean that it also happen with TC 4 built-in static page serving ? Or
is it just with Slide ?

There is a setSoTimeout(60000) on the socket, so if something (Slide, the TC
connector) hangs, or something really bad happens, the socket will be
flushed and closed. I assume here, something really bad happens, but after
60s the remaining bytes are sent (here, it's the termination chunk).

> I looked around quite a bit but didn't find anything conclusive. For a
> while I was running a packet sniffer on the server, and I managed to
> catch this happening once. It looked like the response (to a PROPFIND)
> was going through fine (and reasonably quickly), but the final chunk
> (the 5-byte 0-length terminating chunk) was sent almost 2 minutes later.
> That was a little strange.

When serving static files, both the integrated TC servlet and Slide should
behave in a very similar fashion (I reused lots of code from TC).

> I'm using tomcat 4.0-b1, which may well be relevent - it could as easily
> be a tomcat problem as a slide problem, I suppose.

I would say it's a Tomcat 4 problem (bad luck, I still get to fix the bug,
since I wrote most of the connector), and it would be very important to fix
it.

I think we should try to narrow the problem a little bit.
I assume you're running the Slide version from CVS.
Here's what you could try to help me isolate the problem :
- Update to the latest nigthly build of TC 4.0. We're a couple days away
from b2, so it's supposed to be stable, and it has a lot of very important
fixes introduced since b1.
- If it still fails, try with the HTTP/1.0 connector. By default, it's
commented out in the conf/server.xml. If it fixes the problem, then it's a
problem somewhere in the HTTP/1.1 connector.

Remy