如何在网络服务器上正确加载测试新组件？
我们正在经典的 ASP 环境中实现一个新的解决方案，该解决方案使用 COM 互操作来实例化 .NET 组件来完成一些工作。该解决方案运行良好，我们的团队负责人希望确保它在负载下表现良好，因为这是我们第一次在站点上使用 .NET 组件。
我需要考虑什么来进行适当的测试，以确保我引入的新代码不会在负载下崩溃？
我已经在做什么：
我制作了一个简单的 asp 网页，它调用基于查询字符串中的信息的新组件。查询字符串还有一个“关闭开关”参数，因此我可以在没有组件的情况下测试页面作为默认值。除了返回一个表示组件是否成功、失败或被跳过的值之外，页面本身是空的。
我编写了一个简单的控制台应用程序，它使用 HttpWebRequest 在每次调用时使用数据库中的唯一数据对 ASP 页面进行迭代调用。它所做的一切都是检查页面返回的值并保存数据。
然后，我将控制台应用程序部署到内部网络上的四台不同的 PC 上。在一个测试中，我在每台计算机上设置了一个应用程序实例，在另一个实例中，我在每台计算机上设置了五个应用程序实例，并将它们配置为同时开始访问开发服务器。应用程序的每个实例向 Web 服务器发出 150 个迭代请求。
对于每个场景（每台机器上有一个实例，每台机器上有五个实例），我运行了两次测试，一次没有调用组件，一次调用了组件。在这两种情况下，调用组件时完成请求所需的时间大约是未调用组件时的 2.2 倍。考虑到我们正在进行的处理量以及为更新数据而访问数据库的次数，我们认为这并不是很昂贵。此外，因为 2.2 倍的比率在我们使用 4 个并发连接访问服务器的情况下和当我们使用 20 个并发连接访问服务器的情况下似乎都是一致的，所以它似乎运行正常。
无论是否运行新组件，20 个实例的测试无疑都会给我们的开发服务器带来很大的负载，但新组件在压力下似乎表现得足够好。但是，我想确保我以正确的方式进行此操作，而不是指通过弱测试来证明我的组件不会使服务器在峰值负载下满足其需要。
We're implementing a new solution in our classic ASP environment that's using COM interop to instatiate a .NET component to do some work. The solution is working great and our team lead wants to make sure that it will perform well under load since this is the first time we'll be working with .NET components on our site.
What do I need to consider to do a proper test to make sure that the new code I introduced won't break under load?
What I'm already doing:
I made a simple asp web page that calls the new component based on the information in the query string. The query string also has an "off switch" parameter so I can test the page without the component as a default. The page itself is bare except for returning a value that represents whether or not the component was a success, failed, or was skipped.
I wrote a simple console application that uses an HttpWebRequest to make iterative calls to the ASP page using unique data from the database on each call. All it does and check the value that the page returns and save the data.
I then deployed the console application to four different PCs on our internal network. In one test, I set up one instance of the application on each of the computers, and in another instance, I set up five instances of the application on each machine and configured them to all begin hitting the development server at the same time. Each instance of the application made 150 iterative requests to the web server.
For each scenario (one instance on each machine & five instances on I each machine), I ran the test twice, once without the component being called, and once with the component being called. In both scenarios, performance with the component being called took about 2.2 times as long to complete the request than when the component wasn't called. We thought that wasn't very expensive considering the amound of processing we were doing and the number of trips being made to the database to update the data. Also, because the 2.2x ratio seemed consisent in both the scenario where we hit the server with 4 concurrent connections and when we hit the server with 20 concurrent connections, it seems to be operating OK.
The 20-instance tests certainly put a lot of load on our development server both with and without the new component running, but the new component seemed to fair well enough under stress. However, I want to make sure that I went about this the right way and am not pointing to a positive pass of a weak test to prove that my component won't bring the server to its need under peak load.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Visual Studio 有一个负载测试组件，但您所做的本质上是相同的事情。 Visual Studio 解决方案的好处是可以进行检测，您可以看到可能的性能瓶颈在哪里。
通过或失败测试的关键不应该是“完成时间比率好吗？”，而是“与给定负载相比，总响应时间还好吗？”。因此，与新组件的比较是相关的。
您的测试似乎足够严格，可以说“它在负载下不会中断”，但在与实时硬件和真实页面的任何其他处理隔离的情况下进行测试，这并不能保证。
您测量了每秒的请求总数吗？如果该值远高于您对峰值负载下实际应用程序的预期，并且响应时间合理，那么您确实对测试结果是否正确有一定的信心。
Visual Studio has a load testing component, but what you have done is essentially the same thing. The benefit of the Visual Studio solution is the instrumentation in that you can see where the likely bottleneck of performance is.
The key to you passing or failing the test should not be "Is the time to complete ratio okay?", but "Is the total response time okay compared to the given load?". The comparison with the new component is therefore relevant.
Your test seems to be rigorous enough to say "it does not break under load", but tested in isolation of the live hardware and any other processing from a real page, it is not a guarantee.
Did you measure the total number of requests per second? If that value is much higher than you would expect for a real application under peak load and the response time is reasonable then you do have some confidence in the results of the test as being a true positive.
我们已经用 Push-to-Test 和 Gomez 等公司来证明大规模应用程序是可行的。两者都模拟大量用户通过您的应用程序采用指定路径。 （就 Gomez 而言，他们拥有实际用户的计算机，他们向运行测试的所有者支付几美分。）他们可以模拟数千个并发用户并提供其他服务，例如正常运行时间监控。
两者都是付费服务，但 Push-to-Test 的软件是基于 Selenium 的，因此您也许能够构建（或找到）基于该软件的负载测试框架。
There are companies out there like Push-to-Test and Gomez that we've used to prove that large-scale applications will work. Both simulate large numbers of users that take a specified path through your application. (In the case of Gomez, they have actual users' machines that they pay pennies to the owners of run the tests.) They can simulate thousands of concurrent users and provide other services, as well, such as uptime monitoring.
Both are paid services, but the software that Push-to-Test is based on Selenium, so you may be able to build (or find) a load-test framework built on that.