有没有办法找出 websphere 处理请求需要多长时间
我有一个问题，我需要监视 Websphere 处理请求所需的时间。具体来说，我需要知道在“应用程序世界”中花费了多少时间，即处理ear文件中的代码所花费的时间。
我不能只计算 request_time - reponse_time 因为它包含在容器或我所说的“websphere 世界”中花费的时间。我需要知道仅在ear 文件中花费的时间。
我可以在 websphere 中切换一些性能设置，以便将此信息记录到服务器系统日志文件中吗？该应用程序没有 log4j。
我正在使用Websphere 6.1
I have an issue where I need to monitor how long it takes for Websphere to process a request. Specifically I need to know how much time is spent in the "application world", that is time spent processing code in the ear file.
I can't just compute request_time - reponse_time because that contains time spent in the container or what I call "websphere world". I need to know the time spent only in the ear file.
Is there some performance setting I can toggle in websphere so this information gets logged to the server system log file? The application does not have log4j.
I am using Websphere 6.1
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
看一下WAS管理控制台下的PMI界面。它提供了一些性能指标——不是最漂亮或最简单的界面，但它可能提供您正在寻找的东西。
通常使用监控插件来执行此操作。我的公司通过 WAS JBM 插件使用 Introscope，它提供了比 PMI 更好的界面来查看性能数据。当然，它不是免费的，但可能有比 PMI 更好的免费或廉价替代品。
Take a look at the PMI interface under the WAS admin console. It provides some performance metrics -- not the prettiest or easiest interface, but it might provide what you're looking for.
A monitoring plugin is often used to do this. My company uses Introscope via a WAS JBM plugin, and it provides a better interface than PMI for viewing the performance data. Of course, it isn't free, but there may be free or cheap alternatives that are better than PMI.
WebSphere 有一种称为“请求指标”的东西
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.express.doc/info/exp/ae/tprf_rqenable.html
它使您可以记录不同级别的制动请求执行时间。正如您所期望的那样，通过此类监控，可以轻松收集大量数据，因此可以根据其他条件（如 java 包命名空间、EJB 名称、URI 等）过滤事件。
WebSphere has something called "request metrics"
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.express.doc/info/exp/ae/tprf_rqenable.html
It gives you the possibility to log braked down request execution times on different levels. As you may expect with such monitoring it's easy to collect to much data so there is a possibility to filter events based on additional criteria like java package namespace, EJB name, URI etc.