所以變成我們現有的資源……

因為以現在CPU測出來的使用率來講，並不是現在一般營運狀況可以接受的，已經超過90％了。

所以我們再看到AP的CPU使用率，所以假設要符合六十萬戶的申報量，其實還是要再從報表去作改變，還有看報表改變之後的CPU使用會不會下降。

我們知道瓶頸會存在於報表的產出，會到PDF檔，我相信各位都有看過我們的壓測報告，平均反應的時間會比較長，再來是可能到達我們所呈現情境一的數量之後，後面其實表現就不是很好了。

不過還是有其他的瓶頸在，並不是現在的機器就做得到，我們透過這一次的壓測去檢視整個系統的設計有沒有瓶頸存在。

對。

可以做到一天兩萬件……一小時……等一下，我看一下。

對。並不是沒有落實，六十萬戶一壓下去，現有的機器到一個瓶頸，所以沒有辦法再往下做。

我回應一下，我們收到Mac是加上行動版的人下去做，我們有收到兩個需求的數據，一個是以六十萬戶下去做壓測，後來我們又收到一個更高的數據，好像是為了符合一、兩百萬人。

要調。

這個沒有辦法（笑）。

整個機器都是為了電子報稅購買的，空間設置在中華電信機房。

時間的部分，可能至少給我們兩週的時間，現在同仁都還在忙下稅後的事情。

至於其他承載量問題的話，我想瓶頸的部分還是要回去找原因，畢竟這個跟連線數、點擊方式及動態設計都會有關係。

其實壓測相關數據，我要再回去諮詢一下，畢竟是我們私底下測的，有一些東西我們要再檢視，像這樣的測法，如果以後是要作正式大量的時候，這樣的測試方法有沒有需要調整的地方。

我們配合中心研擬方向，再作細節的討論。

這上面還有身分認證元件的設計考量，這不是單一方面關貿配合就可以解決。

在行動版的合約裡面是沒有要求壓測作業，但是我們實際上有做，所以像剛剛中心長官說的，大概是在五萬上下，我們以這樣的量去壓測，因為長期觀察市場使用的狀況，使用者大概是一萬上下而已，假設沒有做任何改變的時候，很難瞬間飆高，以市場使用者的狀況，也就是以五萬上下的量壓測。