线程化 HTTP Post 应用程序答案

【问题标题】：Threaded HTTP Post Application线程化 HTTP Post 应用程序
【发布时间】：2023-03-28 18:19:01
【问题描述】：

我有一个定期执行 HTTP 发布的应用程序（从 SQL 检索的数据）。每 30 秒最多生成 50 个线程并同时运行 HTTP 帖子。如果一个帖子失败，它会等待 2 倍，只要间隔设置为。这会发生两次。例如，30s、60s 和 120s。

我使用普通的Thread.Start() 来启动这个进程，但是我发现在实时服务器上，它完全耗尽了 CPU。

我的问题如下：

是否有更好的类用于线程性能？
有没有办法限制 .NET 中的线程应用程序 CPU 使用率？

谢谢，

凯尔

【问题讨论】：

你的重试逻辑有缺陷，它应该小于间隔，否则它只会排队到无穷大:)
恐怕需要这样。它只会在当前批次完全排序后运行下一个批次，因此不会无限期地运行。

标签： c# performance multithreading

【解决方案1】：

您不应该使用线程来运行多个 I/O 流。由于这些线程主要在 I/O 上阻塞，因此您可以使用非阻塞或异步 I/O 更有效地执行此操作。一个线程与一台服务器通信，而不是一个线程与 N 个服务器通信。

由于您使用的是 HttpWebRequest，因此您想查看 HttpWebRequest.BeginGetResponse 和 HttpWebRequest.BeginGetRequestStream。

【讨论】：

我同意...我正在考虑通过 .BeginInvoke(...) 进行异步操作，也许是委托。
谢谢，我一定会尽快调查。

【解决方案2】：

一般来说，使用线程池。

在每个 .NET 进程中都有一个线程池，一个准备好为您工作的线程池。你应该使用它。

有关原因，请参阅 Thread vs ThreadPool 或 The .NET ThreadPool

简而言之：与当前按需启动线程的方法相比，它效率更高，对 CPU 也更友好。

.NET 还有一个易于使用的机制，用于将工作发送到线程池中的线程：ThreadPool.QueueUserWorkItem。

我不知道 .NET 线程池是如何在内部进行管理的，但我知道比我聪明的工程师已经完成了分析工作来弄清楚它应该做什么，其中应该有多少线程，它应该如何表现以免淹没CPU。是的，它的设计专门是为了避免您描述的问题。如果线程池对于 ASPNET 工作进程来说足够好，那么对于我的应用程序来说可能已经足够好了。

还有你的。

【讨论】：

【解决方案3】：

很抱歉，我对多线程 HTTP 帖子没有任何经验。

话虽如此，您使用哪个类进行 HTTP 发布？
我想，它应该有方法以异步方式进行 HTTP 发布。

而且，如果这不起作用，您可以使用 ThreadPool 而不是创建自己的线程。

【讨论】：

我不能使用异步帖子，因为我需要退货。它使用普通的旧 HttpWebRequest 来发布帖子。在这种情况下，ThreadPool 会给我带来什么好处？
您可以在您的请求中使用异步。您可以对 .NET 中的任何委托执行 BeginInvoke()，这使您有机会在 HttpWebRequest 上使用异步。有关为什么应该使用线程池，请参阅我的回答。 stackoverflow.com/questions/2115299/…

【解决方案4】：

真的有必要同时运行这 50 个线程吗？

只需尝试将生成的线程数限制为 10 个线程，然后批量运行。

【讨论】：

【解决方案5】：

我想知道您运行的其他什么可能会破坏 CPU 性能（例如低效的监控循环），或者它是否是页面文件抖动问题，因为您已用完内存。如果你的工人阶级有很多本地数据，你可以很快地吸收内存。

我使用 HttpWebRequest 完成了类似的操作，并且能够同时进行大约 100 个连接，但此时我已经用尽了网络带宽和内存，尽管 50 个连接运行良好。我创建自己的线程而不是使用 ThreadPool，因为我使用回调，因此我可以轻松跟踪线程状态，甚至在需要时中止线程。它还简化了从失败的连接重新启动的过程——我只是将线程放回待处理线程的队列中。

ThreadPool 可以很好地防止您启动过多的线程，但我认为线程创建开销与网络连接响应延迟相比是微不足道的，至少在我的经验中是这样。

【讨论】：