2016-05-17 89 views
0

因此,我有一個在Azure上運行的Web應用程序,並且有一個API端點將處理一個漫長的過程(大概我可以說)。在visual studio上運行local時很好,但當它變成天藍色時,在請求開始55秒後失敗。Azure Web Apps Timeout long process request

我有研究發現這個問題在每個平臺上,我改變了在終點上添加這行代碼的機會。

System.Web.HttpContext.Current.Server.ScriptTimeout = 10000; 

所以,現在它能夠延長到超時,但仍然無法在3分50秒後處理。在這一點上,我發現還有其他的東西叫負載平衡器。他們都表示,Azure負載平衡器將在4分鐘後自動終止所有請求。所以我堅持在這個地方。

所以我嘗試了所有這些解決方案。

1.System.Web.HttpContext.Current.Server.ScriptTimeout = 10000; 2.System.Net.ServicePointManager.SetTcpKeepAlive(true,30000,30000); 3.使用「啓動新線程」來處理長進程並將http狀態代碼返回給客戶端,初始化進程已啓動。 4.做長時間的過程作爲另一個異步功能

我想要實現的很簡單,一個長的過程函數可以被調度程序任務或手動觸發(AJAX調用)。

有什麼建議嗎?

+0

我認爲你需要打破你對API的客戶端會發生什麼,然後在服務器端會發生什麼情況的說明(或者你想要發生)我很好奇看到更多關於方法的細節3.你立即返回的地方 - 爲什麼會失敗? –

+0

@ G.Stoynev客戶端將是一個AJAX調用,第一個設計是將請求發送到服務器,然後服務器在這個長的過程完成後返回,而服務器端則是啓動過程的整個流程(檢查,添加數據到數據庫,但記錄是巨大的)。對於方法3來說,這只是我的愚蠢想法,所以讓我們說客戶不希望得到結果,而是說過程完成與否,它從服務器獲得響應並向用戶顯示「過程開始」。所以線程會喜歡在後臺運行,它不需要響應任何結果給用戶。 有何建議? –

+0

如果客戶端啓動Ajax調用並且服務器返回http接受狀態(如果請求已開始處理但未完成),那麼該如何處理?在客戶端,onsuccess處理程序可以重新查詢服務器,直到它接收到指示完成的http確定狀態。當然客戶必須知道正確的方式來唯一地識別操作。 –

回答

1

這就是我在這個過程中安頓下來的方式。

如果這是一個長遠的過程,它應是處理基於Web的工作,我必須通過使用Visual Studio Azure的WebJob SDK 2015年

而且重寫整個過程分爲webjob,爲了加快整個過程(只是爲了節省Azure信用費用),我直接使用DatabaseContext並使用匿名類型在ToList()上創建每個所需的表runnig。 Finanlly,我得到需要插入的項目列表,並使用BulkInsert。

一切都在3分鐘內完成Azure運行時間爲70k條目。

//更新我仍在使用WebJob一些後臺進程最新執行

,但我加快利用EntityFramework BulkInsert,與Parallel.ForEach()沿着我的邏輯過程我的過程。 此外,在處理批量更新時,我還使用Parallel.ForEach()與using(var context=new DatabaseContext()){...}。 (有bulk.update庫在那裏提供良好的解決方案太)

此外,我做嘗試Azure.Functions,似乎是替代Auzre.WebJob。通過使用相同的隊列觸發器,它的速度比WebJob更快。

對於所有後臺進程,Azure都爲您提供少量解決方案,只需分享任何需要此功能的人即可。

  • WebJob
  • 功能
  • 邏輯應用
1

我認爲你達到了Azure Web Apps的默認超時時間(如果我沒記錯的話,我認爲它是3分鐘,但可能是錯誤的)。你能設置SCM_COMMAND_IDLE_TIMEOUT從門戶 - 網絡應用程序設置=>應用程序設置=>添加設置所需的值(說360(以秒爲單位))。 Reference。 有一些功能可以在外部操作超時的情況下終止(信息位於上面的鏈接中)。

+1

這與http請求超時有什麼關係?它表示這個值是關於「默認值」,當你的構建過程啓動一些命令時,它可以運行長達60秒而不產生任何輸出,如果時間不夠長,你可以延長它,例如使它成爲10分鐘「 –

0

雖然我沒有回答你的大部分問題,但我選擇表達一個意見,你的「3」選項,立即向AJAX客戶端返回成功狀態是您解決問題的第一步。

實現TCP/IP/HTTP流量的網絡基礎設施在看起來空閒時間超過您的典型Web請求時間的連接上皺眉。這些行爲通常不在應用程序之外(層) - 在較低的基礎架構層。你可能有或沒有訪問這些,如果你這樣做,你可以「修復」你的問題。

使用選項3.從您的問題中,結合輪詢或某種形式的推送通知是您更好的解決方案IMO。