快精灵印艺坊 您身边的文印专家
广州名片 深圳名片 会员卡 贵宾卡 印刷 设计教程
产品展示 在线订购 会员中心 产品模板 设计指南 在线编辑
 首页 名片设计   CorelDRAW   Illustrator   AuotoCAD   Painter   其他软件   Photoshop   Fireworks   Flash  

 » 彩色名片
 » PVC卡
 » 彩色磁性卡
 » 彩页/画册
 » 个性印务
 » 彩色不干胶
 » 明信片
   » 明信片
   » 彩色书签
   » 门挂
 » 其他产品与服务
   » 创业锦囊
   » 办公用品
     » 信封、信纸
     » 便签纸、斜面纸砖
     » 无碳复印纸
   » 海报
   » 大篇幅印刷
     » KT板
     » 海报
     » 横幅

优化apache/tomcat配置

近日不得不越那个代疱地钻研发布和发布系统治理和测试的相关问题。有充分证据表明现得绝大多数的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能够,这样,就把上面的问题解决了。



返回类别: 教程
上一教程: 让Java程序自带JRE
下一教程: [分享]eclipse 3.0 中jre设置的小错误导致在java文件中连接数据库失败

您可以阅读与"优化apache/tomcat配置"相关的教程:
· 如何利用Apache+Tomcat配置JSP开发环境?
· WINDOWS2000下APACHE2.0.46与TOMCAT5.0.2整合配置方式
· ZIP版本TOMCAT配置新手入门
· TOMCAT中DATASOURCE的配置方式
· 配置Eclpise+tomcat与实现JSP部署
    微笑服务 优质保证 索取样品