长时间运行的 Magento 进程答案

【问题标题】：Long-Running Magento Process长时间运行的 Magento 进程
【发布时间】：2012-08-27 16:07:08
【问题描述】：

任何人都有使用长期运行的 Magento 进程来减轻开销的经验。例如，对订单或客户资源的典型 Magento API 调用可能需要 1 秒或更长时间，其中可能有一半时间花在 Magento 开销上，而不是特定于相关 API 资源。

那么，如果 Magento PHP 进程在内存中启动并维护，等待 API 请求，这样它就可以处理它们而无需每次都加载 Magento。

我对长时间运行的 php 脚本的大部分搜索都出现了与 PHP 脚本故障排除相关的问题/问题，这些问题需要比预期更长的时间来运行它们正在处理的数据量的 b/c 等 - 所以我我发现很难找到关于这类事情的好资源，如果可能的话。

更新：更具体地满足我的需求：

我已经为简单的 GET 设置了 memcached，我们可以安全地缓存服务器端。
我现在要优化的是写操作。
使用 REST API，因此无需加载任何我们关心的 WSDL。

【问题讨论】：

对潜在的内存泄漏保持高度警惕很重要......
通常你必须在 PHP 中实现 web 服务器（我相信那里有很多实现），引导 Magento，然后为每个请求分叉一个进程。需要考虑很多内存/资源管理。 APC 和 memcache 通常用作模仿行为的机制。您可能正在寻找与 Application Scope 类似的东西（例如在 Java/.NET 应用服务器中）。
谢谢@beeplogic。任何指向 APC / memcache 基准的链接？我们已经将 memcache 用于可以安全地完全缓存的 API 响应（主要是 GET），但对于 POST，我们没有使用它。我将进一步研究 APC。就 memcache 而言，我们实际上是否可以只缓存一个 magento 模型，然后从 memcache 的独立 PHP 文件中加载它，而不需要任何 magento 加载开销并使用它？这似乎不可能，但很棒。
我不知道任何有关性能的链接，但我确信它们就在那里。应该可以将一些对象存储在 APC 中，尽管如果它们有资源或包含某些 XML 对象，它们会抛出错误，因为它们不支持序列化。在这些情况下，您必须重写模型并实现 __serialize/__deserialize 方法来处理这些情况。

标签： php performance magento

【解决方案1】：

您可能想查看proc-open，并且您需要做很多通常发生在操作系统本身的管理。

但是，如果问题在于速度，而不仅仅是想要一种方法来管道/分叉以利用可用的硬件，我会考虑简单地找到整个系统的瓶颈，并在深入研究之前进行缓存。例如 WSDL 缓存、数据库规范化、OP 代码缓存甚至 memcache 或反向代理缓存。 Alan 在他的 Mercury API 产品中确实有 WSDL 缓存 (http://store.pulsestorm.net/products/mercury-api)

我之前使用proc-open 使用相同的方法在不到 8 小时内将超过 500k 客户记录（通过我可能添加的 Magento 模型（堆栈））与地址导入 32 核系统上的 Magento。一个 PHP 文件作为主要入口点，基于数据块的新进程被派生到一个辅助 PHP 文件，该文件进行实际导入。

我确实利用这个小脚本对我提到的导入进行了多线程处理，尽管这不是您问题的确切答案，因为它似乎不是非常面向技术，但希望能提供一些关于可能性的见解：

【讨论】：

感谢@Boomer！所以，我最近实际上读到了 Alan 的 WSDL 缓存收益——相当激烈——但我们实际上使用的是 REST API，所以不确定这是否适用于我们。数据库规范化 - 鉴于 Magento 本身在现有数据库结构方面施加了相当多的影响，有很多事情可以做吗？我们创建的自定义表相当少。 OP 代码缓存 - 去检查一下。 Memcache / 反向代理——我们已经为简单的 GET 设置了这个，我们可以在服务器端缓存它，但是我们想要更多地关注写入。
你可能想看看插入缓冲：dev.mysql.com/doc/refman/5.0/en/innodb-insert-buffering.html