近日不得不越那個代疱地鑽研發布和發布系統管理和測試的相關問題。有充分證據表明現得絕大多數的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能夠，這樣，就把上面的問題解決了。
