# 优化feeds性能
理想的规模取决于许多因素，包括提交feeds的速度，feeds之间共享的SKU数量，以及正在更新的ASINs的类型(关系较多的ASINs需要更长的时间来更新).我们建议每个feeds开始时粗略估计为30,000 -50,000次更新，然后调整规模和提交速度，直到维持最小的正在进行的feeds积压.
**审查并限制你需要更新的清单数量：**只包括你要更新的产品，而不是你的整个库存.
**确定你的feeds提交率：**每20分钟上传一个相同类型的feeds不超过一次.允许更大的feeds之间有更多的时间.
**确定你的feeds提交文件的大小：**将文件大小保持在10 MiB以下(5*221，或10,485,760字节).如果你的文件超过了建议的大小，请通过将其划分为不同的较小的提交来调整.
**根据积压的大小来调整feeds提交率：**等待以前的feeds完成后再重新提交.
# 优化feeds处理
避免提交大量的馈送，每个馈送中只有几条记录.可能时，将数据合并到频率较低的大型馈送中.
**一个库存相关的馈送和一个订单相关的馈送可以同时处理：**库存馈送和订单馈送是分开处理的.如果多个库存馈送(或多个订单馈送)是按顺序提交的，它们将在前一个完成后被处理.
当使用POST_PRODUCT_DATA馈送时，避免为相同的SKU提交价格、库存和其他馈送： POST_PRODUCT_DATA馈送可以与价格、库存和其他XML馈送一起处理. 然而，如果价格、库存和其他馈送提到产品馈送尚未完成处理的SKU，它们将失败. 你应该在产品馈送完成后将价格、库存和图片更新序列化.
**除POST_PRODUCT_DATA之外的所有库存馈送可以同时提交：**例如，价格、库存可用性、关系和图像馈送都可以同时提交.
**同一类型的馈送是按顺序处理的：**这适用于所有库存馈送类型. 例如，如果你提交两个定价馈送，每次只处理一个.
**避免提交多个小型进料：**每隔几秒钟上传许多小型进料是非常低效的，可能导致积压，阻碍其他进料的处理，并迫使你取消一些先前提交的进料.
# 不要依赖文件ID结构
你不应该依赖文档标识符的格式和结构.这些标识符的格式和结构(如feedDocumentId，这是调用getFeedDocument操作所需要的)是可以改变的.