优化apache/tomcat配置
类别: JAVA教程 
近日不得不越那个代疱地钻研发布和发布系统管理和测试的相关问题。有充分证据表明现得绝大多数的apache/tomcat配置中,apache根本就是摆设，所有的响应负担，包括静态多媒体文件实际上是由tomcat完成，而tomcat实际上是效率相当低的，大约是apache的十分之一。因此，没有达到集成两者的目的；但在优化配置本地基本成功，打算在网上测试服务器实际试行时，却碰到了"martix现象"：无可解释的不可重复的异常表现。
看来，在tomcat/apache的配合上要动真格的，今天写的那份文章提示了一个现实的问题，apache根本就没有作用，更严重的是，107和106上不匹配，107上甚至不能重复出106的配合。由于图片的量会不少，所以这是一个非常现实的问题。我想，目前唯一的办法就是下载到本地，参考可能参考的资料完整地进行一次配置。毕竟，现在的配置是几年前的，而且不是由我进行的。这里如果处理OK了，那么相信对于提供系统的处理能力和处理的速度，是大有益处的。......经过一天的奋斗，主要的时间在于重新在本地设备上安装所有相关的软件，包括本地的DNS服务器，没有这个没有办法测试虚拟主机解释。所以主要还是在晚上测试，深入钻研apache/tomcat的配合，基本搞清楚了两者的关系，确认原来的配置方式只是"表面上成功"，实际上完全由tomcat完成所有应答，apache只是聋子的耳朵——摆设。但是在本地完成所有测试，原封不动地准备在网上进行更新设置时，再次碰到"Matrix现象"：出现了莫名其妙的差异；无法解释，自然消失。
第一个差异就是，按照最新的理解，apache解释的多媒体路径与tomcat解释的页面路径是不同的，因此，必须在页面上修整两者，否则图片和多媒体就会因为路径不一而不能获取；而在原来设置中由于完全由tomcat解释，所以两者是相同的。这个设想的实验在本地非常成功，但是在网上，就完全相反，路径解释无论如何都是对的——问题在于我在本地已经测试并修改了这个路径解释：老天爷，到底要那一个呢？而实际上，worker.properties的过滤是完全一样的。这点如果还不算太怪的话，那么第二个差异就更怪了。
首先是使用原来的httpd.conf总是在虚拟主机DocumentRoot上被禁止访问，在强行使用本地设置文件置换（由于路径一样，问题倒不算大）后就变得可以了。这条权作是未知的某处错误存在，那么随后就怪事连连了：无论是那个虚拟主机，统统只是解释到第一个虚拟主机的目录，换言之，虚拟主机完，全失效。把那个设置文件拿回本地测试却是一切正常。随后再次到网上测试，这次却是跟着正常了......原因不明，唯一的可能......似乎是firefox缓存一类......总之是笔糊涂帐。真是莫名其妙。但前者的图片必须改由apache解释是确证无疑的，否则，系统性能会过大消耗，静态大文件的处理，不是tomcat的长处。
我们这个世界是一个物质物理世界，它的基本特征就是同质可重复性，整个现代科学都是建筑在这个基础上的。如果一旦碰到同质可重复性不能成立时，我的感觉就是俺是不是生活在Matrix里头了。
续：今天在本地的测试得到了与远端同样的结果，至少看来重新象一个物质世界了！ 目前唯一可能的解释，（不过也是解释得非常牵强的），就是firefox对于浏览过的网站或者出于加速的原因，有一些与过往的浏览器有很大不同的缓存策略。在以后的操作中要注意这一点。
这个结构许多人已经熟悉用了，而且在网上也有大量的howto，不过最关键的文件worker.properties设置就未必正确，如：
info=Ajp13 forwarding over sockettomcatId=localhost:8009[uri:/jsp-examples/*][shm:]disabled=1
如果象上面那样uri:/jsp-examples/*的话，相信，apache屁用没有，根本上就是tomcat承受了一切的负担。 显然，如果是这样配置，系统承受的负担,我指的是java 服务器，将是大大超出应有的负荷的。应该修改上面的配置，让apache承但，主要是html和图片以及多媒体的下载任务，而不是tomcat,估计可以大大提供这个搭配系统的负载能力。
......前天写到这里，忽然觉得这个配置颇为眼熟，赶快去查一下，果然现在的项目中的设置就是这个样子的，但是进一步的测试就让我有点入歧途，一会儿证明是那样，一会儿就表明是那样。软件这东西如果缺乏逻辑必然的联系，人是没有什么好干的。无论如何，继续上面的思路，象上面的配置，表明所有/jsp-examples/*次级目录下的东东都是交由tomcat处理；Apache并没有相应的工作。正确的配置应该是：[uri:/jsp-examples/*.jsp][uri:/jsp-examples/servlet/*]
如果使用了如struts，大概还需要增加*.action这样的后缀。这样，非此类型的文件将会交给apache。而这样的设置：[uri:/*]有极大的危险，将意味着所有的请求全部由tomcat响应；不过，看来ajp13作了预防性措施，事实上，这时侯ajp13把所有请求扔进了下水道，什么也不干。负作用就是虚拟主机的根目录我无论如何设不出它能够直接识别index.jsp引导。只能使用html代替，不过，这也没有什么大不了的，如果是小型的首页，可以就地转向，而假如是大型的首页，本身就会定时转换输出为html页面。显然，在这种结构中使用通配符是最容易配出运行框架的，却也是错误的。
把Apache与tomcat合并起来后，还得到了一个意外的收获，就是可以使用连接形式把一些主要的非jsp/servlet文件由apache在目录以外解释，从而简化了开发目录的管理。在实际的开发过程中，如果规划不佳，不多久就会积累了大量的无用的图片文件，工作目录动不动超过一个G是非常正常的；如果开放部分如允许用户上载文件之类，更是大得惊人，但是由于tomcat不能解释symbolic链接，这样就不能把这些图片移到目录以外，只能是使用全url才有可能实现，而把在合理配置Apache/tomcat后，尽管tomcat不能解释链接符号，但Apache能够，这样，就把上面的问题解决了。
看来，在tomcat/apache的配合上要动真格的，今天写的那份文章提示了一个现实的问题，apache根本就没有作用，更严重的是，107和106上不匹配，107上甚至不能重复出106的配合。由于图片的量会不少，所以这是一个非常现实的问题。我想，目前唯一的办法就是下载到本地，参考可能参考的资料完整地进行一次配置。毕竟，现在的配置是几年前的，而且不是由我进行的。这里如果处理OK了，那么相信对于提供系统的处理能力和处理的速度，是大有益处的。......经过一天的奋斗，主要的时间在于重新在本地设备上安装所有相关的软件，包括本地的DNS服务器，没有这个没有办法测试虚拟主机解释。所以主要还是在晚上测试，深入钻研apache/tomcat的配合，基本搞清楚了两者的关系，确认原来的配置方式只是"表面上成功"，实际上完全由tomcat完成所有应答，apache只是聋子的耳朵——摆设。但是在本地完成所有测试，原封不动地准备在网上进行更新设置时，再次碰到"Matrix现象"：出现了莫名其妙的差异；无法解释，自然消失。
第一个差异就是，按照最新的理解，apache解释的多媒体路径与tomcat解释的页面路径是不同的，因此，必须在页面上修整两者，否则图片和多媒体就会因为路径不一而不能获取；而在原来设置中由于完全由tomcat解释，所以两者是相同的。这个设想的实验在本地非常成功，但是在网上，就完全相反，路径解释无论如何都是对的——问题在于我在本地已经测试并修改了这个路径解释：老天爷，到底要那一个呢？而实际上，worker.properties的过滤是完全一样的。这点如果还不算太怪的话，那么第二个差异就更怪了。
首先是使用原来的httpd.conf总是在虚拟主机DocumentRoot上被禁止访问，在强行使用本地设置文件置换（由于路径一样，问题倒不算大）后就变得可以了。这条权作是未知的某处错误存在，那么随后就怪事连连了：无论是那个虚拟主机，统统只是解释到第一个虚拟主机的目录，换言之，虚拟主机完，全失效。把那个设置文件拿回本地测试却是一切正常。随后再次到网上测试，这次却是跟着正常了......原因不明，唯一的可能......似乎是firefox缓存一类......总之是笔糊涂帐。真是莫名其妙。但前者的图片必须改由apache解释是确证无疑的，否则，系统性能会过大消耗，静态大文件的处理，不是tomcat的长处。
我们这个世界是一个物质物理世界，它的基本特征就是同质可重复性，整个现代科学都是建筑在这个基础上的。如果一旦碰到同质可重复性不能成立时，我的感觉就是俺是不是生活在Matrix里头了。
续：今天在本地的测试得到了与远端同样的结果，至少看来重新象一个物质世界了！ 目前唯一可能的解释，（不过也是解释得非常牵强的），就是firefox对于浏览过的网站或者出于加速的原因，有一些与过往的浏览器有很大不同的缓存策略。在以后的操作中要注意这一点。
这个结构许多人已经熟悉用了，而且在网上也有大量的howto，不过最关键的文件worker.properties设置就未必正确，如：
info=Ajp13 forwarding over sockettomcatId=localhost:8009[uri:/jsp-examples/*][shm:]disabled=1
如果象上面那样uri:/jsp-examples/*的话，相信，apache屁用没有，根本上就是tomcat承受了一切的负担。 显然，如果是这样配置，系统承受的负担,我指的是java 服务器，将是大大超出应有的负荷的。应该修改上面的配置，让apache承但，主要是html和图片以及多媒体的下载任务，而不是tomcat,估计可以大大提供这个搭配系统的负载能力。
......前天写到这里，忽然觉得这个配置颇为眼熟，赶快去查一下，果然现在的项目中的设置就是这个样子的，但是进一步的测试就让我有点入歧途，一会儿证明是那样，一会儿就表明是那样。软件这东西如果缺乏逻辑必然的联系，人是没有什么好干的。无论如何，继续上面的思路，象上面的配置，表明所有/jsp-examples/*次级目录下的东东都是交由tomcat处理；Apache并没有相应的工作。正确的配置应该是：[uri:/jsp-examples/*.jsp][uri:/jsp-examples/servlet/*]
如果使用了如struts，大概还需要增加*.action这样的后缀。这样，非此类型的文件将会交给apache。而这样的设置：[uri:/*]有极大的危险，将意味着所有的请求全部由tomcat响应；不过，看来ajp13作了预防性措施，事实上，这时侯ajp13把所有请求扔进了下水道，什么也不干。负作用就是虚拟主机的根目录我无论如何设不出它能够直接识别index.jsp引导。只能使用html代替，不过，这也没有什么大不了的，如果是小型的首页，可以就地转向，而假如是大型的首页，本身就会定时转换输出为html页面。显然，在这种结构中使用通配符是最容易配出运行框架的，却也是错误的。
把Apache与tomcat合并起来后，还得到了一个意外的收获，就是可以使用连接形式把一些主要的非jsp/servlet文件由apache在目录以外解释，从而简化了开发目录的管理。在实际的开发过程中，如果规划不佳，不多久就会积累了大量的无用的图片文件，工作目录动不动超过一个G是非常正常的；如果开放部分如允许用户上载文件之类，更是大得惊人，但是由于tomcat不能解释symbolic链接，这样就不能把这些图片移到目录以外，只能是使用全url才有可能实现，而把在合理配置Apache/tomcat后，尽管tomcat不能解释链接符号，但Apache能够，这样，就把上面的问题解决了。
