12

我有一个在 Visual Studio 2010 和 Mono Develop 2.8 上开发的 C# 服务器。NET 框架 4.0

看起来这个服务器在 Windows 上的表现比在 Linux 上好得多（在可扩展性方面）。我使用 Apache 的 ab 工具在原生 Windows（12 个物理内核）、8 核和 12 核 Windows 和 Ubuntu 虚拟机上测试了服务器可扩展性。

Windows 响应时间几乎是平坦的。当并发级别接近/超过核心数量时，它开始回升。

由于某种原因，Linux 响应时间要差得多。从并发级别 5 开始，它们几乎呈线性增长。8 核和 12 核 Linux VM 的行为也类似。

所以我的问题是：为什么它在 linux 上表现更差？（我该如何解决这个问题？）。

请查看随附的图表，它显示了完成 75% 请求的平均时间与请求并发的函数关系（范围栏设置为 50% 和 100%）。 作为请求并发的函数，完成 75% 请求的时间

我有一种感觉，这可能是由于 mono 的垃圾收集器。我尝试使用 GC 设置，但没有成功。有什么建议吗？

一些额外的背景信息：服务器基于一个 HTTP 侦听器，该侦听器可以快速解析请求并将它们排队到线程池中。线程池负责用一些密集的数学来回复这些请求（在大约 10 秒内计算出答案）。

4

6 回答 6

4

您需要首先找出问题所在。首先使用HeapShot监控您的内存使用情况。如果不是内存，请分析您的代码以查明耗时的方法。

这个页面，性能提示：编写性能更好的 .NET 和 Mono 应用程序，包含一些有用的信息，包括使用 mono 分析器。

过多的字符串操作和装箱通常是无法很好扩展的代码的“隐藏”罪魁祸首。

于 2012-05-18T23:47:35.777 回答
1

我不相信这是因为GC。AFAIK GC 副作用应该或多或少均匀地分布在线程中。

我的盲目猜测是：您可以通过使用 ThreadPool.SetMinThreads/SetMaxThreads API 来修复它。

于 2012-05-21T02:27:56.590 回答
1

试试 sgen 垃圾收集器（为此，推荐使用 Mono 2.11.x）。查看 mono 手册页以获取更多详细信息。

于 2012-05-21T02:13:10.410 回答
1

我强烈建议您对代码进行一些关于各个方法运行时间的配置文件。您很可能会看到一些锁定或类似的多线程问题，而这些问题并没有被 mono 完美处理。CPU 和 RAM 的使用也会有所帮助。

于 2012-05-21T02:51:59.607 回答
1

我相信这可能与我们追踪的涉及线程池和新线程的启动行为的问题相同，以及 setMinThreads 的单声道实现中的错误。请参阅我在该线程上的答案以获取更多信息：https ://stackoverflow.com/a/12371795/1663096

于 2012-10-29T04:11:16.233 回答
0

如果你的代码抛出了很多异常，那么 mono 比 .NET 快 10 倍

于 2012-05-21T02:31:27.190 回答