第 8 章 — 智能客户端应用程序性能                 

智能客户端应用程序可以提供比 Web 应用程序更丰富和响应速度更快的用户界面，并且可以利用本地系统资源。如果应用程序的大部分驻留在用户的计算机上，则应用程序不需要到 Web 服务器的持续的往返行程。这有利于提高性能和响应性。然而，要实现智能客户端应用程序的全部潜能，您应该在应用程序的设计阶段仔细考虑性能问题。通过在规划和设计您的应用程序时解决性能问题，可以帮助您及早控制成本，并减小以后陷入性能问题的可能性。

注改善智能客户端应用程序的性能并不仅限于应用程序设计问题。您可以在整个应用程序生存期中采取许多个步骤来使 .NET 代码具有更高的性能。虽然 .NET 公共语言运行库 (CLR) 在执行代码方面非常有效，但您可以使用多种技术来提高代码的性能，并防止在代码级引入性能问题。有关这些问题的详细信息，请参阅http://msdn.microsoft.com/perf。

在应用程序的设计中定义现实的性能要求并识别潜在的问题显然是重要的，但是性能问题通常只在编写代码之后对其进行测试时出现。在这种情况下，您可以使用一些工具和技术来跟踪性能问题。

本章分析如何设计和调整您的智能客户端应用程序以获得最佳性能。它讨论了许多设计和体系结构问题（包括线程处理和缓存注意事项），并且分析了如何增强应用程序的 Windows 窗体部分的性能。本章还介绍了您可以用来跟踪和诊断智能客户端应用程序性能问题的一些技术和工具。

针对性能进行设计

您可以在应用程序设计或体系结构级完成许多工作，以确保智能客户端应用程序具有良好的性能。您应该确保在设计阶段尽可能早地制定现实的且可度量的性能目标，以便评估设计折衷，并且提供最划算的方法来解决性能问题。只要可能，性能目标就应该基于实际的用户和业务要求，因为这些要求受到应用程序所处的操作环境的强烈影响。性能建模是一种结构化的且可重复的过程，您可以使用该过程来管理您的应用程序并确保其实现性能目标。有关详细信息，请参阅 Improving .NET Application Performance and Scalability 中的第 2 章“Performance Modeling”，网址为：http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt02.asp。

智能客户端通常是较大的分布式应用程序的组成部分。很重要的一点是在完整应用程序的上下文中考虑智能客户端应用程序的性能，包括该客户端应用程序使用的所有位于网络中的资源。微调并优化应用程序中的每一个组件通常是不必要或不可能的。相反，性能调整应该基于优先级、时间、预算约束和风险。一味地追求高性能通常并不是一种划算的策略。

智能客户端还将需要与用户计算机上的其他应用程序共存。当您设计智能客户端应用程序时，您应该考虑到您的应用程序将需要与客户端计算机上的其他应用程序共享系统资源，例如，内存、CPU 时间和网络利用率。

注有关设计可伸缩的高性能远程服务的信息，请参阅Improving .NET Performance and Scalability，网址为：http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenet.asp。本指南包含有关如何优化 .NET 代码以获得最佳性能的详细信息。

要设计高性能的智能客户端，请考虑下列事项：

在适当的位置缓存数据。数据缓存可以显著改善智能客户端应用程序的性能，使您可以在本地使用数据，而不必经常从网络检索数据。但是，敏感数据或频繁更改的数据通常不适合进行缓存。

优化网络通讯。如果通过“健谈的”接口与远程层服务进行通讯，并且借助于多个请求/响应往返行程来执行单个逻辑操作，则可能消耗系统和网络资源，从而导致低劣的应用程序性能。

有效地使用线程。如果您使用用户界面 (UI) 线程执行阻塞 I/O 绑定调用，则 UI 似乎不对用户作出响应。因为创建和关闭线程需要系统开销，所以创建大量不必要的线程可能导致低劣的性能。

