大家好，我是唐鳳辦公室的成員，我叫君翰，我先幫大家作一個簡短的開場，就是這一間會議室，會議進行中會用到的一些工具，接下來就會把麥克風交給主持人芳睿。
在會議開始之前，我先提醒一下，今天的會議都有排位置，可能位置大家不要隨意更換，因為我們要做完整的紀錄。
另外一件要說明的是，連線頭方式有兩種：各個部會的夥伴如果是到行政院第二會議室的話，第二會議室本身有跟硬體一起建置會議系統的功能，所以到第二會議室的話，就是用硬體的方式。如果是在自己部會的話，其實是下載軟體，安裝好軟體之後就可以連線上這一個會議室進行討論，以上說明。
使用流程也很簡單，不過我們還是拍了一支短片跟大家介紹從無到有、安裝起來及連上去並投影簡報，這個短片會會後分享給大家。
我稍微簡短說明一下遠端視訊的部分，基本上遠端視訊會採用行政院資訊處的一套系統叫做「SCOPIA」，這一套系統跟大家常用的skype及線上軟體很像，可以多人同時視訊，也可以分享簡報。
所以會變成是說……
你不可能戴上頭盔就不吃不睡，然後就……
不是啊，可是你終究你是要拿下來，你是要面對你的現實生活。
所以會變成是說，你要怎麼肯定自己可以達到這樣的選擇？
是呀！
剛剛那個情況不是……就我的想法，我覺得並不是每個人都能接受的。
對，直接上一手下載資料的參考位置。
至少我這邊不提供一個讓你下載方便的地方，但是你可以有一個……
剛剛有提到討論事項第二點下載系統資料的功能，因為這一個功能在我們訪問各種不同使用者的時候，陸續有人提到這一個功能，而這一個功能是不是有一個比較前期的做法，也就是把Open Data的網址列上去。
不好意思，我往回問一個問題。
以上報告，詳細的話可能還是要看每一份壓測報告。
因為資拓在這邊，雖然不是正式伺服器，但是他們把它當作測試伺服器，debug模式是關閉的，因此我們沒有辦法看到到底出了什麼錯誤，這個是要麻煩資拓的同仁幫忙查一下，我可以配合幫你們重現「500」的錯誤，讓你們比較好查。
在壓測初期的時候，都會出現程式開發人員最不想看到的「500」這個錯誤，就表示程式運行的時候，可能出現了什麼error。
另外一個是自選組合項目，其實回傳的速度還算ok，也就是跟剛剛重要產區的氣象資料比較起來的話，其實回傳的時間比較短，但會有奇怪的錯誤，可能要麻煩廠商幫忙確認一下。
回應時間小於三秒的時候，其實使用者大概是在六百五十人左右，如果同時在線的人數到達快要將近三千人的時候，已經到達效能的極限，我沒有辦法判斷是資料庫到達極限或是網頁伺服器到達極限，可以看到後來的回傳開始非常不穩定，那就表示資源將近被耗盡了，雖然可以正常提供服務，但並不是一個穩定的狀態。
因為設計上其實是一口氣會查所有的觀測站，所以以甘藍為例的話，其實一按下去的時候，其實會發生五十三個請求。相較於其他的服務，其他的服務其實大概只有兩個，因此這樣的話，一口氣發出五十三個請求，對網頁伺服器來講會造成額外的負擔。
再來另外兩個比較複雜的操作，第一個是重要產區的氣象資料，第二個是自選組的項目。
上次張科長有跟我提到整個農糧署的網段是50Mbps，假如真的有五千人看這一個網站的時候，在沒有任何封鎖限制的情況下，農糧署的網路應該是整個被攤換掉的，因此其實下一個遇到的問題是頻寬。
所以我們用思考時間三十秒及同時在線的人數五千人來看的話，這一個截圖是壓力測試的伺服器，因此這邊看到的是接收的流量，也就是對方網頁伺服器傳送的流量，整個傳送的流量已經到達60.8Mpbs。
現在加上思考時間，這五千人變成是在線上點了一下網頁之後，看了三十秒再選下一個動作，這樣的操作行為其實比較像正常的人類。
「503」錯誤解除之後，會面臨的下一個問題是頻寬，為什麼會說是頻寬？如果以產量與消費量推估的功能來看，其實我們這時加上了思考時間。
錯誤其實是雖然服務是在的，但現在暫時不讓你用，為什麼暫時不讓你用是因為超過可以容納五千人的上限，只要透過這一些簡單的指令，把這五千人的上限打開，其實就會突破目前的這一個門檻。
為什麼會訂那五千人？這邊有一個問題，我們在設定網頁伺服器的時候，並沒有把所謂的連線數的上限打開，所以只要一到五千人的時候，這個IIS的網頁伺服器就會一直回傳錯誤。
那時承載不了的壓力，瞬間是一萬人左右，所以我們現在已經到它的一半了，其實我覺得整體效能看起來滿好的。
大家有印象的是，前一陣子有發生過土壤液化的事件，土壤液化的事件，因為很多人關心土壤液化事件時，導致土壤液化事件的伺服器就因為承載不了那個壓力，所以一直回傳錯誤。
如果直接來看的話，可以發現就算同時在線有五千人的時候，平均回應時間其實還算可以接受，因為最慢的這邊也到七點零二秒而已，這邊也到六點七九秒，同時在線的五千人大概很難想像是多麼重的壓力。
其實我們可以發現最低的是主要一般市場的交易行情，我研究了一下為何主要批發市場的交易行情會最低，因為預設的區間比較大，所以一次要撈的資料比較多，所以需要的運算資源比較多一點，因為我們都是用預設的方式去測。
綜合來看這個結果，如果認為單純這六項功能的話，在畫面上可以分為小於三秒的情況，還有一個是同時在線的人數是五千人的時候，這邊選擇小於三秒是因為像Google比較大的公司都會說如果網頁沒有在三秒之內給人家一個回應的話，那個使用者就會離去，因此我們在這邊選擇三秒當作門檻，目前的這六項子系統到底可以承載多少的使用者。
整個錄製的內容，包含top level的request，進到那一個頁面來的那一次request，在這邊我們就不會特別強調一些圖片的檔案及靜態Java script的檔案，因為這一些東西都可以用catch保存起來或者是CDN機制處理掉，這個是比較容易的。
在日選項目這邊，我的確做了一個非常不合理的腳本，我把所有「＋」都按了一次，再按一下查詢，就是所有的「＋」大概有七、八個，我都按了一次後查詢，等一下我們也可以看結果。
在重要產區的資料，因為預設是甘藍，我們就直接按查詢，看起來是簡單的動作，但會發出比較多http的請求。
針對這一個腳本錄製的說明，基本上這六個比較簡單的這六個動作，就是進入功能頁面、按下甘藍及查詢，我們就沒有額外做多的查詢。
另外這兩個系統，因為不是跟這一群系統一起建置的，所以在這邊並沒有準備測試環境，為了不影響農糧署自己的網路，所以就沒有在本次的壓測範圍內。
像這個動作較為複雜的自選項目的查詢，還有重要產區的氣象資料，為什麼重要產區的氣象資料會比較複雜？因為一按查詢的時候，所有觀測站的資料都會查詢一遍，目前預設是這樣子，所以相較於其他查詢的頁面來看的話，這邊送出的需求是比較多的。
這一次的壓測目標就是這一個系統，基本上這一個系統可以分為這幾塊，剛剛張科長有介紹過，有一些查詢的動作比較單純，可以選日期、項目，然後按查詢就好。
後來有以一個比較符合正式情況，像使用者進去之後會看的畫面停留，大概是三十秒，之後再重新整理的情況再作測試，這一些測試報告都會在後面呈現。
這邊有設定使用者思考時間，像畫面完全打開之後到重新整理中間停留的時間是零秒，大家可以想像是六千個非常積極的使用者一直按重新整理，其實這一個情況是不太合理的，但可以測到這一個系統的極限，我們先以這樣的方式去測。
再來壓測規劃，基本上這一次的設備是從零位使用者開始，然後每秒增加十位使用者，慢慢往上增加，直到同時在線的使用者是六千位的時候，大概需要十分鐘，之後我們再繼續往後執行，同時在線六千個使用者的方式執行五分鐘，所以總共會是十五分鐘。
但是通常不會直接考慮到網路的頻寬，因為網路的頻寬可以再往上堆，通常會考慮到的是這一個程式碼本身處理的速度是否夠快及網站伺服器有沒有設定好，因此我們在這邊借了一台農糧署內部網路的設備。
先說明一下這一次壓測規格，基本上使用的是Open Source的軟體叫做「JMeter」，所以就不會有版權的問題了。壓測設備基本上「JMeter」server跟client裝在同一台，用的是農糧署借我們內網的設備，因為在做壓測的時候，其實網路的頻寬也是一個部分。
如果有興趣的話，我可以再附上詳細的壓測報告。
各位與會的朋友大家好，我是PDIS小組的馬克，大家也可以叫我君翰，幫菜價系統做初步的壓測，按照剛剛的選項看起來，其實有十個選項，有些有做壓測，有些沒有，壓測的範圍是八個選項，整體統整一下之後，做了這一份簡報，稍微跟大家說明一下。
是不是因為不好轉所以不轉？
不限於恆春地區？
因為上面的數據看起來五年內沒有任何案件，所以剛剛說申請到成功的轉換率根本就沒有資料？
