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