有效地使用事务。如果客户端具有本地数据，则使用原子事务可帮助您确保该数据是一致的。因为数据是本地的，所以事务也是本地的而不是分布式的。对于脱机工作的智能客户端而言，对本地数据进行的任何更改都是暂时的。客户端在重新联机时需要同步更改。对于非本地数据而言，在某些情况下可以使用分布式事务（例如，当服务位于具有良好连接性的同一物理位置并且服务支持它时）。诸如 Web 服务和消息队列之类的服务不支持分布式事务。

优化应用程序启动时间。较短的应用程序启动时间使用户可以更为迅速地开始与应用程序交互，从而使用户立刻对应用程序的性能和可用性产生好感。应该对您的应用程序进行适当的设计，以便在应用程序启动时仅加载那些必需的程序集。因为加载每个程序集都会引起性能开销，所以请避免使用大量程序集。

有效地管理可用资源。低劣的设计决策（例如，实现不必要的完成器，未能在 Dispose 方法中取消终止，或者未能释放非托管资源）可能导致在回收资源时发生不必要的延迟，并且可能造成使应用程序性能降低的资源泄漏。如果应用程序未能正确地释放资源，或者应用程序显式强制进行垃圾回收，则可能会妨碍 CLR 有效地管理内存。

优化 Windows 窗体性能。智能客户端应用程序依靠 Windows 窗体来提供内容丰富且响应迅速的用户界面.您可以使用多种技术来确保 Windows 窗体提供最佳性能。这些技术包括降低用户界面的复杂性，以及避免同时加载大量数据。

在许多情况下，从用户角度感受到的应用程序性能起码与应用程序的实际性能同样重要。您可以通过对设计进行某些特定的更改来创建在用户看来性能高得多的应用程序，例如：使用后台异步处理（以使 UI 能作出响应）；显示进度栏以指示任务的进度；提供相应的选项以便用户取消长期运行的任务。

数据缓存原则

缓存是一种能够改善应用程序性能并提供响应迅速的用户界面的重要技术。您应该考虑下列选项：

? 缓存频繁检索的数据以减少往返行程。如果您的应用程序必须频繁地与网络服务交互以检索数据，则应该考虑在客户端缓存数据，从而减少通过网络重复获取数据的需要。这可以极大地提高性能，提供对数据的近乎即时的访问，并且消除了可能对智能客户端应用程序性能造成不利影响的网络延迟和中断风险。

? 缓存只读引用数据。只读引用数据通常是理想的缓存对象。此类数据用于提供进行验证和用户界面显示所需的数据，例如，产品说明、ID 等等。因为客户端无法更改此类数据，所以通常可以在客户端缓存它而无须进行任何进一步的特殊处理。

? 缓存要发送给位于网络上的服务的数据。您应该考虑缓存要发送给位于网络上的服务的数据。例如，如果您的应用程序允许用户输入由在多个窗体中收集的一些离散数据项组成的定单信息，则请考虑允许用户输入全部数据，然后在输入过程的结尾在一个网络调用中发送定单信息。

? 尽量少地缓存高度不稳定的数据。在缓存任何不稳定的数据之前，您需要考虑在其变得陈旧或者由于其他原因变得不可用之前，能够将其缓存多长时间。如果数据高度不稳定并且您的应用程序依赖于最新信息，则或许只能将数据缓存很短一段时间（如果可以缓存）。

? 尽量少地缓存敏感数据。您应该避免在客户端上缓存敏感数据，因为在大多数情况下，您无法保证客户端的物理安全。但是，如果您必须在客户端上缓存敏感数据，则您通常将需要加密数据，该操作本身也会影响性能。

网络通讯原则

您将面临的另一个决策是如何设计和使用网络服务，例如，Web 服务。特别地，您应该考虑与网络服务交互的粒度、同步性和频率。要获得最佳的性能和可伸缩性，您应该在单个调用中发送更多的数据，而不是在多个调用中发送较少量的数据。例如，如果您的应用程序允许用户在定单中输入多个项，则较好的做法是为所有项收集数据，然后将完成的采购定单一次性发送给服务，而不是在多个调用中发送单个项的详细信息。除了降低与进行大量网络调用相关联的系统开销以外，这还可以减少服务和/或客户端内的复杂状态管理的需要。

