TA貢獻1893條經(jīng)驗 獲得超10個贊
謝謝各位的回答。這邊我自己總結(jié)了一下,根據(jù)我自己的實際情況主要前臺異步提交一個請求，后臺進行異步組合報表。然后通過1.郵件的方式通知用戶2.通過定時器將消息PUSH給用戶,讓用戶去相應(yīng)的地址上下載查詢時間精確到秒。在用戶請求之前,先告訴用戶在這個時間段訂單個數(shù)。我們可以設(shè)定一個合理的值來提示用戶(改動最小)采取任務(wù)的形式,前臺提交一個任務(wù)給后臺,后臺創(chuàng)建一個任務(wù)，并且存入數(shù)據(jù)庫。前臺可以每隔30s向后臺請求,獲取任務(wù)的狀態(tài),以防止超時。相應(yīng)的前臺有一個loading框(這里也可以改成將文件的生成過程放在服務(wù)端,然后這里給用戶返回的是一個連接,用戶可以直接點連接來下載文件)(這個類似使用AJAX的長連接模式)把分析過程放在服務(wù)端。服務(wù)端起一個定時任務(wù),隔段時間去分析這些數(shù)據(jù)。直接生產(chǎn)文件放在服務(wù)端。可以提供給用戶一個下載列表直接提供給用戶下載5.優(yōu)化流程,采取dubbo批量數(shù)據(jù)請求。采取dubbo異步請求。多線程處理數(shù)據(jù)。多個dubbo服務(wù)合并(性能優(yōu)化)
TA貢獻1946條經(jīng)驗 獲得超3個贊
最直接的辦法便是，壓縮數(shù)據(jù)(例如導(dǎo)出時進行壓縮)，調(diào)整CGI超時時間。這其中，可以考慮節(jié)省CGI進程(因為即使輸出成果已經(jīng)完成，按照題主的說明，fast_cgi的responsebuffer肯定是遠遠小于這次輸出的大小)，在最后輸出的過程上用其他服務(wù)(例如直接用nginx)代勞。其實，例如在問題中的這種從產(chǎn)品設(shè)計的角度解決問題在我看來最優(yōu)解，實時下載真的是那么必要嗎？
舉報