如何改进PHP'；XML加载时间是多少？

放弃我的潜伏者身份，最后问一个问题

我需要知道如何提高从XML文件中提取数据的PHP脚本的性能

一些背景：

• 我已经将瓶颈映射到了CPU上，但我想在降低处理器成本之前优化脚本的性能。具体来说，脚本中占用CPU最多的部分是XML加载

• 我之所以使用XML存储对象数据，是因为需要通过浏览器Flash界面访问数据，我们希望在该领域提供快速的用户访问。不过，该项目仍处于早期阶段，所以如果最佳实践是完全放弃XML，这也是一个很好的答案

• 大量数据：目前绘制大约10万个对象，尽管通常是小对象，但它们都必须包含在脚本中，可能有少数例外。数据集只会随着时间的推移而增长

• 频繁运行：理想情况下，我们每小时运行脚本约5万次；实际上，我们满足于1k/h的运行。这加上数据大小，使得性能优化完全势在必行

• 已经采取了一个优化步骤，在同一个数据上进行多次运行，而不是每次运行都加载数据，但仍然需要很长时间。运行通常应使用“新鲜”数据，并由用户进行修改

---

如果XML保持相对静态，可以将其缓存为PHP数组，如下所示：

<xml><foo>bar</foo></xml>

条

在文件中缓存为

<?php return array('foo' => 'bar');

---

只是澄清一下：您正在加载的数据是否来自XML文件，以便在当前状态下进行处理，并且在发送到Flash应用程序之前是否正在对其进行修改

看起来最好使用数据库存储数据并根据需要推出XML，而不是先用XML读取数据；如果生成XML文件的速度变慢，您可以在生成文件时缓存这些文件，以避免重复生成同一文件。
~1k/小时，3600秒/小时，每秒运行3次以上（更不用说50k/小时了）

有很多问题。其中包括：


您的php脚本是否需要为每次运行读取/处理数据源的所有记录？如果不是，它需要什么样的子集（~size，criterias，…）
对于flash应用程序+谁在发送数据，同样的问题？php脚本？“直接”请求完整的静态xml文件
对数据源执行哪些操作
您需要某种并发机制吗


仅仅因为您希望将xml数据交付给flash客户端，并不一定意味着您必须将xml数据存储在服务器上。例如，如果客户端只需要可用记录的一小部分，则不将数据存储为xml，而是更适合于速度和“可搜索性”，然后动态创建子集的xml输出，可能会快得多，根据客户机请求的数据以及数据更改的程度，可能需要一些缓存来辅助

编辑：假设您真的，真的需要整个数据集，并且需要一个连续的模拟。然后，您可能需要考虑一个连续的过程，它将完整的“世界模型”保存在内存中，并在每次运行（世界嘀嗒声）上对该模型进行操作。这样，至少您不必在每个刻度上加载数据。但是这样的过程通常是用php以外的语言编写的。
这就是我要建议的+1是的，100k对象最好保存在嵌入式数据库中，如果您可以访问，最好保存在专用数据库中；然后，您可以生成客户端所需的xml数据。澄清一下：Flash界面和运行是完全独立的，只是运行修改了一些最终可显示的数据。但运行与用户是否查询对象无关。来自XML的数据处于当前状态；当发送到Flash时，它不会被修改。但是，用户可以通过界面对加载的文件进行更改。问题是，尽管用户访问速度更快，但使用DB是否会加快运行速度？目前我们更关心这个问题。在实际运行的情况下，您似乎可以从数据库中获得性能提升；与每次解析XML相比，加载数据的开销将显著减少。这至少可以降低每次跑步的成本。这是一个很好的答案，但我们已经同时进行了几次跑步；XML预计不会在几秒钟内保持特别静态，但我们允许几分钟的更改在几次运行中溜走。之后，我们必须进行所有更改，这意味着重新创建阵列。仍然非常CPU密集。为了澄清，运行应该在后台工作，处理最终将显示给用户的数据。-我们每次运行都需要每个对象的数据。-当用户查看界面时，界面会调用特定的XML文件，以便知道显示什么。-不需要并发机制——我认为我们在这方面还可以。搜索能力对用户来说都很好，但是在后台运行时使用DB会更有效吗？这是当前关注的问题。如果是后台进程，为什么需要重复读取/加载整个数据集？如果你说你必须这么做，我们可能不得不相信你；-）但在php论坛上，这样的问题很多时候都会被问到，归结起来就是“不，你不需要（几乎）连续的模拟”。您能否更具体地说明数据集以及每次运行时要执行的操作？然后我会尝试删除文件或至少是重复的加载操作。即a）进行模拟，b）接受和服务SUB请求的连续运行过程