线程处理原则

在应用程序内使用多个线程可能是一种提高其响应性和性能的好方法。特别地，您应该考虑使用线程来执行可以在后台安全地完成且不需要用户交互的处理。通过在后台执行此类工作，可以使用户能够继续使用应用程序，并且使应用程序的主用户界面线程能够维持应用程序的响应性。

适合于在单独的线程上完成的处理包括：

? 应用程序初始化。请在后台线程上执行漫长的初始化，以便用户能够尽快地与您的应用程序交互，尤其是在应用程序功能的重要或主要部分并不依赖于该初始化完成时。

? 远程服务调用。请在单独的后台线程上通过网络进行所有远程调用。很难（如果不是无法）保证位于网络上的服务的响应时间。在单独的线程上执行这些调用可以减少发生网络中断或延迟的风险，从而避免对应用程序性能造成不利影响。

? IO 绑定处理。应该在单独的线程上完成诸如在磁盘上搜索和排序数据之类的处理。通常，这种工作要受到磁盘 I/O 子系统而不是处理器可用性的限制，因此当该工作在后台执行时，您的应用程序可以有效地维持其响应性。

尽管使用多个线程的性能好处可能很显著，但需要注意，线程使用它们自己的资源，并且使用太多的线程可能给处理器（它需要管理线程之间的上下文切换）造成负担。要避免这一点，请考虑使用线程池，而不是创建和管理您自己的线程。线程池将为您有效地管理线程，重新使用现有的线程对象，并且尽可能地减小与线程创建和处置相关联的系统开销。

如果用户体验受到后台线程所执行的工作的影响，则您应该总是让用户了解工作的进度。以这种方式提供反馈可以增强用户对您的应用程序的性能的感觉，并且防止他或她假设没有任何事情发生。请努力确保用户可以随时取消漫长的操作。

事务原则

事务可以提供重要的支持，以确保不会违反业务规则并维护数据一致性。事务可以确保一组相关任务作为一个单元成功或失败。您可以使用事务来维护本地数据库和其他资源（包括消息队列的队列）之间的一致性。

对于需要在网络连接不可用时使用脱机缓存数据的智能客户端应用程序，您应该将事务性数据排队，并且在网络连接可用时将其与服务器进行同步。

您应该避免使用涉及到位于网络上的资源的分布式事务，因为这些情况可能导致与不断变化的网络和资源响应时间有关的性能问题。如果您的应用程序需要在事务中涉及到位于网络上的资源，则应该考虑使用补偿事务，以便使您的应用程序能够在本地事务失败时取消以前的请求。尽管补偿事务在某些情况下可能不适用，但它们使您的应用程序能够按照松耦合方式在事务的上下文内与网络资源交互，从而减少了不在本地计算机控制之下的资源对应用程序的性能造成不利影响的可能性。

性能调整和诊断

在设计和实现阶段处理性能问题是实现应用程序性能目标的最划算的方法。但是，您只有在开发阶段经常且尽早测试应用程序的性能，才能真正有效地优化应用程序的性能。

尽管针对性能进行设计和测试都很重要，但在这些早期阶段优化每个组件和所有代码不是有效的资源用法，因此应该予以避免。所以，应用程序可能存在您在设计阶段未预料到的性能问题。例如，您可能遇到由于两个系统或组件之间的无法预料的交互而产生的性能问题，或者您可能使用原来存在的、未按希望的方式执行的代码。在此情况下，您需要追究性能问题的根源，以便您可以适当地解决该问题。

本节讨论一些将帮助您诊断性能问题以及调整应用程序以获得最佳性能的工具和技术。

制定性能目标

当您设计和规划智能客户端应用程序时，您应该仔细考虑性能方面的要求，并且定义合适的性能目标。在定义这些目标时，请考虑您将如何度量应用程序的实际性能。您的性能度量标准应该明确体现应用程序的重要性能特征。请努力避免无法准确度量的模糊或不完整的目标，例如，“应用程序必须快速运行”或“应用程序必须快速加载”。您需要了解应用程序的性能和可伸缩性目标，以便您可以设法满足这些目标并且围绕它们来规划您的测试。请确保您的目标是可度量的和可验证的。

