Tomcat、Jetty和Glassfish性能测试( 四 ) _Tomcat

文章插图

可以看到请求平均处理响应时间为26809ms
10线程测试（1）
测试端口为8088，线程数为10，循环次数为100线程间请求的允许的间隔时间为0，也就是立即建立10个线程发起请求。下面是测试结果：

文章插图

可以看到请求平均处理响应时间为6110ms
2.3.3 Tomcat测试100线程测试（1）
测试的端口为8888，线程数为100，循环次数为10线程间请求的允许的间隔时间为10，也就是10秒钟内建立100个线程发起请求。下面是测试结果：

文章插图

可以看到请求平均处理响应时间为30078ms
100线程测试（2）
测试端口为8888，线程数为100，循环次数为10线程间请求的允许的间隔时间为5，也就是5秒内建立100个线程发起请求。下面是测试结果：

文章插图

可以看到请求平均处理响应时间为32510ms
100线程测试（3）
测试端口为8888，线程数为100，循环次数为10线程间请求的允许的间隔时间为0，也就是立即有100个线程同时发起请求。下面是测试结果：

文章插图

可以看到请求平均处理响应时间为30871ms
50线程测试（1）
测试端口为8888，线程数为50，循环次数为20线程间请求的允许的间隔时间为0，也就是立即建立50个线程发起请求。下面是测试结果：

文章插图

可以看到请求平均处理响应时间为25443ms
10线程测试（1）
测试端口为8888，线程数为10，循环次数为100线程间请求的允许的间隔时间为0，也就是立即建立10个线程发起请求。下面是测试结果：

文章插图

可以看到请求平均处理响应时间为2745ms
3 讨论与总结在第2章给出了丰富的测试数据。测试的重点以高并发的情况为主，也就是100线程的情况，分别每个应用服务器都做了三次测试。我们对比这些测试数据，可以看出无论是在windows还是在linux环境下，glassfish对高并发的处理比jetty和tomcat都要好一些，jetty与tomcat对高并发的处理能力相比相差不大。而在50线程并发请求的时候，我们发现这个差距缩小了，直到在10线程这种低并发请求的情况中，三个应用服务器的处理性能却又反了过来。我们可以清楚地看到，tomcat的处理能力比jetty更好，而glassfish的处理能力变得较弱。与此同时，我们还可以看到相对于windows7，CentOS7server中应用服务器的表现更加出色，响应时间更短，即使centos7server只是运行在虚拟机之中。
应用服务器的性能需要参考的数据远远不是一个并发请求响应时间能解决的，还有对jetty与glassfish的部署与设置，每个应用服务器的标准都不同，例如jetty对servlet标准的严格检查，令我们在glassfish和tomcat下能运行的项目，在jetty中都不能部署起来。例如glassfish，对高并发的情景处理的较好，拥有一个十分强大的项目和服务器管理程序，而这以为的优点却也换来了处理一般情况的能力却不如其他应用服务器的缺点。又如我在第一章所介绍的，为什么处在中庸的jetty在2014年统计的应用服务器选择上，占有率能排第二，因为它的特点更加地聚焦于成为一个嵌入式的服务器，将一些非原本需要通过socket或者其他方式连接的非web业务逻辑封装成一个servlet 。结合实际来说就像我们正在使用的上传编译工具，有一部分文件处理和调用cmd命令的代码便是用socket与我们的java服务端连接，这种形式的连接，使用jetty便可以轻松的替换，并且不用考虑更多的字符编码问题，以及socket的编写和参数的处理。这次的研究，对于三种应用服务器无法评价出哪一款更适合我们的APP，因为还有很多的因素需要去参考。例如，稳定性，安全性，伸缩性等等。
最后，我需要说明的是，这些测试数据只能提供一个简单的参考。这些数据是在本地开发环境的数据库与我自己的电脑环境得到的，因此这些结论只能当作一个趋势的参考。真正生产环境的服务器性能测试也许会和本次测试有出入，并且如果要正真的模拟服务器的整个工作，我们所选取的随机请求也不能只是三个有代表性的连接，而应该是通过实际环境每个功能被请求的次数，来模拟真正的服务器性能测试，以达到一个更为精确的结果，让我们可以从中来调优我们的应用服务器，以及选取更好的server环境。