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. */