Next Previous Contents

10. Troubleshooting

10.1 Error Messages

A brief guide to some of the error messages, and the work arounds.

Run_xx_yy/reports has some odd looking reports. all stats are 0.00 for several runs, then jump to a very high value, (200-300 seconds), then a very low value, then to 0.00 again. What does this mean?

I dunno

I get the error message: ....cannot connect ...

You are behind a firewall. Use either the socks versions of the binaries, or specify the proxy server with the -p flag.

10.2 Known Problems or Likely Trouble Spots

Checksums

If there is a current date or some similar thing in a page, the date will be different every day the page is run.

Or, you COULD run with the -i flag and tell webclient to ignore checksums. This is not a good idea for the following reason: your server could fail and send more or less meaningless web pages to webclient in the middle of a long performance run, and you will never know the difference. It has happened to me.... That is the reason the checksum stuff is in there in the first place!

If you do get a mysterious checksum error, look in webclient error log and then go look at the trace file generated when you retrained your script file. (You did use the shell script "retrain" to retrain your webclient input file, didn't you?). Locate the offending page in the trace file and in the webclient error log. Split them out into a separate file (each) and diff them to find out why they are different. This will often point to something like a date field or the infamous handles (see item(2)) which you will have to figure out how to kludge around somehow.

Handles

XXX This section is obsolete and no longer applicatble. A handle is a value manufactured by the servlet code and sent out in the page, that the server expects the browser to hand back to the server on one of the requests in the page. The server uses this to store data between pages. What happens is that the handle value is somehow associated with permanent storage in the server; when a new request comes along, it supplies the handle value given to the browser in the last page. The server code then goes and fetches the saved data.

This is problematic for webclient in that webclient runs a saved list of URL's. Those URL's can have handle values in them that were good only for the particular run when the URL's were saved and are meaningless in a subsequent run. So webclient will fail to submit a plausible request to the server.

Handles are also problematic for webclient in that if webclient is checking hash values (to make sure that the pages sent are the correct ones) and there is a handle value on the page, then every time the page is run, the handle values are different so they never checksum the same.

How this problem is solved: In the simple_check_sum routine in webclient and webmon, the handle values are found and overwritten with X's before the hash is calculated. This should make the pages checksum the same. Now this is still a problem if handle values are not always of the same length.


Next Previous Contents