為了更好的測試你的asp程式，你首先需要決定你的程式將來需要面對多大的壓力。簡單的說，壓力或負載可以分解成以下數字：
· 最低使用者數量。（這個程式的使用者的最低數量是多少？通常這個數值可以是每日或沒周或每月的點選量—當然你也可以分解成乙個更可控的數值—每小時訪問量，）
· 併發使用者的總量. (在最高峰時的糟糕狀況是什麼？作出相應的計畫. 希望在有壓力的情況下工作正常有效.)
· 請求高峰值. (每秒鐘需要產生多少asp頁面? 這也許是在衡量乙個asp程式對使用者請求作出反應的能力時的乙個最重要的因素.)
為你的程式決定使用者量和併發使用者數通常是很困難的事情，而且是在你的程式在被實際使用之前。尤其是網路程式。即使是區域網程式也常常要面對使用者增加的問題，所以準確的預計使用者量將會是困難的。當你不知道怎麼開始時，最好從基礎的開始：
internet需要考慮的問題：
· 分析你已有的iis日誌。這個數值會暗示出一些實際的機率
· 你的站點將會有多流行？流行的站點一天會有100萬或更多的訪問量。不會那麼流行？那麼假設一些不同的情況？假設你有1000以上的使用者群？你能通過增加更多的硬體裝置來解決擴充套件性問題嗎？或者，你的程式的架構會成為瓶頸嗎？
· 什麼是最糟糕的情況？問一下你的朋友這些情況會發生嗎？
intranet需要考慮的問題：
· 同樣地，分析你已有的iis日誌。
· 這個asp程式是可以給每個人用的嗎？在公司內部網有多少臺機器？你的系統管理員可以告訴你有關網路高峰流量的東西嗎？
· 這個程式有特定的使用者物件嗎？只是hr人力資源部？有多少個人力資源部的員工在使用？
· 最糟糕的情況是怎樣的？
如果你不能提前決定適當的負載，那麼確定你的程式的最高上限將是你最好的選擇。如果被10個使用者點選，你能在1秒內產生多少的asp響應結果？100個呢？1000個呢？10000個呢？記錄你的基準。當你從實際使用中得到你的流量日誌顯示你正在接近你的極限時，你將不僅會為你知道你當前的極限是什麼，而且你會有時間準備解決的辦法。
介紹測試工具was
雖然有很多的壓力測試工具可供選擇，但是在本文，我會主要集中介紹was（就是以前所謂的homer），was是當前微軟的標準網頁壓力測試工具。如果你已經對webcat很熟悉了，你會激動的發現was可以很方便地匯入現有的webcat指令碼。如果你以前用過inetmonitor，你會激動的發現was也是基於gui的（對於很多使用命令列的webcat的使用者來說這將會是乙個很好的附加特性）。另乙個好處是它是免費的，我的乙個好朋友常說，「如果是免費的，那麼就是我的。」除了它的**優勢外，這個工具還提供了完整的功能，而且還在不斷地公升級更新中。microsoft.com經常要使用它，所以他們會明白這個工具的重要性。
但是你不需要過多地理會我的話，只管自己去嘗試。我在文章的結尾會提供乙個列表，列出一些第三方的壓力測試工具，你可以自己決定選什麼工具。底線是你需要乙個工具，能夠把你的asp程式放到負載下，在發布之前測試它。
為你的程式建立乙個控制台
經常看到一些程式在執行的時候有乙個windows控制台，感覺非常cool。實際上有的時候幫助你監視系統執行是很方便的，那麼怎麼樣建立乙個控制台呢？實際上windows為你提供了一系列的api來完成這個功能，例如 readconsole,writeconsole等，具體參見msdn。下面我們用一段 來...
乙個小小的程式測試你的思維
php演算法 氣泡排序 arr array 3,1,5,9,2 外層迴圈 決定輪數 for i 0,len count arr i len i if i 2 print r arr i 0 j 0 3 1 交換 1,3,5,9,2 j 1 3 5 不交換 1,3,5,9,2 j 2 5 9 不交換 ...
用ASP寫的乙個轉換程式
至於轉換程式,這次是第二次寫了,第一次是.略 比起第一次不同的是這次使用了動態陣列 有點興奮,bs我吧 用asp寫了不少程式,這是第一次用到陣列.這次轉換的條件是要根據原資料庫中某字段的值進行判斷,然後根據相關值進行替換,問題本來不難,不過要替換的記錄實在是太多了,幾千條記錄中的同一需要進行替換的字...