不難認識到，在web應用中圖片/多媒體和長文體的處理策略，很大程度上決定中一個系統的性能和負載能力。
這幾天在處理圖片上載的同時，也在考慮著最合理的對圖片和長文本的存儲。多年前，我喜歡把圖片和長文本都存進oracle中，目的是備份方便，只需要 exp就可以連圖片一起備分起來，不用一個個地照顧目錄。但是缺點也隨著訪問量上升而一點點顯示出來：一來是大大加重了數據庫服務器的負擔；二來使用 BLOG/CLOG並不是SQL92支持的標准SQL，令開發持久性的對象變得復雜;其三，oracle並不是一個適合存儲文件的數據庫，象他的 varchar2只能支持四千個字符，而使用CLob就不能直接使用sql顯示；顯然，mysql是更合適的文件數據庫；它的text好象到現在還沒有發現存儲極限，而且完全可以使用標准的SQL讀取和搜索。對於圖文資料來說，事務並不重要，方便的查詢和速度（意味著低負載）更為重要，反而是把它升級使用 BerklneyDB，添加事務回滾等，變得畫虎不成反類犬。而Oracle,應該讓它專著於商務型的事務可靠性要求高的場合。 有朋友認為，長文本和圖片都應該放在數據庫以外，通過連接引用，我覺得對於mysql來說，它本身基本上就是一個圖文文件系統，帶有一個sql接口，所以文本沒有必要存到外邊，放在MySQL中最合適。而圖片，需要特別的BLOG處理，不能使用標准SQL，就應該放在數據庫外面，減少系統的負擔。 今天的數據庫使用和開發模式實際上是一步步走向面向對象的存儲和處理，這點特別是在JAVA（是中間件的主要工作語言）上表現得非常突出，無論是J2EE 還是Hibernate，還是我自已搞的dao/Processor，都是把java對象池看作是數據庫對象向語言平台的延伸，直接面向對象的存儲代替了通過SQL訪問具體數據。盡管數據對象本身還是以關系結構的形式存在數據庫中的，但它的細節被Java對象的自動初始化隱藏起來。因此，盡可能令存儲方式標准化（不要采用獨特的存儲方式）可以大幅度提高性能，簡化數據對象化的程序，實際上提高了它的可靠性。正因如此，圖片存儲在文件系統而不是以二進制存在數據庫中，是更合理的選擇。 現在我的web平台主要是采用apache_catalina，這個平台在幾年前使用後，很長一段時間沒有使用了，實際上，它不但多變，而且文檔極其缺乏 ——甚至於我現在還找不到server.XML中的Context對象屬性的定義說明。當初把apache通過ajp13連系在一起，據說是因為 apache處理靜態文件的能力遠強於tomcat，但我一直不明白，它如何識別什麼文件該阿帕奇，什麼文件該tomcat?事實上我想最關鍵的文件是 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頁面。
顯然，在這種結構中使用通配符是最容易配出運行框架的，卻也是錯誤的。
