Okay, given that situation, I would be considering the following statistics -
For req and ack, periodic volume. Just the number of each kind of items for that hour (or two hours, or four hours). if you want to get a little deeper, you can do stats for each period, on how long the delay was between the req and ack. (avg, min, max. stdev). Calculate this from the ack side, and dont' try to attach the stat to the req. (because the stats will be effectively identical. If you are calculating it hourly, then calculate it at the 15 minute mark, for the prior full hour. That gives any trailing transactions plenty of time to get indexed.
For response, if the typical delay is days, you don't need to produce summary stats very often. Every 6 hours or 8 hours or 12 hours or every day might be just fine. It doesn't HURT to do it more often, but it won't get you much extra information. (If you are going to be PULLING the current information frequently, though, then you might want to go ahead and run them on the same schedule.)
On the response side, you DEFINITELY want the stats on how long it took. Again, calculate those stats from the response side, since the event data is all in one place. In the last hour, we have received responses for requests from three weeks ago down to yesterday, with this average, this stdev, and so on.
Then, if you really want to, you can also calculate how long things took from the request side, but you need to wait until you have the vast majority of the responses. For example, calculate the stats on a rolling window where the requests happened exactly n days ago. (Where N is a fixed number between 8-14 )
You might learn some interesting things from that data, but from a statistical basis, across time, the request side stats are going to have an identical average and stdev to the response side stats. The difference will be in terms of finding out that, for example, requests early in the week get responses faster (in terms of calendar days) than requests late in the week.
Because of weekends, right?
... View more