第一：作為oltp應用（聯機事物處理，區別於olap），響應速度和處理並訪能力是系統整體效能評價的第一要旨。
作為帶動效能提公升的主要因素，佔第一位的是系統的體系架構、第二位的是資料結構定義、第三位的才是選擇怎樣的語言和系統平台。當然，很多情況下在考慮體系結構的時候是有基於系統平台的考量，但是一般而言，系統體系結構並不是依存於某特定平台才能確定的。
作為高並訪應用的oltp而言，一般在涉及資料庫操作和資料儲存操作的時候，應當明確的關鍵問題是，資料庫操作的觸發和執行是不應當基於使用者請求的，這也是三層體系結構的真諦所在。也就是說，如果乙個使用者請求就觸發了乙個資料庫操作，不管你使用的是php,jsp,asp,cfm,fcg還是com元件或其他什麼東東，嚴格講都不是真正的三層體系，因為這時中間層實際上並不存在。即便使用了預編譯，即便使用了資料連線池（connect pool），即使系統提供了足夠的緩衝處理，都是不夠的。
舉個例子而言，如果你在乙個頁面上使用了計數器，最簡單的方法是每次頁面請求的時候，處理程式直接資料庫中相關記錄加1，不管使用什麼語言，什麼平台，或呼叫什麼控制項，亦或採用了資料庫內部的儲存過程處理（顯然這樣效率很高）。但是這還不夠，比如類似於易數統計這樣的系統，當它每天處理幾百萬至上千萬請求的時候，任何資料庫就都無法容忍這樣的操作，因為對於update操作，資料庫緩衝的存在基本是無用的。
那麼取代的手段是怎樣的，前台的api程式將來訪請求的一些資訊按照乙個指定規範直接扔到指定緩衝區裡面，這樣api程式（請注意這裡我不提cgi,cgi效率那麼差，在這樣的場合是不推薦的）的處理過程很簡單，效率很高。後台的看守程序從緩衝區讀取資料，通過指定管道（資料連線池，固定資料庫連線程序維持常連線狀態）和資料庫進行資料更新操作，這樣的好處有以下幾點，第一是當並訪瞬間高峰時，前台響應不會受很大影響，緩衝可能會造成溢位而損失資料，但是不會影響前台的展示，而且當緩衝合理分配時，這種壓力也會減輕，而後台看守程序可以將任務負載均衡分布處理，一時處理不完的在系統負載減輕時可以繼續處理，這樣後台負載可以均擔，減少因瞬態高峰造成系統崩潰的隱患；第二是當緩衝區資料儲存合理安排時，後台可以作到批量處理，要知道資料庫批量更新比乙個乙個單獨更新的效率會高很多，這樣從處理任務量上減輕系統負載！
針對以上補充一點說明，一般而言，針對良好的商業資料庫而言，select操作比update操作的效率高乙個數量級，因為前者可以充分利用緩衝，而後者不能，因此將update操作批量化和後台化是非常重要的！
第三：那種語言效率最高
這是乙個最原始的問題，php＋zend,fcg,jsp,iis api都宣稱自己非常之快，實際上他們都是採用了提前載入，預編譯，駐留記憶體，緩衝分配等手段，使得處理請求響應的速度非常之快，但是這種速度僅僅是處理響應的速度，當系統需要對後台資料庫，對後台檔案，甚至對後台shell進行操作的時候，最快的毋庸質疑，還是c語言，而且是標準c語言，有乙個事實必須提醒諸位，儘管高階語言層出不窮，但是從70年代到21世紀，世界上最值錢的程式設計師一直是標準c的程式設計師（當然還有更原始的彙編程式設計師）。其實乙個大型系統，前台動態展示採用asp也好，cfm也好，fcg也好，jsp也好都是無關緊要的，關鍵是採用合適的架構並把煩瑣的資料操作盡可能放到後台執行。
放到後台執行的準則是，將動態化過程中所有可以集中批量處理的，所有可以通過緩衝交換的，所有重複性的工作，所有與使用者請求沒有直接關聯的，一概放到後台，以看守程序，或者定時程式進行。
第四：安全問題考慮。
當乙個大的網上應用系統，如果有些程式，訪問量不高，因此**設計者認為效率無所謂，可以通過api直接對資料庫進行煩瑣操作，那麼就危險了，實質上那種程式往往成為基於cgi的d.o.s攻擊的靶子，（本人恰恰是這方面的專家）。因為當有人通過偽裝報文，瞬間大量請求這個處理效率不高，反應緩慢的程式的時候，系統資源就會大量被占用，很快就會因為系統資源過載而導致系統崩潰或拒絕服務。
請注意這種攻擊是導致系統資源的過載而不是頻寬，由於寬頻網的接近，基於頻寬的拒絕服務攻擊將越來越困難，但是恰恰相反的是，基於系統資源的拒絕服務攻擊將越來越容易，所以**設計者，千萬不可在任何乙個地方掉以輕心，而煩瑣操作後台化，對這樣的攻擊行為就有很好的抗擊能力，這一點也是我這裡再次要強調的。
再補充一句，進行這樣的攻擊非常容易，以至於乙個完全不會寫程式的人，只要懂得一些網路，就可以在很短時間掌握，並給大型站點帶來嚴重打擊。
第五：資料支援
本人羅里羅嗦這麼半天，大家不知道是不是不耐煩，我有何德何能在此逞強？
.i**e.net是目前每天支撐接近300萬次廣告鏈呼叫的免費廣告交換系統，瞬間高峰每秒請求超過50次，每天流量12g以上。我在系統正常執行的過程中作過測試（系統已經有一定負載），通過apache的ab進行標準測試，對廣告鏈投放程式，測試結果是在100個並訪情況下，瞬間處理能力可達到每秒1300次廣告鏈請求！如果不是合理分配記憶體緩衝和後台看守程序的預生成，如果每個請求程式都要到資料庫跑一趟，這個數字是絕對不可能達到的。
任何人都可以在apache下面用ab對自己寫的程式進行速度評測，看看你的程式能達到怎樣的處理能力？
關於Session的一些討論
眾所周知，session是jsp的九大內建物件之一，也是伺服器二次識別客戶端的橋梁，它的生命週期非常長，一般都是存在於乙個會話 同一瀏覽器 之中，與 天地同壽 伺服器 有如下例子 1 在不關閉瀏覽器的情況下，建立乙個session，你始終可以訪問到這個session。2 在不關閉瀏覽器的情況下，建立...
大型機系統檔案命名的一些技巧
目前正在做乙個遷移的專案，該專案把大型機上的乙個系統遷移到unix系統中。現在遇到的乙個問題是，因為原大型機系統會被替換，但是這個系統所產生的輸出檔案，會被別的系統使用到，替換的新系統也必須同樣能產生一樣格式 內容，然後從unix上傳到大機中。記得在以前的公司，乙個系統的輸出作為別的系統輸入的檔案叫...
素數判定的一些討論（Miller Rabin演算法）
很久沒有寫部落格了。最近軍訓加開學，感覺刷題速度有降低，要補一補。回歸正題，正式進入數論階段，討論一下關於素數判定的那些事。直接根據素數的定義列舉 i 從2到 n 1 如果n i 0 n 為合數。時間複雜度 o n bool is prime int n 發現若存在 i n 使得n i 0，則必有n...