如何为一个高负荷站点配置tomcat连接器（connector）【译文】（第一篇）

引言

　　最近正好要用到这些内容，因此就找了一篇比较有分量的文章，思来想去，还是尝试写一下译文吧。其实LZ的英语是非常烂的（四级没过的LZ眼泪掉下来），因此这篇文章翻译的水平LZ自己也不敢恭维。各位猿友大致参考一下即可，其中【】符号是LZ的标注，（）内的是原文。如果各位有哪里实在看不明白的话，可能是LZ翻译的问题，各位猿友可以去看原文的内容，地址：http://people.apache.org/~mturk/docs/article/ftwai.html。

摘要

　　倘若你想实现最大的性能和稳定性的话，那么在web服务器后运行tomcat集群是必经之路，这篇文章就是用来描述完成这件事的最佳实践。

tomcat之前

　　一些人可能会问“为什么要在tomcat前面放置一个web server？”由于最近的JVM技术以及tomcat核心本身的原因，单个tomcat的性能已经非常接近于本地的web服务器，甚至当发送静态文本时，tomcat也只比当前的Apache2web服务器慢10%。因此答案就是：扩展性。

　　tomcat通过给每个客户端连接分配独立的线程，可以服务许多用户的并发访问。尽管这样tomcat可以做的很好，但是当并发连接数上升的时候，将会出现一些问题。系统为了管理这些线程所花费的时间会降低整体的性能，JVM也将花费更多的时间管理和切换这些线程，然后才能真正的对客户的请求做一些具体的工作。

　　此外，当应用直接运行在tomcat上的时候，连通性（connectivity）也有不少严重的问题。一个典型的应用可能会处理用户数据、访问数据库或者做一些计算再将结果返回给客户端。所有的这些都是一些耗时的工作，但是为了让用户感觉这是一个可以正常运行的应用程序，大多数时候必须在半秒内（500ms）就完成。如果应用的响应时间为10ms，那么在你的客户抱怨之前，你的应用最多只能同时服务50个并发用户【这句话有点别扭，0.0，但大致意思是理解的】。那么为了支持更多的用户你该怎么做呢？最简单的办法就是买一个更快的硬件，增加更多的CPU或者更多的箱子（boxes）【boxes？箱子？】。两个双路箱子一般比一个四路的便宜，因此添加更多的箱子一般比买一个服务器更加省钱【貌似这个箱子可以替代服务器，到底是什么东西，有英语好的给翻译一下】。

　　降低tomcat负载的第一件事就是使用web server处理静态文本，就像下图一样。

　　上图给出了最简单的可行的配置方案。web server用来传送静态文本，而tomcat只处理具体的工作，也就是应用服务。大多数情况下，这就可以满足你了。如果用一个四路的箱子【又是箱子，0.0】，并且应用的响应时间为10ms的话，那么你将能同时服务200个用户，也就是说，一天可以支持350万的访问量【不知道350万这个数字怎么算出来的，用200*60*60*24不是350万，0.0】，这已经是一个比较可观的数字了。

　　在以上这种程度负载的情况下，你或许不太需要将web server放在tomcat之前。但是还有第二个原因让你这么做，那就是这样创建了一个控制区（demilitarized zone）。将web server放在一个主机上等于在公司的私有网络与互联网或者是其它的外部公共网络之间插入了一个隔离区（neutral zone），这可以让tomcat上的应用安全的访问其它的私有资源，也可以访问公司的私有数据。

　　除了拥有控制区和可以安全的访问私有网络，还有一些其它的原因，比如可以满足自定义授权的需要。

　　如果有更多的负载需要承载的话，那么你将不得不添加更多的tomcat应用服务器，这可能是因为客户端的负载已经无法被一个简单的箱子【靠，到现在还没猜出来箱子是什么】处理，也可能是因为当某一个节点宕机时，你需要一种故障恢复的机制。

　　部署一个包含了多个tomcat应用服务器的架构，需要在web server和tomcat之间加入一个负载均衡器。在apache1.3、apache2.0和IIS中，你可以使用Jakarta Tomcat Connector，因为它提供负载均衡和黏性session机制。在将来的apache2.1/2.2中，可以使用advanced mod_proxy_balancer，它是一个新设计的模块并整合在apache httpd的核心当中。

　　

计算负载

　　当决定tomcat服务器数量时，你需要满足客户端负载，首要的任务就是决定应用的平均响应时间。正如之前所说，为了满足用户体验，应用不得不在半秒内响应用户。客户端浏览器收到的内容通常会触发多次对web server的请求，比如图片。web页面通常由html和图片数据构成，所以客户端会分发一系列的请求，而获得这些所花费的总的处理和传送时间就是平均响应时间。为了不超过tomcat的极限，你应该限制并发请求数不高于“200/CPU”。

　　因此，我们可以从一个简单的公式计算出一个物理箱子【这个箱子到底是什么，0.0】能够处理的最大的并发连接数：

　　　　并发请求数 = max(500/平均响应时间,200) * CPU个数

　　另外一件你需要考虑的事，就是web server和tomcat实例之间的网络吞吐量。这里介绍一个新的概念，叫做平均响应大小，这是指一个web页面传送给用户的所有的字节大小。对于一个标准的“8位/字节”的100Mbps网卡，理论上最大的吞吐量为12.5Mbytes。

　　　　并发连接数 = 12500/平均响应大小

　　对于20KB的平均响应大小来说，最大可以支持625的并发请求数。如果你需要承载更大的负载，那么可以增加更多的卡或者使用更快的1Gbps的硬件。

　　

　　上面的公式教你对于一定数量的并发请求，如何大概估算tomcat、箱子和CPU的数量。如果你接触不到具体的硬件就要进行配置，你可以在一个测试平台上测试平均响应时间，然后比较测试平台与硬件提供商的SPECmarks，这样你可以获得一个比较接近的数值。

文章小结

　　文章就先翻译到这里吧，剩下的有时间再来翻译，锻炼下自己的有道水平。总的来说，LZ是大致看懂了这篇文章，但是仍旧有些不明白的地方，比如那个box，也就是箱子，到底是指的什么。LZ觉得这个box绝对不应该简单的翻译成箱子，但是LZ实在想不到是什么玩意，所以就只能暂时这么写了。希望有高人路过的话，回答一下这个箱子到底是什么。

幽你一默

　　LZ看到这两幅图的时候笑跪了，您呢，0.0。