定义良好的性能度量标准使您可以准确跟踪应用程序的性能，以便您可以确定应用程序是否能够满足它的性能目标。这些度量标准应该包括在应用程序测试计划中，以便可以在应用程序的测试阶段度量它们。

本节重点讨论与智能客户端应用程序相关的特定性能目标的定义。如果您还要设计和生成客户端应用程序将消耗的网络服务，则您还需要为这些服务定义适当的性能目标。在此情况下，您应该确保考虑整个系统的性能要求，以及应用程序各个部分的性能与其他部分以及整个系统之间存在怎样的关系。

考虑用户的观点

当您为智能客户端应用程序确定合适的性能目标时，您应该仔细考虑用户的观点。对于智能客户端应用程序而言，性能与可用性和用户感受有关。例如，只要用户能够继续工作并且获得有关操作进度的足够反馈，用户就可以接受漫长的操作。

在确定要求时，将应用程序的功能分解为多个使用情景或使用案例通常是有用的。您应该识别对于实现特定性能目标而言关键且必需的使用案例和情景。应该将许多使用案例所共有且经常执行的任务设计得具有较高性能。同样，如果任务要求用户全神贯注并且不允许用户从其切换以执行其他任务，则需要提供优化的且有效的用户体验。如果任务不太经常使用且不会阻止用户执行其他任务，则可能无须进行大量调整。

对于您识别的每个性能敏感型任务，您都应该精确地定义用户的操作以及应用程序的响应方式。您还应该确定每个任务使用的网络和客户端资源或组件。该信息将影响性能目标，并且将驱动对性能进行度量的测试。

可用性研究提供了非常有价值的信息源，并且可能大大影响性能目标的定义。正式的可用性研究在确定用户如何执行他们的工作、哪些使用情景是共有的以及哪些不是共有的、用户经常执行哪些任务以及从性能观点看来应用程序的哪些特征是重要的等方面可能非常有用。如果您要生成新的应用程序，您应该考虑提供应用程序的原型或模型，以便可以执行基本的可用性测试。

考虑应用程序操作环境

对应用程序的操作环境进行评估是很重要的，因为这可能对应用程序施加必须在您制定的性能目标中予以反映的约束。

位于网络上的服务可能对您的应用程序施加性能约束。例如，您可能需要与您无法控制的 Web 服务进行交互。在这种情况下，需要确定该服务的性能，并且确定这是否将对客户端应用程序的性能产生影响。

您还应该确定任何相关服务和组件的性能如何随着时间的变化而变化。某些系统会经受相当稳定的使用，而其他系统则会在一天或一周的特定时间经受变动极大的使用。这些区别可能在关键时间对应用程序的性能造成不利影响。例如，提供应用程序部署和更新服务的服务可能会在星期一早上 9 点缓慢响应，因为所有用户都在此时升级到应用程序的最新版本。

另外，还需要准确地对所有相关系统和组件的性能进行建模，以便可以在严格模拟应用程序的实际部署环境的环境中测试您的应用程序。对于每个系统，您都应该确定性能概况以及最低、平均和最高性能特征。然后，您可以在定义应用程序的性能要求时根据需要使用该数据。

您还应该仔细考虑用于运行应用程序的硬件。您将需要确定在处理器、内存、图形功能等方面的目标硬件配置，或者至少确定一个如果得不到满足则无法保证性能的最低配置。

使用性能日志和警报

性能日志和警报是作为 Windows 操作系统的一部分发行的一种管理性能监控工具。它依靠由各种 Windows 组件、子系统和应用程序发布的性能计数器，使您可以跟踪资源使用情况以及针对时间以图形方式绘制它们。

您可以使用 Performance Logs and Alerts 来监控标准的性能计数器（例如，内存使用情况或处理器使用情况），或者您可以定义您自己的自定义计数器来监控应用程序特定的活动。

全文结束