我有一個WebService ABC的方式來提高其稱之爲休息Webservice的性能的其他API
ABC操作：
1.撥打XYZ Web服務在數據庫
2.存儲響應
3.返回結果
整體ABC響應時間= 18秒
XYZ響應時間= 8秒。
只有ABC響應時間= 18-18 = 10秒
我想盡量減少ABC服務的響應時間。
這怎麼辦？
我雖然沒有幾件事：
1.發送部分請求並獲得部分響應=但它不可能在我的情況。
2.以異步方式返回響應並執行db。 （這可以以可靠的方式完成嗎？）
3.有什麼方法可以改善db寫操作嗎？
如果有可能以異步方式'，即到「」執行分貝，如果你之前可以給調用者迴應數據庫寫入完成後，您可以使用'寫入後'模式異步執行數據庫寫入。
寫入後面的模式如下所示：對每個數據更改進行排隊，讓此隊列受制於可配置的持續時間（又稱「寫入延遲」）和最大大小。當數據的變化，它被添加到後寫隊列（如果它不是已在隊列中），並將其寫入到底層存儲每當下列條件之一滿足：
有大量現有的在這個空間。例如，Spring的Cache Abstraction允許您添加緩存層，並支持符合JSR-107的緩存，如Ehcache 3.x，該緩存提供write behind cache writer。Spring的緩存服務是一個抽象而不是實現，它的思想是當你繼續提供商店和代碼來與商店進行交互時，它會照顧你的緩存邏輯。
除了調用XYZ之外，還應該考慮ABC內部發生的其他事情，如果數據庫調用佔所有這些額外的10，那麼'寫入後面'會節省您10秒，但如果還有其他活動發生在那些10年代，那麼你需要分別解決這些問題。這裏的關鍵點是調用ABC中的調用，以便您可以準確地確定何時花費的時間，然後根據以下因素確定每個階段的優先級：（a）該階段需要多長時間; （b）這段時間可以輕易減少。
如果你移動到「寫的背後」的方法，則DB的經過時間不再是你的來電者的問題，但它可能仍然是 ABC內的問題長期以來寫入次數可能導致的「隊列寫下'指示建立。在這種情況下，您會對數據庫調用進行配置文件以瞭解爲什麼它需要這麼長時間。常見的候選項包括：試圖編寫大量數據項（例如大規模非規範化數據項），試圖寫入索引嚴重的表/存儲區。
據我所知，你可以按照根據您的需要的選項：從緩存響應XYZ的結果
思考和存儲數據庫，這樣可以最大限度地減少通話。
在選項2中可能會出現故障，但仍然可以通過將故障案例寫入錯誤日誌並稍後處理來修復它。
DB寫操作可以通過適當的索引，標準化等來提高..