2

全部 -

更多的方法问题。我有一个 Web 服务，我需要从客户端机器上对其进行性能测试。所以本质上是在编写一个快速的 WPF 多线程应用程序（其中有一个仪表/速度计）来直观地指示请求/响应时间。事件驱动 - 所以当我点击一个按钮时 - 应用程序将开始发出请求。我只关心请求/响应花费了多少时间，而不是响应值本身（目前）。

这是我目前的思考过程：

1）我需要创建尽可能多的线程（我的客户端机器可以处理）并测量性能。我可以考虑的 2 个选项 - 创建一个新的 Thread 机制（这样我可以完全控制线程）或使用 backgroundworker 机制（这样我可以将该值从后台处理传递回 UI）。假设 - 必须循环通过线程创建代码 - 因此可以继续为这两种方法创建多个线程。

2) 不需要任何进度报告，因此这不是选择多线程方法的标准

3）确实需要一个回调方法 - 因为它应该传回值（请求/响应网络服务所花费的时间）

4) 当我用一个值更新一个变量时 - 将利用任何一种可用的同步方法。

5) Havent 确实使用了 4.0 框架中的 Task API - 但这是我应该考虑的事情。

上面的方法看起来不错 - 还是我错过了什么？

非常感谢任何帮助！

4

1 回答 1

1

很多人都推荐了Tasks，我认为这是个好主意。我自己也不介意使用裸线程，就您应该使用哪个线程而言，两者都可以。需要警惕的主要事情是异常处理行为，这在两者之间有所不同。如果你在一个典型的线程中有一个未处理的异常，它会降低你的进程，所以你可能想要这样的东西（只是不要过于简单;））：

int errorCount = 0;

void Run()
{
    Thread t = new Thread(delegate()
    {
        try
        {
            // your code
        }
        catch (Exception )
        {
            Interlocked.Increment(ref errorCount);
        }
    });
}

另一方面，任务有一种更可控的方式来处理错误——当您调用 Task.Wait 函数时，它们会将错误包裹在AggregateException中。

我正在考虑您的案例的例外情况，特别是因为我假设您在压力测试期间最终会出现超时错误。

Parallel.ForEach可能也值得一看，但老实说，由于您正在尝试压力测试而不是真实世界的场景，我可能会避免它来确定我一次运行了多少线程 - 我相信 PLINQ 的东西会做一些客户端负载均衡。

所有这些方法的回调方法都很容易。我只是使用方法调用，而不是传递回调，但这是一个实现细节。

我会远离 BackgroundWorker，因为它确实适用于与 UI 相关的异步操作，并且在这个特定的上下文中可能有点臃肿。

于 2013-03-14T18:09:31.293 回答