2016-10-10 47 views
0

我的系統架構是一個Web應用程序服務器,它運行PHP-Slim 3的LAMP堆棧以充當API和Web應用程序前端。該API允許獲取請求來檢索數據,但也允許傳感器設備每秒對其進行POST。在同一臺服務器上,我們運行一種用Python編寫的處理算法,每5分鐘執行一次處理600秒的數據。PHP Slim應用程序MongoDB - 獲取請求阻止發佈請求

MongoDB位於單獨的服務器上,並擁有自己的資源。在一開始只有很少的傳感器,性能就像你想象的那樣好。但隨着時間的推移,隨着索引與數據量成比例增長,以及發佈數據的傳感器數量不斷增加,來自Web應用前端的獲取請求已經放緩,即使顯示圖形也會導致很大的延遲,發佈傳感器數據。這是一個大問題,需要爲我們解決。

我一直在想,Web應用程序可能需要分解成3個組件 - 一個用於POST API的Web服務器,一個用於Web應用程序,另一個用於處理API獲取請求。這樣我們就有3個到MongoDB服務器的單獨連接,並且希望我們不會在發佈數據時獲得請求的不利阻塞效果。

我的問題是,我將如何開始使用PHP Slim做這件事?

+0

嗯,這聽起來不像Slim那樣的問題,或者可以單靠Slim解決。 你試過緩存嗎?例如,您可以使用Redis緩存非規範化/準備顯示數據。 能否請你解釋一下「用Python編寫的處理算法,每5分鐘執行一次處理600秒的數據」? –

+0

我會研究緩存,因爲我們目前肯定沒有這樣做。處理算法採用一批最近600年的傳感器數據,並執行許多不同的轉換來規範數據(因此爲什麼這是在Python中完成的)。它每5分鐘運行一次crontab,並處理過去10分鐘內所有傳感器設備的數據。擴大更多傳感器和連續記錄數據將使我進入大數據領域。 – ugotchi

回答

0

這真的不是一個苗條的問題,這是一個數據庫問題。您的超薄應用程序很可能只是從數據庫中提取數據......製作瓶頸要麼是等待數據庫響應的時間,要麼是將所有數據從數據庫發送到超薄應用程序的傳輸時間。

試圖找出瓶頸在哪裏。在CLI中運行數據庫查詢並查看在本地獲取數據需要多長時間......如果是MB數據,那麼即使在數據中心中的傳輸時間也會成爲問題....我已經看到了蹩腳的DCs有500kbs,所以即使是幾MB的數據也會明顯變慢。