性能需求：用户和管理员
用户根据自己的体验来判断应用程序性能：
- 应用程序是否快速响应？
- 执行后台作时是否显示沙漏图标？
- 应用程序是否快速启动和关闭？
- 错误是否以可理解的方式进行处理？
总之，用户希望应用程序快速且可预测。
相比之下，管理员通常会判断应用程序使用网络资源的效率。 管理员可能会要求：
- 应用程序是否具有较低的开销和高效的网络使用情况？
- 是否使用了最小连接数，因此我的服务器可以一次性为尽可能多的用户提供服务？
- 我是否经常致电支持人员？
简言之，管理员希望应用程序能够缩放。
性能需求的最佳做法
开发 Windows 套接字应用程序时，这些性能要求将转换为有用的规则。
让网络应用程序快速初始化。
用户界面不应等待网络响应。 可以在网络可用或没有网络之前执行某些任务。 如果网络未响应，用户可能需要用户界面进行简单的作，例如关闭应用程序。
不要等待网络关闭。
正确编写的客户端-服务器应用程序可正常处理中止断开连接。 不要启动可能较长的作，例如将文件或文件夹与服务器同步，在关闭时无法中断。 网络不一致响应，因此即使是小型作也可能会证明耗时。 为用户提供积极反馈，包括进度指示和估计完成时间。
确保响应式用户界面。
应用程序响应能力有助于消除不必要的支持人员调用。 交互式响应的良好准则为 500 毫秒。 用户认为暂停时间超过 500 毫秒，因为性能滞后。 应用程序应足够响应，使用户对应用程序充满信心。
仔细检查网络错误。
并非所有网络错误都至关重要。 例如，已接收或发布其所有数据的应用程序在关闭连接时可能会忽略错误。 不要假定网络或用户可用;在不进行用户干预的情况下处理错误，或者如果错误是非关键性的，则忽略它们。
应用程序应定义自己的合理超时。
例如，在某些情况下，Windows 套接字连接请求可能会阻止多达 21 秒。 应用程序可能需要根据自己的用户引入自己的超时。
尽量减少协议开销。
节省网络带宽部分是关于最大程度地减少应用程序产生的协议开销。 它还涉及消除不必要的网络流量。 标头开销较低的协议可用于传输应用程序数据。 例如，发送少量的非关键数据或可重复数据时，请使用 UDP 而不是 TCP 来减少与建立和维护连接相关的开销。 如果必须将相同的数据发送到多个收件人，请考虑多播。 请注意，UDP 应用程序不受流控制-推送超出可用带宽可能会导致灾难性的网络故障。 Netstat 实用工具可与其 -e 和 -s 选项一起使用，以显示各种协议的统计信息。
节省系统资源。
如果未使用适当的约束，系统资源可以快速消耗。 例如，套接字和 TCP 连接使用资源。 不要在每个客户端使用多个 TCP 连接，其中一个连接将用于应用程序。
对于事务应用程序，良好的用户体验和低网络利用率并不是冲突的目标。 网络是瓶颈。 网络密集型应用程序花费更多时间等待，并且编写良好的网络应用程序旨在最大程度地减少用户界面和网络传输的不必要的等待时间。
相关主题