2

我有一个在 32 位 Windows 服务器上部署和测试的 C#/WCF 应用程序（托管在 Windows 服务中）。现在我需要将它部署到生产环境中。我的网络团队建议将其部署在 64 位 Windows Server 上，以充分利用服务器功能。

我的问题：

  • 在 64 位操作系统上部署应用程序是否有任何性能提升？如果是，多少钱？
  • 我需要做任何特别的事情来使我的应用程序与 64 位操作系统兼容吗？如果是，是什么？

PS 我的应用程序是使用“任何 CPU”选项编译的（这有关系吗？）。

4

1 回答 1

1

有关于这方面的信息博客。快速 Bing 会带来 1000 多个谈话要点：http://www.bing.com/search?q=x64+vs+x86+server&src=IE-SearchBox&FORM=IE8SRC 但是，简而言之：

在 64 位操作系统上部署应用程序是否有任何性能提升？如果是，多少钱？

最显着的好处是内存利用率——特别是，您的服务/应用程序，以及服务器的所有其他服务/应用程序，有更多的发挥空间。仅当您有 4 GB 或更多 RAM 时才适用。如果您的内存少于此数量，那么您实际上是通过分配块来浪费内存。

在原始性能级别的好处是，对于每个 CPU 周期，您可以执行多达 64 位的信息，而不是 32 位 - 信息翻倍。多线程应用程序明显更引人注目：例如托管在 IIS 中的 WCF 服务，它是多线程的传入请求。:)

我需要做任何特别的事情来使我的应用程序与 64 位操作系统兼容吗？如果是，是什么？

简短的回答，什么都没有。:) 当您使用默认的“任何 CPU”选项 进行编译时，这就是 .NET 的好处！

当您将代码编译成程序集时，您正在将代码编译成中间语言 (IL)，而不是实际的机器代码。安装在您要部署到的特定服务器/工作站/设备上的 .NET CLR（公共语言运行时）版本是获取您的 IL 代码并在该特定平台（x86、x64 或IA-64（或 AMD64、ARM 等，如果使用了任何调整）。你不必做任何事情！

至于编码实践，也没有什么具体可做的。

引用第 3 方本地程序集？ 现在，唯一需要担心的是，如果您通过 COM 或类似方式使用以本机代码编译的任何第 3 方程序集（即基本上以原始语言编写的第 3 方程序集）进行引用。在 x64 机器上通过 CLR 引用 32 位本机程序集变得很棘手（基本上，您必须强制应用程序编译为 32 位才能访问它）。但是，还有其他解决方法，这超出了此答案的范围。

这就是为什么我要么：坚持所有 .NET 引用，只引用用 .NET 编写的第 3 方程序集，自己编写，或者请求第 3 方组件的作者发布 32 位和 64 位编译版本。后者变得难以在您的 x86（32 位）机器上测试，因为您只能参考 32 位版本，但必须部署 64 位版本。

更令人头疼的是在处理您自己的 WCF 项目和那些 3rd 方本机程序集时，Visual Studio（以及 Cassini）中的内置 WCF 托管服务也只有 32 位作为 Visual Studio 的 IntelliSense。是的，当使用 3rd 方本机程序集并尝试在 x64 机器上调试应用程序时，这很有趣。美好的时光！

于 2010-01-11T08:35:51.537 回答