速度慢的原因可能是什么(详情见邮件正文)?

速度慢的原因可能是什么(详情见邮件正文)?

我遇到了一个非常奇怪的情况,我正努力解决它。一个性能问题,它看起来真的像是在代码中设置了一个空的等待序列(虽然它可能不是这样)。

我有一台功能非常强大的专用服务器(10 GB RAM、八个 Xeon 核心等),运行 Ubuntu 10.04,并将所有功能服务(用于为客户端提供安全访问的 OpenVPN 服务器除外)部署在单独的 VirtualBox(vboxheadless)机器中(一台用于公司电子邮件服务器,一台用于 Web 服务器,一台用于会计/crm 服务器(Firebird + 专有应用服务器与 Delphi 制作的客户端协同工作))。

CPU 负载(如“top”所示)几乎总是接近于零。主机系统 RAM 使用率接近 100%,但并未过载(因为使用的交换空间非常少,并且释放的内存(通过停止其中一个虚拟机)不会很快被重新使用)。大约 50% 的客户机 RAM 被使用。iostat 通常显示接近于零的 %util。网络带宽似乎未得到充分利用。

但是会计/crm 客户端(在 WinXP 机器上运行的 Win32 Delphi 应用程序)软件在该服务器上的运行速度非常慢(而使用局域网内部的 Windows 服务器则运行得更好)。

我只是无法想象,即使在最困难的时刻,客户端和服务器上也有如此充足的 CPU、RAM、HDD 和带宽资源可用,是什么导致它变慢。

说带宽未得到充分利用,我不仅知道客户端和服务器通过比实际使用的更大的通道连接到互联网(这使得它们之间的路由可能存在某种瓶颈),我还通过在客户端和服务器之间复制文件来测试它们之间的带宽。

答案1

我猜 Delphi 会计应用程序使用 SMB 连接到服务器。某些类型的应用程序使用基于文件的数据库:Access、Outlook PST、FoxPro、BTrieve 等。当客户端和服务器由 WAN 链接分隔时,这些应用程序通常表现不佳 - 即使是快速的 WAN 链接,延迟也会让您崩溃。这与使用 ODBC 和 SQL 驱动程序进行后端连接的应用程序形成鲜明对比;这些应用程序可以更好地处理一些延迟。

您说当服务器位于 LAN 上时,此操作可以正常工作,这确实表明了问题所在。因此,没有“修复”方法。

  1. 将该单个应用程序保留在您的 LAN 上或
  2. 在托管环境中构建 Windows TS,以便用户可以运行该应用程序,但从应用程序层到数据库层的访问具有低延迟。或者
  3. 重新编写应用程序,也许使用 Web 前端。可能行不通。

相关内容