本帖最后由 群发软件 于 2017-7-10 22:19 编辑
网站首页面用的是静态页 里面包含了不少js、css、图片。 能优化的地方都优化了。js、css的压缩、摆放的位置等。不知道还有没有别的什么提高的速度的方法。 另外有些jsp页面内循环，判断等逻辑标签使用的也很多 ，tomcat中放了十几个项目 ，是不是服务器也存在原因。
方法一：在servlet的init()方法中缓存数据
当应用服务器初始化servlet实例之后，为客户端请求提供服务之前，它会调用这个servlet的init()方法。在一个servlet的生命周期中，init()方法只会被调用一次。通过在init()方法中缓存一些静态的数据或完成一些只需要执行一次的、耗时的操作，就可大大地提高系统性能。
例如，通过在init()方法中建立一个JDBC连接池是一个最佳例子，假设我们是用jdbc2.0的DataSource接口来取得数据库连接，在通常的情况下，我们需要通过JNDI来取得具体的数据源。我们可以想象在一个具体的应用中，如果每次SQL请求都要执行一次JNDI查询的话，那系统性能将会急剧下降。解决方法是如下代码，它通过缓存DataSource，使得下一次SQL调用时仍然可以继续利用它：
以下是引用片段：
public class ControllerServlet extends HttpServlet{
private javax.sql.DataSource testDS = null;
public void init(ServletConfig config) throws ServletException {
super.init(config);
Context ctx = null;
try{
ctx = new InitialContext();
testDS = (javax.sql.DataSource)ctx.lookup("jdbc/testDS");
}catch(NamingException ne){ne.printStackTrace();}
}catch(Exception e){e.printStackTrace();}
}
public javax.sql.DataSource getTestDS(){
return testDS;
}
...
...
}
方法 2:禁止servlet和JSP 自动重载(auto-reloading)
Servlet/JSP提供了一个实用的技术，即自动重载技术，它为开发人员提供了一个好的开发环境，当你改变servlet和JSP页面后而不必重启应用服务器。然而，这种技术在产品运行阶段对系统的资源是一个极大的损耗，因为它会给JSP引擎的类装载器(classloader)带来极大的负担。因此关闭自动重载功能对系统性能的提升是一个极大的帮助。
方法 3: 不要滥用HttpSession
在很多应用中，我们的程序需要保持客户端的状态，以便页面之间可以相互联系。但不幸的是由于HTTP具有天生无状态性，从而无法保存客户端的状态。因此一般的应用服务器都提供了session来保存客户的状态。在JSP应用服务器中，是通过HttpSession对像来实现session的功能的，但在方便的同时，它也给系统带来了不小的负担。因为每当你获得或更新session时，系统者要对它进行费时的序列化操作。你可以通过对HttpSession的以下几种处理方式来提升系统的性能。
如果没有必要，就应该关闭JSP页面中对HttpSession的缺省设置。 如果你没有明确指定的话，每个JSP页面都会缺省地创建一个HttpSession。如果你的JSP中不需要使用session的话，那可以通过如下的JSP页面指示符来禁止它：
以下是引用片段：
＜%@ page session="false"%＞
不要在HttpSession中存放大的数据对像：如果你在HttpSession中存放大的数据对像的话，每当对它进行读写时，应用服务器都将对其进行序列化，从而增加了系统的额外负担。你在HttpSession中存放的数据对像越大，那系统的性能就下降得越快。
当你不需要HttpSession时，尽快地释放它：当你不再需要session时，你可以通过调用HttpSession.invalidate()方法来释放它。尽量将session的超时时间设得短一点：在JSP应用服务器中，有一个缺省的session的超时时间。当客户在这个时间之后没有进行任何操作的话，系统会将相关的session自动从内存中释放。超时时间设得越大，系统的性能就会越低，因此最好的方法就是尽量使得它的值保持在一个较低的水平。
方法 4: 将页面输出进行压缩
压缩是解决数据冗余的一个好的方法，特别是在网络带宽不够发达的今天。有的浏览器支持gzip(GNU zip)进行来对HTML文件进行压缩，这种方法可以戏剧性地减少HTML文件的下载时间。因此，如果你将servlet或JSP页面生成的HTML页面进行压缩的话，那用户就会觉得页面浏览速度会非常快。但不幸的是，不是所有的浏览器都支持gzip压缩，但你可以通过在你的程序中检查客户的浏览器是否支持它。下面就是关于这种方法实现的一个代码片段：
以下是引用片段：
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
OutputStream out = null;
String encoding = request.getHeader("Accept-Encoding");
if (encoding != null && encoding.indexOf("gzip") != -1){
request.setHeader("Content-Encoding" , "gzip");
out = new GZIPOutputStream(request.getOutputStream());
}
else if (encoding != null && encoding.indexOf("comdivss") != -1){
request.setHeader("Content-Encoding" , "comdivss");
out = new ZIPOutputStream(request.getOutputStream());
}else{
out = request.getOutputStream();
}
...
...
}
方法 5: 使用线程池
应用服务器缺省地为每个不同的客户端请求创建一个线程进行处理，并为它们分派service()方法，当service()方法调用完成后，与之相应的线程也随之撤消。由于创建和撤消线程会耗费一定的系统资源，这种缺省模式降低了系统的性能。但所幸的是我们可以通过创建一个线程池来改变这种状况。
另外，我们还要为这个线程池设置一个最小线程数和一个最大线程数。在应用服务器启动时，它会创建数量等于最小线程数的一个线程池，当客户有请求时，相应地从池从取出一个线程来进行处理，当处理完成后，再将线程重新放入到池中。如果池中的线程不够地话，系统会自动地增加池中线程的数量，但总量不能超过最大线程数。通过使用线程池，当客户端请求急剧增加时，系统的负载就会呈现的平滑的上升曲线，从而提高的系统的可伸缩性。
方法 6: 选择正确的页面包含机制
在JSP中有两种方法可以用来包含另一个页面：
1、使用include指示符
以下是引用片段：
＜%@ includee file=”test.jsp” %＞
2、使用jsp指示符
以下是引用片段：
＜jsp:includee page=”test.jsp” flush=”true”/＞
在实际中发现，如果使用第一种方法的话，可以使得系统性能更高。
方法 7:正确地确定javabean的生命周期
JSP的一个强大的地方就是对javabean的支持。通过在JSP页面中使用jsp:useBean标签，可以将javabean直接插入到一个JSP页面中。它的使用方法如下：
以下是引用片段：
＜jsp:useBean id="name" scope="page|request|session|application"
class="package.className" type="typeName"＞
＜/jsp:useBean＞
其中scope属性指出了这个bean的生命周期。缺省的生命周期为page。如果你没有正确地选择bean的生命周期的话，它将影响系统的性能。
举例来说，如果你只想在一次请求中使用某个bean，但你却将这个bean的生命周期设置成了session，那当这次请求结束后，这个bean将仍然保留在内存中，除非session超时或用户关闭浏览器。这样会耗费一定的内存，并无谓的增加了JVM垃圾收集器的工作量。因此为bean设置正确的生命周期，并在bean的使命结束后尽快地清理它们，会使用系统性能有一个提高。
其它一些有用的方法
1、在字符串连接操作中尽量不使用“+”操作符：在java编程中，我们常常使用“+”操作符来将几个字符串连接起来，但你或许从来没有想到过它居然会对系统性能造成影响吧?由于字符串是常量，因此JVM会产生一些临时的对像。你使用的“+”越多，生成的临时对像就越多，这样也会给系统性能带来一些影响。解决的方法是用StringBuffer对像来代替“+”操作符。
2、避免使用System.out.println()方法：由于System.out.println()是一种同步调用，即在调用它时，磁盘I/O操作必须等待它的完成，因此我们要尽量避免对它的调用。但我们在调试程序时它又是一个必不可少的方便工具，为了解决这个矛盾，我建议你最好使用Log4j工具(http://Jakarta.apache.org )，它既可以方便调试，而不会产生System.out.println()这样的方法。
3、ServletOutputStream 与 PrintWriter的权衡：使用PrintWriter可能会带来一些小的开销，因为它将所有的原始输出都转换为字符流来输出，因此如果使用它来作为页面输出的话，系统要负担一个转换过程。而使用ServletOutputStream作为页面输出的话就不存在一个问题，但它是以二进制进行输出的。因此在实际应用中要权衡两者的利弊。
总结
本文的目的是通过对servlet和JSP的一些调优技术来极大地提高你的应用程序的性能，并因此提升整个J2EE应用的性能。通过这些调优技术，你可以发现其实并不是某种技术平台(比如J2EE和.NET之争)决定了你的应用程序的性能，重要是你要对这种平台有一个较为深入的了解，这样你才能从根本上对自己的应用程序做一个优化。
关于PHP和JSP的运行速度之比较，两者的起源地--美国的网路上已经争论了很长时间。给人的感觉是PHP社群总是说没有任何官方任何的测试标明JSP一定要比PHP快速，但是JSP社群也总是坚持编译执行的JSP在先天就比解释执行（由于Zend公司的努力，现在的PHP也应该是接近编译模式运行了）的PHP要快速。就我本人的观点，两者的运行速度比较实际上意义并没有想象中那么重大--在一个PHP的工程中，我们绝对依赖PHP；而在一个用到JSP的工程中，很多情况下JSP只是起到MVC模式中的表示或者控制的作用，真正的支持还在于其后真正的Java家族（比如Servlet，Bean甚至是EJB等等）。因此如果过分看重PHP和JSP在各自速度上的比较，可能并不能说明由该两种技术构建的工程的速度因素。（至于说是否存在完全由JSP构建的工程，我想是有的，不过希望以后维护这个工程的家伙不是我）
但是我还是做了几次有趣的测试--毕竟让代码们用数字展示各自的能力是一件很奇妙的事情，并且之前我也做过有关PHP代码速度测试和优化的工作，由此获得的一些成就感很容易让人忘记自己在其上花费了一夜时间。其实我做的工作也很简单，先是比较一些简单运算的速度，然后是测试和数据库连接的速度。我的用意是把前者比作一般的表示层和控制层的工作，而后者则被希望表示一般的逻辑层所作的工作。还是MVC模式。
开始测试
照例是要把测试的环境介绍一下，我采用了一台Linux（我的开发环境）和一台Windows（我的猪窝了）机器进行相同的测试（这样也可以顺便让Linux再羞辱Windows一次）--所谓相同是指代码的内容相同--非常感谢我喜欢的这两种语言都是跨平台的。具体的配置如下：
（猜猜看同样的代码在哪台机器上跑得快哪？下面你将会得到答案）
然后就是一些简单的Coding。我把写好的JSP放在了Linux平台上，首先是1000×1000次的算术运算操作，采用两个for循环完成它。这样的循环次数比较保守，因为我也不知道JSP究竟是否能在我不耐烦的按下浏览器的"停止"按钮之前执行完它们--可是事实却让我小小的吃惊了一次--在大约13毫秒左右的时间内这样数目巨大的循环被完成了。于是我又很不平衡的在两个循环的最大数后面各加了一个0--10000×10000次循环！不出我所料，等待的时间也不过是1.33-1.34秒左右。应该说，在没有写PHP的相关功能之前，我已经感觉到了JSP的强大速度优势。
好了，让我们再来看看PHP在Linux和Apache中的表现--1000×1000勉强通过，但是花费了竟然有5秒左右之巨；随后的10000×10000次测试真是一场灾难，我在页面中设置了PHP的执行时限为不限，但是结果是对于我来说这段代码真正的是不限时间的在孜孜不倦的运行，始终没有返回。OK，STOP IT！所以这一项测试没有结果。
在Windows平台的表现一样，不过看来速度都慢了一些，这个结果让我心理很安慰。
下面一项是连接和操作数据库的测试，我选择了MySQL。从上面的测试环境中可以看出在Linux机器上另有Oracle在运行着，但是有两个原因让我并没有使用Oracle参与测试，一是考虑到MySQL在Linux平台上已经得到了广泛的应用；二是Oracle在我周围的客户中使用并不多见。选择的数据库操作是SELECT，而且看来不能像普通的算术运算那样动辄就是1000×1000，我首先选择了10×10的二重循环。很明显，JSP在进行数据库操作时要比普通运算时慢了许多，让我等待了260毫秒左右；而当我鼓起勇气对JSP进行100×100测试之后，我才发现自己又陷于一场漫长的等待--最终29秒左右完成了这一操作。
对于PHP，我没有抱很大希望，先前的测试已经说明了PHP的普通运算能力确实有所欠缺。但是LAMP的组合又让我看到了速度的影子--实际的测试结果让我吃惊不小，10×10的测试PHP几乎在瞬间完成（85毫秒左右），而100×100的测试也仅仅花费了8.33秒左右。
以下是测试的条件和数据表，这里(speed_test.zip)可以下载测试用例：
结论
以上的测试只是我突发感慨而来的产物，那时我正在考虑一个简单的基于Web的商店是否值得完全使用JSP来实施--虽然我一直非常中意MVC模式并且在PHP中也引入了这样的概念，但是对于Web项目的"超快速开发"来说采用完全JSP倒也不失为达到目标并且可以有效保证项目的开发速度和运行速度的一种方式。于是我就想到了应该测试一下JSP和PHP的差距。不过结果并不能让我满意--在数据库的连接方面，借助JDBC可以达到数据库层的透明，但是速度上似乎有了许多的折扣；至于那种1000×1000的计算，如果有这样的网上商店会经常使用的话，我非常乐意认识一下这个项目的负责人并且好好学习一次。
因此，这次测试也许会让一些JSP的支持者失望，PHP从速度角度来说，我认为完全可以接受其应用在各种Web项目中。当然，对于电子商务以及其他关键应用采用何种技术的话题，已经超过了本文的范畴，我在这里只想多阐述一些我的观点：毫无疑问Java技术已经成为了以上这些关键应用的事实技术标准，因为她的丰富内涵和相对简单的开发以及产品的强壮性都非常容易被我们所接受；而显然将PHP和Java技术在Web上的应用相比是毫无道理的、结果也是非常明显的，同样将PHP和JSP相比也只是不合适的--JSP在整个Java战略中只是算不上核心的一块，而PHP哪--只有PHP，完全PHP。不过作为LAMP的一分子，越来越受到重视的PHP在中小型项目以及非关键应用中的能力不容怀疑。
|( 京ICP备09078825号 )
发表于 2017-7-10 22:17:26
收藏
