Inexplicable delays in browser-to-servlet-to-browser communication

Question

We are seeing some inexplicable "pauses" in the round-trip from
browser-to-servlet-to-browser communication. The browser and Weblogic
instance are on different machines, so correlating absolute times has
been difficult. So at this point it's hard to tell whether the browser
request is not being received immediately by the servlet, or the servlet
response is not being received immediately by the browser... or perhaps
it is, but maybe the response stream isn't "closing" properly, causing
the browser to think there's still more to come.
If the browser request is not being received immediately by the servlet,
it could be because the execute thread count is so low that the request
is being blocked until a thread is availble to service it. But our
thread count is set to 30 and this is with just a single user hitting
the servlet.
If the servlet response is not being received immediately by the
browser, or is not being closed properly, what could cause that?
Occassionally, I have been able to account for some of the "delay"
time. Our servlet does the usual stuff: writes out to the response
writer and then closes the writer:
PrintWriter writer = response.getWriter();
writer.write( htmlString );
writer.close();
I have seen the writer.close() method taking a long time - over 5
seconds on one occassion! What could it be doing?
Could some type of TCP_NO_DELAY network setting account for all of
this? Any and all help/experiences are appreciated.
mg
Mike Gorman, Director of Architecture
YOUcentric, Inc.
Charlotte, NC
704-643-1000 x518
http://www.youcentric.com

Answer 1

If you are using 5.1 and you have ELF turned on (see docs).
You can specify "time" as an ELF header and this gives you the time of
processing and the write.
mbg
In article <[email protected]>, [email protected] says...
Here are a few top of the head suggestions:
1. You can log the time when the request is received by the servlet and
when the output stream is closed. That should give you a fair idea of
what percentage of delay happens on the servlet side.
2. Try flush() to send stuff to the browser after every few lines of
write(). It helps.
3. IE does wait for the whole HTML to come in before it displays unlike
Netscape which shows the streaming data. So switch browser and check.
4. Make sure you are not using the SingleThread model even though that
does not explain the delay encountered by a single user.
If these do not help, you would need to give more insight into the code.
- Anshum
Mike Gorman wrote:
We are seeing some inexplicable "pauses" in the round-trip from
browser-to-servlet-to-browser communication. The browser and Weblogic
instance are on different machines, so correlating absolute times has
been difficult. So at this point it's hard to tell whether the browser
request is not being received immediately by the servlet, or the servlet
response is not being received immediately by the browser... or perhaps
it is, but maybe the response stream isn't "closing" properly, causing
the browser to think there's still more to come.
If the browser request is not being received immediately by the servlet,
it could be because the execute thread count is so low that the request
is being blocked until a thread is availble to service it. But our
thread count is set to 30 and this is with just a single user hitting
the servlet.
If the servlet response is not being received immediately by the
browser, or is not being closed properly, what could cause that?
Occassionally, I have been able to account for some of the "delay"
time. Our servlet does the usual stuff: writes out to the response
writer and then closes the writer:
PrintWriter writer = response.getWriter();
writer.write( htmlString );
writer.close();
I have seen the writer.close() method taking a long time - over 5
seconds on one occassion! What could it be doing?
==================================================
NewsGroup Rant
==================================================
Rant 1.
The less info you provide about your problem means
the less we can help you. Try to look at the
problem from an external perspective and provide
all the data necessary to put your problem in
perspective.