Question

我有一个静态的大型数组，表示大约有100k个节点的树结构，这个数组只是值锁定的只读参考。

现在，这种方法的女巫会表现得更好吗？

首先，简单地在纯PHP文件中定义数组，包含在请求中

其次，序列化此数组，gzip序列化输出，并加载gzip文件并对每个请求进行反序列化

或者将数组转换为SQLite或者类似的东西，但是存储必须能够快速锁定长的“ID路径”，即。 1-> 5556-> 123-> 45-> 455-＆gt; Node_name（实际上PHP表非常好）

服务器上的内存限制不是问题

Answer 1

无论如何，你需要将数组转换为PHP值，所以gzip就出来了。

因此，如果您要决定使用类似sqlite的东西将它保存在磁盘上，或者只是让PHP每次都加载它（最好启用APC），真正的问题是对您，内存或CPU更重要。如果您还不知道，您可能会遇到过早优化的情况。

当与您相关时，无论是减少内存还是cpu，（或者io）答案都会更明显，所以请确保您可以轻松重构。

如果您想预测什么对您更好，请做一个基准测试。

更新我刚看到内存显然不是问题。转到PHP数组并包含该文件。简单。请记住，如果总数据大小为10MB，则每个apache进程为10MB。在100个apache进程中，这已经是1GB。

Answer 2

考虑到您在每个请求上加载整个文件，这些加载时间实际上看起来非常好。 gzip可能有所帮助（通过减少必须从磁盘读取的数据量）

如果你想要它更快或者该文件可能变得更大，或许可以考虑在不加载整个文件的情况下寻找提取你想要的东西的方法 - 指向树节点/ fseek / hashtables /等的指针。

如果你可以找到一种方法来查找你真正想要的数据，只需加载它而不是加载整个文件，这会加快速度。

Answer 3

我的基准测试正在告诉所有事情：

纯PHP文件大小：~5 MB

Pure PHP file import: avg load time: ~210 ms
Pure PHP file import with APC: avg: ~60-80 ms
Unserialize(gzuncompress(file_get_contents()) : almost const, every request: ~ 40 ms

SQlite我没有测试，因为时间不够，将这个树结构移植到SQL DB中

~host是4核心Intel Xeon与HT，硬件RAID 5

存储大型PHP数组，纯PHP或gzip序列化数据？

3 个答案: