我們正在主持一個包含30位用戶的應用程序。每10分鐘我們發送一個_GET_FLAT_FILE_OPEN_LISTINGS_DATA_
請求。如果完成,我們每4分鐘查一次。星期五之前一切順利。我們甚至每兩分鐘就看一次。並在不到10分鐘的時間內得到結果。現在(從星期五開始),我們不得不等待一個多小時。我們沒有改變任何東西。沒有錯誤,不應該有節流?是否可以通過關閉AWS API來做些什麼?那麼每個人都轉向MWS? 亞馬遜MWS支持速度緩慢,他們不回答我們,這就是爲什麼我們在其他用戶尋求幫助的原因。自星期五以來你有類似的問題嗎? 這可能是什麼原因?亞馬遜MWS未處理我們的請求。 [無錯誤,無節流]
P.S.我們正在使用PHP庫。 我們用MWS Scratchpad查找了ReportRequestList。請求已成功交付。所以只有問題是,亞馬遜現在需要很長時間來處理ReportRequest。
就像羅伯特所說的,正好一個星期後問題就消失了。沒有什麼可以對抗的(如果有的話,請讓我知道;)),所以保持冷靜,如果這發生在你身上。
嗨羅伯特。 不幸的是'_GET_FLAT_FILE_OPEN_LISTINGS_DATA_'報告是唯一一個能夠滿足我們需求的人。但有4列是小報告之一。 從'_SUBMITTED_'到'_IN_PROGRESS_'的延遲。 '_IN_PROGRESS_'到'_DONE_'通常很快。 但是看起來,其他報告類型的處理要快得多,因爲我可以用便箋簿看到。我現在會測試,如果我用Scratchpad發送'_GET_FLAT_FILE_OPEN_LISTINGS_DATA_'報告會更快。 –
@MichaelHirn我認爲問題不在於報告被請求的方法,而是亞馬遜生成有問題的報告。我很想看看你的測試發現了什麼。 –
我測試了一些東西。 1)任何類型的請求緩慢地獲得handeld。如果我將它們與PHP庫或從暫存器一起發送,則無關緊要。 2)更改應用程序名稱既不會將MWS端點從https://mws.amazonservices.de更改爲https://mws-eu.amazonservices.com,也不會產生任何正面影響。我真的不能理解這種行爲。 –