副标题#e#
引言
最近正好要用到这些内容，因此就找了一篇较量有分量的文章，思来想去，照旧实验写一下译文吧。其实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的焦点傍边。
#p#副标题#e#
计较负载
当抉择tomcat处事器数量时，你需要满意客户端负载，首要的任务就是抉择应用的平均响应时间。正如之前所说，为了满意用户体验，应用不得不在半秒内响应用户。客户端欣赏器收到的内容凡是会触发多次对web server的请求，好比图片。web页面凡是由html和图片数据组成，所以客户端会分发一系列的请求，而得到这些所耗费的总的处理惩罚和传送时间就是平均响应时间。为了不高出tomcat的极限，你应该限制并发请求数不高于“200/CPU”。
因此，我们可以从一个简朴的公式计较出一个物理箱子【这个箱子到底是什么，0.0】可以或许处理惩罚的最大的并发毗连数：
并发请求数 = max(500/平均响应时间,200) * CPU个数
#p#分页标题#e#
别的一件你需要思量的事，就是web server和tomcat实例之间的网络吞吐量。这里先容一个新的观念，叫做平均响应巨细，这是指一个web页面传送给用户的所有的字节巨细。对付一个尺度的“8位/字节”的100Mbps网卡，理论上最大的吞吐量为12.5Mbytes。
并发毗连数 = 12500/平均响应巨细
对付20KB的平均响应巨细来说，最大可以支持625的并发请求数。假如你需要承载更大的负载，那么可以增加更多的卡可能利用更快的1Gbps的硬件。
上面的公式教你对付必然数量的并发请求，如何或许估算tomcat、箱子和CPU的数量。假如你打仗不到详细的硬件就要举办设置，你可以在一个测试平台上测试平均响应时间，然后较量测试平台与硬件提供商的SPECmarks，这样你可以得到一个较量靠近的数值。
文章小结
文章就先翻译到这里吧，剩下的有时间再来翻译，熬炼下本身的有道程度。总的来说，LZ是大抵看懂了这篇文章，可是仍旧有些不大白的处所，好比谁人box，也就是箱子，到底是指的什么。LZ以为这个box绝对不该该简朴的翻译成箱子，可是LZ实在想不到是什么玩意，所以就只能临时这么写了。但愿有高人途经的话，答复一下这个箱子到底是什么。
幽你一默
LZ看到这两幅图的时候笑跪了，您呢，0.0。
作者：zuoxiaolong（左潇龙）
出处：http://www.cnblogs.com/zuoxiaolong
