apache+tomcat+mysqlproxy性能评估
转自： http://hi.baidu.com/xuwanbest/blog/item/f3f8fca1e4d34c8e461064db.html看了两个星期软件性能测试的东西，一来是项目需要用来评论（证明）系统的性能，二来是为了从一个具体的例子系统中学习一下影响性能的因素。 实验平台用了Apache+Tomcat+MySQL，在上面跑了一个开源的blog系统（roller）。使用JMeter模拟客户端请求产生压力，根据响应时间来评价用户体验到的性能。
关于性能测试的相关知识，可以看《软件性能测试过程详解与案例剖析》或者在这里的一系列文章。从里面摘出来一个图片，简要说明响应时间与性能的关系。
http://www.cnblogs.com/images/cnblogs_com/jackei/33219/o_modified-001.jpg
如上图所示，其实对于一个多用户服务系统来说，随着并发用户数（x轴）的增加，响应时间其实分为三段；第一段，当用户数量比较少，其实就是系统资源占用率不断提高，用户响应时间开始线性增长。第二段，系统资源利用已经饱和，响应时间因为并发调度以及资源争用等的开销而更快得增长。最后一段，用户连接在accept队列或者别的系统队列中堆积，所以响应时间需要加上排队等待服务器接收请求的时间而显现出更陡峭的增长。
所以性能测试只需要测得图中两个拐点，一个是系统利用率接近饱和的并发用户数，另外一个是响应时间增长陡然变快的点。这两个点确定基本就能表征系统的性能。
Tomcat
目前实验所得的结果，由于用了个很小的数据库，所以MySQL方面基本不成问题。但是，Tomcat的性能却实在不敢恭维。虽然实现上极度的面向对象，修改扩展很容易，虽然配置上也合理且灵活，虽然升级迅速支持最新的JSP和Servlet标准，虽然功能齐全而强大，但是也掩盖不住Tomcat本身性能不高的事实。当然，我也承认我配置Tomcat方面可能还是没有使之发挥最高性能。但Tomcat为每一个请求开一个线程来处理的做法，使得并发用户多的时候系统堆积了大量等待CPU时间的线程，其中还包括与数据库连接的线程。大量的线程带来了巨大的并发调度开销，以至于系统很快就进入瘫痪状态。
MySQL Proxy
用MySQL做数据库只能使用读写分离的主从副本进行分布式复制，如果要不改变原来程序，那么就只能在后面加个中间层来判断查询的类型然后进行转发。而其中一个比较常用的实现就是MySQL Proxy。不过这个东西本身不是为了做这件事而开发的，只是它提供了Lua语言的嵌入式脚本解释环境，所以可以扩展来处理这件事情。而我个人的观点是，用这玩意儿不能期望一个程序到处能用，针对一个应用写一个特定的脚本是最好的，能够通过一些先验知识来加入特定处理，反而通用的系统由于要做太多SQL语言解释，反而可能影响效率。
另外，一般参考的实现都是一堆web服务器后面连一个MySQLProxy，后面再连MySQL的各个副本。不过，其实这样其实容易造成单点失效，而且可能也会造成性能瓶颈（个人经验，proxy在windows下的实现不太高效，这个下面再说）。所以，低成本一点的做法就是每个web服务器后面连一个proxy好了。原因有三，一防止单点失效；二如果proxy效率低可以防止瓶颈；三如果proxy效率高，也就不在乎了。
最后，效率问题。proxy的效率在windows下其实不是特别高。我初略看了它的源代码，其中IO的调度（也就是socket的读写）是通过一个开源事件处理库libevent来做的。这个库在Linux/Unix平台下使用了epoll、kquue等手段，似乎在Windows下没有使用IOCP，所以至少不是在Windows下最高效的实现（为了移植性？）。所以如果要跑proxy，最好还是选择Linux平台。 看不明白。 用windows跑数据库，那是找死
mysql-proxy的支持列表里面根本没有Windows吧 现在正准备改到MYSQL 。。这个mysql-proxy。有点意思，把读写分离也是个不错的办法。
回复 #4 duke2 的帖子
你原来用的是什么数据库?
页:
[1]