0

I'd like to replay the IIS or Tomcat access logs to do load testing. The access logs contain only Get request, so the session data/post data is not a problem here. However two timing problem is present at default IIS and Tomcat logs

  1. The access log "time" entry is at the resolution of 1 seconds , say "06/Aug/2011:17:51:52 +0800". So when the request enter in the 1 seconds is unknown, they can comes in a bursty way or in a evenly way. The response time will be different, but how much different do not known.

  2. The access log "time" entry records the request completion time not request arrival time. See Tomcat time,IIS log time. If the "time-taken" field is present, we can extract the "time taken" from the "time" to get the arrival time, but the real problem is that "time-taken" is not logged by default. It seems to me that the only we to solve this problem is try to persuade the client to turn "time-taken" on.

Both problem can be solved by modified the default logger, but it is a last resort. Are there any workaround or tricks to measure or calculate the correct "time" so that it can be used for load testing.

IZhen
  • 145
  • 4
  • 13

1 Answers1

0

No, you can't generate more accurate data than that which you've measured. You can try and emulate something close to what you want (like assuming an even distribution, or just dumping it all in at the beginning of the second), but the best way is to improve your measurement. You can do it out-of-band, without modifying your application, by packet captures (which also gets around the "logging-at-completion" problem); you just capture the packets with the HTTP requests and the (by-the-millisecond) timestamps and write them out somewhere.

womble
  • 96,255
  • 29
  • 175
  • 230
  • Can you recommend a packet capturers that are suitable for production usage? i.e,scalable if traffic is high and less intrusive to existing infrastructure – IZhen Aug 16 '11 at 07:32
  • I find `tcpdump` with suitable packet filters and a really good I/O layer behind it to work fine for almost all purposes. Remember that you should only have to capture the data-carrying TCP packets from the client to the server in order to get the request data (i.e. the SYN/ACK/FIN/response packets can be dropped on the floor). – womble Aug 16 '11 at 10:27