基于 Restlet 的 Web 服务中的日志响应时间

发布于 2024-08-23 14:52:15 字数 309 浏览 14 评论 0原文

记录基于 Restlet 的 Web 服务的响应时间的最简单方法是什么?

我想确保我们的网络服务有合理的响应时间。因此,我希望能够关注响应时间,并对耗时过长的请求采取措施。

我能找到的最接近的是这个食谱: http://www.naviquan.com/ blog/restlet-cookbook-log,它解释了如何更改日志格式。但似乎没有响应时间的参数,因此可能需要一种完全不同的方法。

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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

埋葬我深情 2024-08-30 14:52:15

当然,记录响应时间的最简单方法是在 Restlet 开始时调用 System.getCurrentTimeMillis(),然后在 Restlet 结束时再次调用Restlet 并记录差异。这当然不会给你带来框架开销,而且我怀疑它比你想要的要天真和琐碎得多。

不过我发帖是因为10天后没有人回复你,我怀疑这是因为每个人都在静静地思考

“你不能只使用 System.getCurrentTimeMillis() 吗?不,这肯定是一个太愚蠢的答案;如果我这么说,我看起来就像个白痴。我只会等待其他人发表第一篇文章。”

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."

叶落知秋 2024-08-30 14:52:15

我认为实现此目的的一种方法是使用 Codehale 的度量 API。只需将注释 @Timed(name="sampleApiName") 添加到您的 API 声明中即可。

One way to do this I suppose is to use the Codehale's metric API. Just add an annotation @Timed(name="sampleApiName") to your API declaration.

情栀口红 2024-08-30 14:52:15

我不认为日志记录是正确的选择,至少不是 Restlet 或 Java API 中内置的任何类型的日志记录。这些用于面向编程调试的日志记录或访问日志记录,旨在提供有关哪些资源正在使用以及由谁使用的统计信息。但真正的问题是您不会衡量用户对您的服务的真实体验。

如果您想测量用户将经历的响应时间,那么您确实需要一种采样方法,该采样方法位于应用程序堆栈之外,最好位于数据中心之外,以便尽可能接近真实的情况-您的用户将使用您的服务的世界条件。

如果您只需要测试相当简单的 GETPOST 请求的结果,那么像 Pingdom 可能就足够了。如果您的服务更复杂,那么您可能需要编写自己的采样应用程序/脚本,它可以作为 Pingdom 等到您的实际服务的代理。您应该将采样代理托管在与实际服务不同的服务器上。 Google 的 App Engine 可能对此很方便。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文