Log response-time in restlet-based webservice

Question

What is the simplest way to log the response-time for a restlet-based webservice?

I want to make sure that our webservice has a reasonable response time. So I want to be able to keep an eye on response times, and do something about the requests that take too long.

The closest thing I could find is this recipe: http://www.naviquan.com/blog/restlet-cookbook-log, it explains how to change the log format. But there doesn't seem to be a parameter for response times, so probably a completely different approach is needed.

Answer 1

Well, the simplest way of logging response times is, of course, by calling System.getCurrentTimeMillis() at the start of your restlet, and then again at the end of your restlet and logging the difference. That won't of course give you the framework overhead, and I suspect it's much more naive and trivial than you are after.

I'm posting it, however, because after 10 days nobody has answered you, and I suspect it's because everybody's quietly thinking

"Can't you just use System.getCurrentTimeMillis()? No, surely that's way too dumb an answer; I'd look like an idiot if I said that. I'll just wait for someone else to make the first post."

Answer 2

I don't think logging is the way to go here, at least not any of the types of logging built into Restlet or the Java API. Those are intended for either programmatic debugging-oriented logging or access logging intended to provide statistics on which resources are being used and by whom. But the real problem is that you wouldn't be measuring the real-world experience which your users would have of your service.

If you want to measure the response times that your users will be experiencing, then you really need to have an approach to sampling which lives outside of your application stack, and ideally outside of your datacenter, so as to simulate as closely as possible the real-world conditions under which your users will be using your service.

If you only need to test the results of fairly straightforward GET and POST requests, a service like Pingdom would probably suffice. If your service is more complex, then you may need to write your own sampling app/script, which could serve as a proxy from Pingdom, et al, to your actual service. You should host the sampling proxy on a separate server from your actual service. Google's App Engine might be convenient for this.