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