负载测试日志记录
我正在为我的应用程序构建一个简单的负载测试脚本。它基本上会产生一堆线程并命中登台服务器来记录响应时间。
我在本地计算机上记录时间还是在登台服务器数据库的表上记录时间之间犹豫不决。由于我将在本地运行一堆线程，因此我不希望上下文切换影响日志记录时间（或者某些日志记录数据库（如 SQLite）的性能较差），但我不想减慢 IO在临时服务器上写入日志表时。
通常会做什么？
I am building a simple load testing script for my application. It will basically spawn a bunch of threads and hit the staging server to record response times.
I am torn between logging the times on my local computer or on a table in the staging server's db. Since I am going to be running a bunch of threads locally, I don't want context switching to throw off the logging timings (or some poor performance out of some logging db like SQLite), but I don't want to slow down IO on the staging server while writing to the log table.
Which is typically done?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
添加到 Web 应用程序中的任何附加功能都可能会影响您的结果，因此您可能希望最大限度地减少这种情况。如果您只关心在服务器端生成响应需要多长时间，那么这对您来说可能是一个不错的权衡。但如果您想测量提供响应需要多长时间 - 那么您需要测量并记录测试工具的响应。在后一种情况下，您将测量负载对网络基础设施（路由器、负载平衡器、防火墙等）的影响。
FWIW，我们的负载测试工具，我最熟悉的工具都是后者 - 记录最终用户看到的响应时间。根据我们的经验，我们看到的性能问题近一半与响应的交付有关，而不是与响应的创建有关。
Any additional functionality you add to your web application could affect your results, so you probably want to minimize this. If you only care about how long it takes to generate a response on the server side, this may be an ok tradeoff for you. But if you want to measure how long it takes to deliver the response - then you need to measure and record the response from the testing tool. In the latter case, you will then be measuring the effects of load on the network infrastructure (routers, load balancers, firewalls, etc).
FWIW, our load testing tool and most I am familiar with do the latter - record the response time as seen by the end user. In our experience, nearly half of the performance problems we see are on the delivery of the response, rather than the creation of it.