我有一個要求,即將推送通知發送到在iOS和Android上運行的應用程序,總共安裝約200萬次。我使用Azure通知中心構建了一個PoC。這項工作很好地針對我可以借用的少數手機/平板電腦進行測試。我也嘗試過與亞馬遜的SNS一樣的功能,而且效果也很好。負載測試通知集線器
我沒有理由相信集線器不會按需要擴展,但我想知道是否有任何負載測試的規定。我不能借用2米手機,但也許我可以配置集線器來呼叫我託管的服務,從而模擬對GCM或APNS網關的推送?這將有助於建立對端到端性能/容量測試的信心。
我有一個要求,即將推送通知發送到在iOS和Android上運行的應用程序,總共安裝約200萬次。我使用Azure通知中心構建了一個PoC。這項工作很好地針對我可以借用的少數手機/平板電腦進行測試。我也嘗試過與亞馬遜的SNS一樣的功能,而且效果也很好。負載測試通知集線器
我沒有理由相信集線器不會按需要擴展,但我想知道是否有任何負載測試的規定。我不能借用2米手機,但也許我可以配置集線器來呼叫我託管的服務,從而模擬對GCM或APNS網關的推送?這將有助於建立對端到端性能/容量測試的信心。
我相信這不被支持。如果有負載測試功能,它是Azure的內部功能,不提供給公衆使用。
但是,Microsoft確實爲通知中心的基本層和標準層提供了SLA。他們聲稱他們使用通知中心服務爲Bing新聞應用提供諸如突發新聞警報之類的內容。 SLA保證在五分鐘(超過一個月)內成功發送99.9%的郵件。
服務總線SLA(涵蓋通知集線器)是在這裏:http://www.microsoft.com/en-us/download/details.aspx?id=4767
我無法找到GCM或APNS的SLA。
通知中心提供了相當豐富的報告API,您可以使用OData過濾器進行查詢,以確定在給定時間段內發送了多少通知。
但是我認爲影響服務整體的可變負載條件意味着沒有對任何交付的具體及時性(在五分鐘保證交付時間內)做出具體承諾。換句話說,您的所有200萬通知可能會在15秒內發送,也可能需要4分鐘才能發送第一條消息,並且所有消息均以4.9分鐘發送,具體取決於還有哪些人正在使用該服務,以及他們正在使用它。
另外 - 它可能取決於您是使用模板和標籤發送消息,還是您計劃單獨排隊將200萬本機消息排隊到特定註冊。如果你正在做後者,我會認真傾向於將後端服務完全排在Azure上。如果前者,那麼你需要兩百萬個獨特的設備註冊。您可能想要在部署的生產應用程序中構建一個靜默測試通知功能。 –