最佳化apache/tomcat配置

來源:互聯網
上載者:User
apache|最佳化 近日不得不越那個代皰地鑽研發布和發布系統管理和測試的相關問題。有充分證據表明現得絕大多數的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能夠,這樣,就把上面的問題解決了。

相關文章

Beyond APAC's No.1 Cloud

19.6% IaaS Market Share in Asia Pacific - Gartner IT Service report, 2018

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。