关于J2EE系统性能设计的基本思路..doc

关于J2EE系统性能设计的基本思路 任何一个J2EE的应用系统都摆脱不了下图的处理模式： 从这个图可以看出，要完成一项完整的功能必须经过“表现层==》界面逻辑层==》业务逻辑层==》数据访问层==》数据存储管理层”的处理，同时也依赖于具体的硬件设备支撑。这里假设我们都用好的硬件设备，不考虑硬件本身的性能问题，我们就考虑如何使用软件来充分利用有限的硬件资源提高我们的系统处理能力，下面我们将从纵向和横向逐层分析如何让系统处理最优化的。 从纵向切面分析 （一）、表现层 首先，可能你很想知道为什么我会将表现层从用户界面层分离出去。的确，从Windows应用程序的角度来看，表现层和用户界面是一回事：它们都是些可以与用户进行交互的图形用户接口。 然而，从Web程序的角度来看(或者从一个基于终端的程序来看)，区别应该是很明显的。典型地，浏览器仅仅是将内容显示给用户，并采集用户的输入信息。在这种情况下，所有实际的交互逻辑（产生内容输出或者分析用户输入的代码）都在Web服务器端运行(或者主框架中)，而不是在客户端机器上。 当然，在现实环境中，浏览器可能会运行JavaScript脚本或者是胖客户端代码。但是，这些代码都是不可信任的(译注：可以联想下客户端表单验证)。这些代码必须被视为与你运行于服务器端的代码进行交互的独立代码。所以，即使有代码运行于浏览器中，你的应用程序的用户界面代码仍然是运行于Web服务器上的。 因此，这里的表现层主要指的是运行于客机器上的HTML、JS脚本、ACTIVEX控件等，表现层更侧重于用户的界面友好交互，提高表现层性能主要是提高HTML网页、JS等效率，可以采取以下思路： 对于经常不变化的一些HTML、图片等文件缓存在本地PC机上，减少网络交互的数据量，同时，也提高了界面载入的效率。 优化整理界面行为，避免总是跳来跳去，一次业务用尽量少的界面去实现，一个界面尽量呈现更多的业务功能，以提高用户的交互效率，增强用户体验。 分析每一种业务，对于一些完全可以在客户机处理的逻辑尽量在客户本地运算（比如：一般基本的数据从服务器获取，而需要通过四则公式运算出来的合计数、平均值等则移动到客户本地运算），从而降低WEB服务器的负荷。 对于一些耗费性能和CPU的大运算块，能够在本地完成的（或者需要少量的服务端数据本地就可以完成）也尽量就在本地完成，这也许用JS处理效率也很低下，这时候可以采用ACTIVEX控件来完成。 合理利用COOKIE等浏览器本身的机制，在客户端本地构建全局内存区，降低WEB服务器SESSION共享全局数据的压力。 （二）、界面逻辑层 与表现层相对应的就是界面逻辑层，也称为WEB服务器层（假如用STRUTS框架开发，那么就是STRUTS ACTION和FORM层的逻辑）。这一层涉及到具体的页面参数的校验、预加工和页面流的管理控制等操作。 这一层也是系统请求接入层，压力非常的大，要应付千千万万的客户机的访问，对于请求接入性能要求是非常高的。也许你会说接入性能完全取决于WEBLOGIC这些基础应用服务器，其实这只是一方面，WEBLOGIC解决的只是接入控制，我们可以通过WEBLOGIC集群扩大并行接入的请求线程数，但是我们总不能集群N台WEBLOGIC，无论从硬件和软件方面考虑都是不允许的，而真正需要提升的是我们界面逻辑层软件处理的性能，从软件层面我们可以采取以下思路（下面的部分思路摘自YAHOO网站优化思路）： Minimize HTTP Requests 减少HTTP请求： 图片、CSS、script、flash等等这些都会增加http请求数，减少这些元素的数量就能减少响应时间。把多个JS、CSS在可能的情况下写进一个文件，页面里直接写入图片也是不好的做法，应该写进CSS里，利用 CSS sprites 将小图拼合后利用background来定位。 Use a Content Delivery Network 利用CDN技术 Add an Expires or a Cache-Control Header 设置头文件过期或者静态缓存 浏览器会用缓存来减少http请求数来加快页面加载的时间，如果页面头部加一个很长的过期时间，浏览器就会一直缓存页面里的元素。不过这样如果页面里的东西变动的话就要改名字了，否则用户端不会主动刷新，看自己衡量了~ 这项可以通过修改.htaccess文件来实现。 Gzip Components Gzip压缩 Gzip格式是一种很普遍的压缩技术，几乎所有的浏览器都有解压Gzip格式的能力，而且它可以压缩的比例非常大，一般压缩率为85%。 Put Stylesheets at the Top 把CSS放顶部 让浏览者能尽早的看到网站的完整样式。 Put Scripts at the