2011-11-19 84 views
1

什麼是您的「平均」Magento Core API響應時間?我得到〜1.5秒只是做一個SOAP調用並返回一個數字(我已經有一個肥皂對象和會話ID)。不確定是否可怕的服務器或magento。magento api響應時間

有關改善Magento API響應時間的任何提示?謝謝。

+0

是否在客戶端啓用了wsdl緩存?您的magento實例上是否啓用了Web服務配置緩存? – Zyava

+0

不是我所知道的,我會去看看。謝謝。 – Mike

回答

1

我不認爲知道其他用戶使用他們的單個Magento SOAP API調用的「平均」響應時間對此會有很大的幫助。

只要這些其他用戶沒有請求非常相同的服務器,至少從同一子網的客戶是,這將導致在比較蘋果和桔子。

我可以確認,某些Magento SOAP API方法可能的服務器端執行時間會相當耗時。特別是,如果正在使用的SOAP API方法導致許多數據庫寫入的數據,這些數據是以EAV方式建模的並且具有大數據庫

但是,你似乎正在談論的方法只是閱讀通過SOAP的價值(你沒有提到你準確使用哪種API方法),我懷疑它的API方法代碼是緩慢的。

我強烈建議,首先確定您的要求的位置,實際的瓶頸是

  • 客戶端
  • 傳輸
  • 服務器端

甚至開始之前試圖優化API方法。

瓶頸可能是是一個或兩側(客戶端/服務器)上的緩存/系統配置錯誤的結果。

或者有一個客戶端/服務器永久運行在重載下。

無論出於何種原因(或想要擁有700毫秒的ping)或者往返時間較長(RTT)。

或者它可能是客戶端的DNS查找速度減慢。

或者它甚至可能是瀏覽器只是緩慢地呈現請求的輸出,因爲輸出使用複雜的佈局並下載數百個其他文件(呵呵,曾經那樣,討厭它^^)。

我可能會首先向服務器快速發送ping(與您的請求並行)以查看RTT並知道我是否可以將傳輸排除在瓶頸之外。

如果你使用Firefox,你也可以直接看看Firebugs Net面板。檢查請求時間表以查看瓶頸是客戶端,dns /傳輸還是服務器端。

+0

首先,它是我正在使用的服務器,用另一臺服務器進行測試,得到0.5秒的響應。也將def查看其他建議。謝謝。 – Mike

+0

嘿@Jurgen,一旦排除客戶端和傳輸瓶頸,您是否有關於如何進行性能分析API調用的技巧?我在這裏發佈了一個關於它的問題:http://stackoverflow.com/questions/11479722/easy-way-to-profile-magento-api-calls – kalenjordan