最近 Funliday-旅遊規劃 常發一些精選旅遊回憶的 App 通知給使用者,在去年十一二月的時候發通知 Server 還能撐的了瞬時大流量的 request。
但今年開始發這類通知,總共發了三次,三次都造成 Server 被打掛,而且重開 AP 還緩解不了,瞬間手足無措。大概都要等過了十分鐘左右,Server 才將這些 request 消化完。
這裡就來簡單整理一下時間軸,順便分享一下 Funliday 是如何解決這個問題。
---
* 1/6 1900:系統排程發送精選旅遊回憶的 App 通知
* 1/6 1900+10s 開始:Server 收到極大量的 request
* 1/6 1900+20s:Nginx 出現錯誤訊息 1024 worker not enough,並回傳 http status code 503
* 1/6 1900+25s:PostgreSQL 出現錯誤訊息 could not fork new process for connection (cannot allocate memory)
* 1/6 1900+38s:Node.js 收到 PostgreSQL 的 exception。There was an error establishing an SSL connection error
* 1/6 1900+69s:PostgreSQL 出現錯誤訊息 database system is shut down
* 1/6 1900+546s:PostgreSQL 出現錯誤訊息 the database system is starting up
---
看了時間軸就覺得奇怪,先不論 10s 的時候發了極大量 request,造成 20s 在 Nginx 出現 worker not enough 的錯誤訊息。而是要關注 25s 時的 PostgreSQL 出現 could not fork new process for connection 的錯誤訊息。
Funliday 用了同時可承載 n 個 connection 的資料庫,而且程式碼又有加上 connection pool,理論上根本不該出現這個錯誤訊息。但整個時間軸看下來感覺就是 PostgreSQL 的 capacity 問題,造成系統無法運作。
因為就算將 Nginx 的 worker connection size 再加大 10 倍,只是造成 PostgreSQL 要接受的 request 也跟著被加大 10 倍,但 PostgreSQL 那裡因為 request 變多,原本在 69s 直接關機的時間點只會提早,而無法真正緩解這個狀況。
基於以上狀況,小編就開始回去看自己的程式碼是不是哪裡寫錯了。會這樣想也是覺得 PostgreSQL 應該沒這麼弱,一下就被打掛,一定是自己程式碼的問題 Orz
---
這邊來分享一下自己程式碼的寫法,圖一是原始寫法,在每個 API 都 create 一個 db client instance 來處理該 API 層的所有 db request。這是蠻單純的做法,也是 day 1 開始的處理方式。但有個小問題,就是每個 API 層都要自己 create instance,不好管理,且浪費資源。
後來因為想要做 graceful shutdown 的關係,所以調整了一下 db client instance 的建立方式,用 inject 將 instance 綁在 request 上面,如圖二。這樣只要在 middleware 建立 db client instance 就好,好管理,而且只要有 req 就可以取得 instance,非常方便。而這也是 1/6 時的程式碼,就從這裡開始研究吧。
---
直接切入 node-postgres 的文件,認真讀了一下 pool 有下面兩種使用方式:
1. pool.connect, pool.release:文件寫著 checkout, use, and return,光看描述就應該用這個沒錯。
2. pool.query:適用於不需要 pool 的連線方式,文件上也清楚寫著內部實作是直接 call client.query,所以用了這個方式是完全跟 pool 扯不上邊。
但偏偏小編從 day 1 用的就是第 2 種方式 Orz,雖然看起來應該是寫錯,但也是要修改後實測,才知道是不是真的可以解決問題。
---
如圖三,這是修改後的程式碼。想了一下子,覺得目前在 API 層使用 req.pool.query 還不錯,不想用官方的建議做法:先 create client,然後 query 之後,再使用 release。
如果照官方建議做法,API 層的程式碼會多一堆與商業邏輯無關的程式碼,也不好維護。所以在不想動到 API 層的程式碼,只能使用 monkey patch 的方式來達到這個需求。
monkey patch 可以將原方法利用類似 override 的方式,將整個方法改掉,而不改變 caller 的程式碼,這也是 JavaScript, Ruby, Python 這類動態語言的特性之一,但真的要慎用,一不小心就會把原方法改成完全不同意義的方法了。
所以原本應該要在 API 層實作 connect, query, release 一大堆程式碼,可以用 monkey patch 完美解決這一大堆程式碼。
---
在 dev 壓測後至少 capacity 可以達到原本的 4 倍以上,隔天實際上 production 之後也確實如壓測般的數據,可以承載目前的流量。
其實這篇分享的重點只有一點,文件看仔細才是最重要的事啦!如果沒把文件看仔細,然後開發經驗也不足的話,什麼 RCA、monkey patch 都幫不上忙啦!
---
後記:有夠丟臉,其實完全用不到圖三,只要把圖二的 pool creation 放到最外層就好了,因為 pool.query 的內部實作已經有做 connect, query, release 了。
感謝下面的 Mark T. W. Lin 及 Rui An Huang 的幫忙,實在是太搞笑了 Orz
* Pool 的文件:https://node-postgres.com/features/pooling
* 官方建議寫法:https://node-postgres.com/guides/project-structure
* pool.query 的內部實作:https://github.com/brianc/node-postgres/blob/master/packages/pg-pool/index.js#L332
#expressjs #nodejs #javascript #postgresql
「middleware是什麼」的推薦目錄:
- 關於middleware是什麼 在 Kewang 的資訊進化論 Facebook 的最佳解答
- 關於middleware是什麼 在 91 敏捷開發之路 Facebook 的精選貼文
- 關於middleware是什麼 在 COMPOTECHAsia電子與電腦 - 陸克文化 Facebook 的最佳解答
- 關於middleware是什麼 在 Re: [系統] 請問資料庫中介軟體為何? - 看板Database 的評價
- 關於middleware是什麼 在 Middleware | Redux 的評價
- 關於middleware是什麼 在 NodeJS入門教學課程16-甚麼是Middleware - YouTube 的評價
- 關於middleware是什麼 在 【筆記】 Redux Middleware 一步一步帶你看!!! - gists · GitHub 的評價
middleware是什麼 在 91 敏捷開發之路 Facebook 的精選貼文
在鈦坦那邊花了蠻多時間把產品架構面的 error handling 機制弄好,不再是到處 try/catch 只寫 log return false.
不再是無謂的 try/catch re-throw exception.
不再是 catch(ex) throw ex; 的該死寫法。甚至吃掉 exception 不做事的情況。
該記 log 的只在邊界層,透過 decorator/action filter/middleware 來封裝與加載。也不再有那種 log 只記到表層的 call stack 而沒記錄到 inner exception 真正的問題發生點。
該做 error handling 或附加 run time 的資訊,handle 完 re-throw 自定義的 custom business exception, 再交給 error handling 底層來觸發對應的 error handler。
在發現問題(例外)的第一時間點 throw exception 通知整個 process 發生了什麼問題。
整個 call stack 與方法簽章都是乾乾淨淨的「正常流程」,沒有不必要的 return true/false 來通知是否有異常,也沒有不必要的 error code Enum 來一路傳遞回呼叫端。
發生怎樣的異常,該決定怎樣的 error code/status code 通知呼叫端,是最後要回傳結果那一層的 error handle 職責與行為。
Error handling 本身就是一整門學問,能在企業等級產品架構裡面打好這段基礎,可以指數性降低 application design 的複雜度。
鈦坦的產品工程師扛霸子之一的 Jrting ,開始把這門知識整理成系列文了,希望能給大家一些幫助。
https://medium.com/@neokn/exception-%E6%80%8E%E9%BA%BC%E4%B8%9F%E6%89%8D%E4%B8%9F%E5%BE%97%E6%BA%96-a385bd27ed15
middleware是什麼 在 COMPOTECHAsia電子與電腦 - 陸克文化 Facebook 的最佳解答
#嵌入式系統 #微處理器MPU #微控制器MCU #專用晶片ASIC #數位訊號處理器DSP #現場可編程邏輯閘陣列FPGA #工業物聯網IIoT
【嵌入式系統=智能互聯】
什麼是嵌入式系統?市調機構看好汽車行業將成為嵌入式運算市場的主要動能——混合動力電動汽車 (HEV) 和純電動車 (EV) 興起,帶領智能系統控制不斷擴張,全自動駕駛尤需運行多個複雜的人工智慧 (AI) 軟體和系統。隨著物聯網 (IoT) 和工業物聯網 (IIoT) 出現,嵌入式技術已成智能生態迅速拓展的推動者。
嵌入式設備通常由系統單晶片 (SoC) 與現場可編程邏輯閘陣列 (FPGA) 等「與硬體集成的軟體」提供動力,以便開發人員針對特定功能進行編程積體電路 (IC) 和其他韌體版本,意謂軟體和硬體已然密不可分。簡單、大批量消費市場的嵌入式系統多由 99% 硬體+ 1% 軟體所組成,但飛機、汽車或高度可靠的工控應用,則以高度專業化、小批量為主;若測試及應用程式繁複,軟體所佔嵌入式系統成本的比例甚或可高達 95%!
嵌入式系統雖是非常成熟的技術,但新一代功能強大的處理器不斷發展,使嵌入式系統幾與「智能互聯」畫上等號,而「智能邊緣設備」(Edge AI) 將促使整個嵌入式系統顯著增長。在分眾市場分面,數十年來,消費電子一直是嵌入式系統的主要市場,但物聯網的出現將賦予它們全新意義——新型感測器和軟體等嵌入式智能已成為主要元素。醫療保健則是嵌入式系統開發最快的應用之一,例如,手持式/可攜式治療設備及用於監測生命體徵的設備。
此外,智能建築和智慧城市的來臨,將使嵌入式系統擴展預測性和規範性,基於 AI 和機器學習 (ML) 實現完全自主和自我修復,前三大 Edge AI 產品分別為:智慧手機、智慧音箱與 AR/VR/MR 等抬頭顯示設備 (HUD)。其中,成長最快速的產品是消費型與企業用機器人及安全監控攝影機。技術挑戰在於:發展低能耗、高準確率的認知計算,包括新型運算架構電路設計、演算法等。預期未來 IoT 裝置所使用的控制晶片,皆將內含 AI 加速晶片。
AI 創新能量蓬勃,演算法每幾個月就有大躍進,如何讓電子器件的開發環境與其無縫接軌,成為影響採用意願的要素之一。於是,各家處理器供應商無不絞盡腦汁在整合開發環境 (IDE)、打包軟體套件、創造韌體差異、各式開發板,乃至與雲端服務供應商 (CSP) 的合作上,目標是為各有專長的工程師形塑「工具鏈」、鋪設一條康莊大道,讓底層基本核心、韌體、中介軟體 (Middleware) 和最上層的應用軟體毫無隔閡。我們日前所介紹的「Microchip MPLAB」系列就是一例。
另為擴大應用,近年 FPGA 在本質上也有了變化:一是整合應特定用途的處理器做異構運算,二是軟核 (軟體為基礎的 IP 內核) 崛起,三是完善開發環境,四是與雲端平台結盟……。
延伸閱讀:
《智能邊緣引領「嵌入式系統」騰飛》
http://compotechasia.com/a/feature/2019/1111/43273.html
(點擊內文標題即可閱讀全文)
#工研院產科國際所 #台灣AI晶片聯盟AITA #微芯科技Microchip #MPLAB #CryptoAuthentication #PolarFire #美高森美Microsemi #賽靈思Xilinx #Zynq UltraScale+RFSoC #芯科科技SiliconLabs #ThunderboardSense 2
middleware是什麼 在 Middleware | Redux 的推薦與評價
Redux middleware 解決了跟Express 和Koa middleware 不同的問題,不過概念上是類似的。它在dispatch action 和action 到達reducer 的時間點之間提供了一個第三方的擴充點 ... ... <看更多>
middleware是什麼 在 NodeJS入門教學課程16-甚麼是Middleware - YouTube 的推薦與評價
學習後端(Back-end) NodeJS,使用Javascript做出網頁伺服器,本節內容有:00:00 甚麼是Middleware01:12 Middleware 用途01:59 Middleware 示範04:43 ... ... <看更多>
middleware是什麼 在 Re: [系統] 請問資料庫中介軟體為何? - 看板Database 的推薦與評價
※ 引述《chrismaggie (中仔)》之銘言:
: 教資料庫高手,這是今年關務特考之考題:
: 何謂中介軟體(middleware)?請舉出常用的資料庫中介軟體,並說明其目的與運作方式?
: 我有參加這次的考試.資料庫除了這題沒什麼把握之外其他都還好,請問何謂中介軟體呢?
: 我是用3-tier的架構去說明中介軟體,就是負責處理轉後前後端的要求與顯示,屬於中間層
: .並且畫出3-tier的架構圖,說明客戶端利用中介軟體來處理需求以及管理後端實體資料庫
: 而我舉例是用mysql.利用phpmyadmin中介軟體來進行資料庫管理與資料搜尋等功能
: 運作模式:clinet-middleware-server方式,利用瀏覽器連線置phpmyadmin介面進行mysql
: 資料庫存取與管理
: 目的:
: 1.資料庫權限控管
: 2.資料查詢
: 3.安全性管理
: 4.資料庫結構管理
: 5.備份與復原機制
: ....等等列點說明
: 我查了網路資料有些說中介軟體是屬於中間層軟體,跟我說得差不多,但有些說中介軟體是
: odbc.jdbc這類的的driver
: 很擔心這題沒有拿到分數.....可否請高手幫忙呢
: 謝謝
我去這個地方查到https://www.oreilly.com.tw/sample_chap/a034_09.pdf
中介軟體的介紹:
“middle tier”又稱為中介軟體middleware,顧名思義,它是在連接之
間進行處理。促使人們廣為在client 和資料來源之間使用middle tier 的最大誘因,
是我們能在middle ti er 中的軟體中置入所謂的商業邏輯。商業邏輯可以把複雜的
低階動作(更新資料庫表格)包裝成高階指令(下訂單),讓資料庫交易動作更容易
也更安全。
想像某個client 應用程式正在下訂單。如果沒有中介軟體,這個應用程式必須
直接連結到資料庫server 儲存訂單資訊。如果server 端有任何更改,不管是
換了機器、內部資料結構改變、或改用其他廠牌的資料庫,原來的client 端軟
體就不能用了。更慘的是,如果cl ient 端軟體稍有改變(不論是故意或意外
的),資料庫在收到對方付款之前不可能輸入訂單,也無法拒絕一筆正常的訂
單。
中介軟體能運用商業邏輯把訂貨流程抽象化。它接收訂單資訊(包括名稱、
地址、項目、數量、信用卡號等),檢查這些資訊是否有效,再把它們存入資
料庫。資料庫如果有改變,中介軟體也要跟著改變,但cli ent 端不必更動。即
使這個訂單資料庫臨時以一個單層的紀錄檔取代,中介軟體在client 端還是呈
現同樣的面貌。
中介軟體能把處理負載分散到不同的後端server 上(CPU server、檔案
server、目錄server 等),從而增進交易效率。運用中介軟體,我們可以更加
有效的運用頻寬:client 不必在低速網路連結上自己一來一往和server 溝通,
只要把要做的事情告訴中介軟體,讓它一次做完即可。
Web上的中介軟體常以servlet 實作。Servlet 提供了一種簡便的途徑,讓利用
HTML form或applet 建立的client 連接後端的伺服器。Client 可用HTTP 把需
求告知s ervlet,servlet 中的商業邏輯則透過後端伺服器來處理它的請求.
我是覺得我寫的應該不至於全部的分數都沒有阿~我也是以3-tier概念去解釋
中介軟體.....這樣會全錯嗎...很擔心> <
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.223.207.121
※ 編輯: chrismaggie 來自: 61.223.207.121 (07/07 00:31)
... <看更多>