tags: Case

2023/5/6 OpenDB會議紀錄

insert 資料壓力測試

insert 資料壓力測試demo

• 刪除昨天壓力測試的資料
• 壓力測試工具-locsut : python套件(蝗蟲)
• 壓力測試內容 : 把event POST上去

Ashley:看一下payload
翊全:

--master // --worker 連結到網頁在port8089
spawn rate:每秒增加幾個user
charts 看到每秒insert多少資料lost多少資料
server 最多 loading 400-500 requests(極限)
中間loading 300 requests

Ashley:如果spawn rate設300以內
益全:400以內可以，不知道這樣夠不夠(是否可以符合警局要求)
品妤:目前只知道搜尋的request (10秒5000萬筆資料搜尋)
solomon:

查詢的效能，當初對廠商的要求是「5000萬筆資料，3碼模糊查詢，必須在10秒內完成」 .
警局口頭說：「目前一天約有20萬筆車牌辨識資料加入 database. 」
但我們覺得沒這麼少
我們目前已高於警局口頭要求了。

機房的server memory和cpu 比較高檔
解決方法(提高可承受的requests數):
1. 用機房的設備建server(private ip)->之後跑在警局設備
2. kubernates(暑修後可嘗試)
3. SQL 改成in-memory存資料(若問題出在SQL)  //目前還不知道是flask還是SQL

結論:先嘗試第一種解法:server跑在警局設備

搜尋資料測試

• 不需要多個requests(寫論文才要測試)，一個就好
• 目前因為硬體空間不足，所以無法把資料匯入資料庫->改到下星期三測試(5/10)

小組進度匯報

SQL:

1.改address到camera table(刪除event table的address)
2.新增三個table(camera table只留下殂存英文和數字的column->省空間)
3.目前eventID和serchID流水號已生成
結論:第二版再改(目前只改hackmd)

待改善事項

• 目前硬體空間未擴充
• SQL 使用read script的方式刪除資料較有效率

下次會議

• 5/10 MPI後搜尋資料測試(各組準備好code放到新server)
• 5/23 10:00 - 12:00 和警局開會，正式上線第一版（各組交ppt給PI）

solomon: I am proud of you !