分类： 系统运维
2008-05-31 13:18:19
常见WebSphere应用系统的概念结构如图1-6所示。
WebSphere应用首先是一个Java程序，所以，应该遵从Java程序的高性能编程规范。
WebSphere应用是构建在WebSphere应用服务器基础上的，所以，WebSphere应用的性能很大程度上依赖于WebSphere应用服务器的性能。WebSphere应用的开发人员应该理解WebSphere的编程接口，遵从WebSphere应用程序的高性能编程规范。WebSphere应用的开发人员（或维护人员）还应该掌握WebSphere应用服务器的各种配置参数，通过参数调整保证WebSphere应用服务器工作在高性能状态。如果WebSphere应用服务器本身就工作不正常，很难期望上层的WebSphere应用程序工作正常。
图1-6 常见WebSphere应用系统的概念结构
WebSphere应用服务器和WebSphere应用程序一样是一个Java程序，需要依赖于特定的JDK才能正常工作。深入优化WebSphere应用系统的性能，很多时候要从JDK入手。虽然WebSphere应用服务器已经屏蔽了很多JDK的实现细节，但是了解JDK的工作机理对于解决很多性能问题都是非常必要的（尤其是Java内存使用问题）。
除了WebSphere应用服务器，WebSphere应用程序往往还需要依赖很多其他类型的服务器才能正常工作（最常见的是数据库服务器和Web服务器）。保证这些服务器高性能工作是整个WebSphere应用系统正常运行的必要前提。作者遇到的很多性能问题都不是WebSphere应用服务器的问题，而是数据库服务器端的问题。
无论WebSphere应用程序、WebSphere应用服务器还是数据库服务器都是软件程序，它们都必须运行在一定的系统硬件之上。没有高性能的硬件支持，WebSphere应用系统不可能高效地工作。读者可以想象一下要求一台运行在个人电脑上的WebSphere应用支持一个大型企业的业务负载会出现怎样的结果。
最后，在多数情况下，一个WebSphere应用往往需要与其他应用系统（很可能是非WebSphere应用）协同工作。这些应用包括其他业务系统或非业务系统。如果这些系统和WebSphere应用工作在同一个硬件环节中，那么，这些系统就可能和WebSphere应用系统竞争硬件资源。即使没有竞争资源的情况，WebSphere应用和外部系统的接口乃至外部系统本身的性能都有可能影响到WebSphere应用自身的性能表现。
作者参与的电子商务应用中有很多这样的例子。比如在一个客户的解决方案中，支付系统（Payment）是由第三方软件厂商提供的。电子商务应用中与该第三方支付系统的接口存在并发性问题。在客户遇到高峰负载的情况下，这个支付系统的接口崩溃了。结果几乎所有的交易都不能正常完成。一个看起来并不起眼的程序模块造成了非常严重的性能问题。在另一个案例中，作者开发的电子商务应用需要和第三方的LDAP（Light Directory Access Protocol，轻量级目录访问协议）系统协同工作，所有的用户都必须经过LDAP系统的身份认证才能登录到网上商店进行操作。但这个LDAP系统存在严重的性能问题，负载稍微大一些就会崩溃。导致作者部署的电子商务应用也不能在较大的负载下工作。尽管这不是WebSphere应用自身的问题，但最终的现象是整个系统的性能问题。毕竟最终用户直接看到的是WebSphere应用的性能表现，他们并不关心具体的性能问题是不是由WebSphere应用程序自身引起的。
因此，关注WebSphere应用的性能绝不能只关注应用程序本身或者应用服务器本身。必须对组成WebSphere应用系统的结构有清楚的认识，有能力对系统各个部分出现的性能问题加以辨别和处理。当然，WebSphere应用系统的高性能工作并不一定要求系统的每一个部分都工作在最佳状态。整个系统的性能往往是由性能最差的环节（即所谓瓶颈）决定的。正确辨别系统的性能瓶颈，当瓶颈位于WebSphere应用程序之外时能够加以解决，只有如此才能构建高性能的WebSphere 企业级应用。性能监视是发现性能问题，识别性能瓶颈的重要途径，本书第二部分将详细介绍性能监视的有关内容。
本书强调的第二个观点是：提高性能是一个贯穿WebSphere应用生命周期的过程，决不能等到系统投入生产运行之后再来考虑性能问题。那样做的结果几乎注定会在生产运行中遇到严重的性能问题。而且如前面虚构场景中描述的那样，解决这些性能问题往往需要对整个系统重新设计，甚至将整个系统推倒重来。
作者认为，WebSphere应用系统的生命周期如图1-7所示。
图1-7 WebSphere应用系统的生命周期
应用系统的生命周期大致可以分为四个阶段：需求与设计、实现、测试与评估、部署与运行。作者将这四个阶段表示为一个封闭的环形，因为实际系统往往是一个螺旋式上升的过程，对应于产品的各个版本或项目的各个实施阶段。
作者认为，提高WebSphere应用系统的性能要从生命周期的每一个阶段着手。
在需求与设计阶段就要考虑性能。首先是性能规划，制定系统的软硬件结构。其次是性能设计，概要设计阶段要制定高性能的编程模型（Programming model），详细设计文档中也要对性能充分考虑。
在系统实现阶段，需要高性能编程。系统的每一段代码都要考虑到对性能的影响，尤其是比较底层或者频繁被调用的代码。任何一段没有经过性能优化的代码都有可能成为最终系统的性能瓶颈。
在测试与评估阶段，应该进行充分的性能测试。只有通过性能测试才能验证针对性能的设计和编码是否有效。性能测试阶段往往需要对被测试的系统进行性能监视，以确定系统是否存在性能问题。
在部署（Deployment）和维护阶段，要对系统进行严密的性能监视。发现了性能问题要尽快进行问题诊断，对于相当一部分性能问题，可以考虑通过性能参数调优解决。
最终系统在生产环境中出现的性能问题会被反馈到需求和设计阶段，成为下一次性能规划或性能设计的依据。
本书第二部分将依次介绍各个生命周期中与性能相关的各种活动：从性能规划到性能参数调优。相对而言，本书对性能设计和高性能编码的论述并不太多。这是因为大部分讲述WebSphere应用性能的资料都会提到开发相关的内容，本书作者觉得没有必要重复这些内容。此外，通过本书第三部分讨论的各种性能问题，读者也能够了解到如何从设计和编码角度避免这些性能问题。
本书强调的第三个观点是：提供WebSphere应用系统的性能需要参与应用系统生命周期的各种角色人员的协同努力，不能片面地认为出现性能问题是某个角色（比如性能测试人员）的责任。
开发人员（包括设计人员）和测试人员是构建WebSphere应用最常见的角色。一般来说，开发人员负责性能设计和实现，测试人员负责性能测试。很多人认为开发人员和测试人员是一对矛盾。作者则更愿意把他们看作相互依存的整体。开发人员需要测试人员帮助他们发现问题，测试人员需要开发人员解决发现的问题。作者认为，开发人员和测试人员应该相互了解对方的工作，并协助对方的工作。比如性能测试人员应该在设计阶段审阅设计文档，确保设计中有针对性能的考虑；开发人员应该审阅性能测试人员的测试计划，确保测试计划能够覆盖应有的范围（覆盖可能存在性能问题的方面）。
实施人员（包括技术支持和服务人员）是构建高性能WebSphere应用的另一个重要角色。对于较小的产品或项目，实施人员与开发和测试人员可能隶属于同一个团队（甚至是同一个人）。对于比较大的产品或项目，则可能有专门的实施团队。实施人员需要对所实施应用的开发模型有比较清楚的了解，这样才能在实施过程中进行正确的配置。实施人员往往还需要在系统投入生产运行之前对系统进行最后的性能评估，所以，实施人员也需要有良好的性能测试知识。
构建高性能系统还有一个重要的角色是维护人员。维护人员通常与开发和测试人员属于不同的组织机构。以电子商务应用为例，大部分部署案例的维护人员隶属于客户的IT部门。运行维护人员的主要职责是对系统进行性能监视和性能调优。但维护人员也需要对所监视的WebSphere应用的内部机制有一定程度的了解，这样，才能对比较简单的性能问题进行正确的问题诊断和相应处理。
此外，比较大型的企业级产品或系统中还有一个专门的角色：性能架构师（Performance Architect）。性能架构师往往专门负责系统的性能规划和性能设计，他们也往往负责重大性能问题的诊断与解决。
本书第二部分将介绍WebSphere应用生命周期中的各种性能活动，不同的角色各有自己负责的活动。各角色的人员可以根据自身需要有选择地阅读对应章节。但本书推荐各角色人员都不要仅限于了解自己所负责的性能活动内容，也应该了解其他角色负责的活动内容，这样才能更好地完成份内的工作。
表1-1是作者推荐的各角色人员对各种性能活动的掌握程度。
表1-1 性能角色与性能活动
|
|
性能规划 |
性能设计与编程 |
性能测试 |
性能监视 |
性能问题诊断 |
性能参数调优 |
|
性能架构师 |
精通 |
熟悉 |
熟悉 |
熟悉 |
精通 |
精通 |
|
开发人员 |
熟悉 |
精通 |
了解 |
熟悉 |
熟悉 |
了解 |
|
性能测试人员 |
了解 |
了解 |
精通 |
熟悉 |
熟悉 |
熟悉 |
|
实施人员 |
了解 |
了解 |
熟悉 |
熟悉 |
熟悉 |
精通 |
|
维护人员 |
了解 |
了解 |
了解 |
精通 |
熟悉 |
熟悉 |
