C# Nop Commerce产品导入速度变慢，并且随着时间的推移使用实体框架使用更多内存

我需要进口约150000个产品的类别，制造商，图像和属性到Nop商业。我基于Nop.Services.ExportImport.ImportManager编写了一个插件。导入的产品越多，导入过程运行越慢。前100种产品将在1.5分钟内进口。大约2500种产品需要15到20分钟才能进口另外100种产品。一次导入2500多个产品会导致内存不足异常。在2500点停止，然后进行第二次导入之后，运行速度甚至会变慢

以下是插件使用的过程：

创建一个新的产品实体，填充详细信息，然后使用Nop.Services.Catalog.ProductService.InsertProduct插入产品。有必要使用ProductService，因为我们需要Product.ID的值来向产品添加子对象

如果制造商存在，则通过首先搜索添加产品制造商。如果找不到制造商，则使用ManufacturerService创建制造商并添加。然后添加ProductManufacturer实体以将产品分配给制造商。此实体将添加到列表对象中

对类别、规范属性、URL记录和产品标记执行相同的例程

下载第一个图像并使用PictureService添加。PictureService将图片实体插入数据库，然后将图像保存到images目录。然后创建ProductPicture实体并将其添加到列表中

每100个产品，我使用SQLBulkCopy/EFBulkInsert将产品制造商、产品类别、产品图像等的列表插入数据库。然后我清除列表并重新开始

因此，在整个过程中，我们使用实体框架将产品、类别、制造商、产品标签和规范属性逐一添加到数据库中。这是必要的，因为我们需要获取这些项目的ID，以便通过将记录插入映射表将它们分配给产品。添加到映射表中的记录可以添加到列表中，然后使用SQLBulkCopy/EFBulkInsert大容量插入到数据库中

每次添加产品及其特性时，整个过程都会越来越慢。随着时间的推移，它似乎使用了越来越多的内存。我不知道下一步该怎么办

我不确定实体框架是否导致了问题。我已经读到，随着时间的推移，实体框架倾向于使用越来越多的内存，每隔一段时间重置DBContext是一个好主意。问题是Nop通过Nop.Data中的eRepository层管理DBContext

使用EFBulkInsert/SQLBulkCopy将产品属性映射记录添加到数据库似乎可以加快速度。我想可能先用它来插入所有的产品，然后再回去导入属性。我仍然会遇到无法将图片实体批量导入数据库的问题，因为我需要PictureID加上ProductID将图片与产品关联

---

我还考虑过使用ADO.NET和存储过程来逐个插入，但不确定这是否会改善情况。有人有什么建议吗

我是EFUtilities的作者，它可以进行批量插入。对于下一个版本，它将能够从批量插入中返回存储生成的id

目前，这是工作，但没有释放。我希望在本周末或下周末发布。同时，您可以在这里找到它的代码，如果您下载并构建release20分支，您应该能够使用它

下面的测试演示了如何启用Id返回（它的速度稍慢，因此在默认情况下被禁用）

---

我已经看透了你现在面对的一切。但我们有大约3万件产品和图片。我尝试了EF、SSIS和普通SQL脚本

我的偏好是

纯SQL脚本

SSIS

实体框架导入

我曾经将普通SQL脚本编写为一个文件，用于恢复空白数据库的副本，从源数据库读取数据并填充表

使用纯SQL

它很快，但首先很难发展。您需要逐个表构建数据导入表

易于使用打印命令进行调试

如果导入后发现任何错误，可以快速修复并重新运行

另一方面，您应该知道nopcommerce中表之间的所有关系。根据你的问题，我可以看出你对它有很好的理解

使用SSI

很快

发展迅速

如果导入后发现任何错误，可以快速修复并重新运行

使用EF

你的问题说明了一切

现在，如果您遇到可能需要定期导入数据的情况，请编写存储过程并使用ADO.NET调用存储过程来导入数据。这将是导入/更新的最快方式。每次导入完成后，不要忘记在nop admin中调用clear cache

---

来源：我在一个基于nopcommerce的电子商务平台上工作了两年多。

你不能为此选择存储过程吗？

using (var db = Context.Sql())
{
     EFBatchOperation.For(db, db.BlogPosts).InsertAll(list, new BulkSettings
            {
                ReturnIdsOnInsert = true,
            });
}