I looked at the "follow tcp stream" function in wireshark.  It didn't
help me much except for the fact that I could see some of the
certificate being sent.

I run top and watch the httpd processes.  When I submit the form on
"page A" I use quickforms to process the data.  Then the I use a
redirect to send them to the next page.  There is a link on "page B"
that points to "page A."

When I redirect from "page A" to "page B" httpd process "X" is used.
When I use the link on "page B" to "page A" process "X" is used.  When
I redirect back to "page B" it uses process "X" but nothing seems to
happen and there is a hang up.  Then it uses process "X + 1."

There is a correlation between the slow timing and the start up of a
new httpd process.  Is there a setting in httpd.conf I need to modify?
Is httpd the problem?

-Daniel



On 3/12/07, Robert Lawrence <[EMAIL PROTECTED]> wrote:
> I captured 94 packets for the one on the Linux box and 35 packets for
> the one on the iSeries.

If your results with optimizing dont make as much difference as you
would like or if you don't find the root of the number of packet
descrepency there is a little feature in wireshark called "follow tcp
stream" under analize that if you are looking at a pile of packets it
will line up just the payloads of the tcp packets for you and color
code it with regards to whom was the sender of any given piece of
information.  If the packets you captured were encoded it may not be
as useful but it still may give you some useful information.  (the
linux is doing lots of really small packets vs large for the other
system or something like that)


Robert

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/


/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/

Reply via email to