衡量成功
唯一能确认我们对代码所做改进是否有效的方式是：衡量一个糟糕的情况，然后对比我们已经应用改进后的衡量情况。换言之，除非我们知道 “解决方案” 能帮我们到什么程度 (如果有的话)，否则我们并不知道它是否是一个解决方案。
我们可以关注两个指标。首先是 cpu 使用率。我们要处理的过程运行得有多快或多慢？其次是内存使用率。脚本执行要占用多少内存？这些通常是成反比的 — 这意味着我们能够以 cpu 使用率为代价减少内存的使用率，反之亦可。
在一个异步处理模型 (例如多进程或多线程 php 应用程序) 中，cpu 和内存使用率都是重要的考量。在传统 php 架构中，任一达到服务器所限时这些通常都会成为一个麻烦。
测量 php 内部的 cpu 使用率是难以实现的。如果你确实关注这一块，可用考虑在 ubuntu 或 macos 中使用类似于 top 的命令。对于 windows，则可用考虑使用 linux 子系统，这样你就能够在 ubuntu 中使用 top 命令了。
在本教程中，我们将测量内存使用情况。我们将看一下 “传统” 脚本会使用多少内存。我们也会实现一些优化策略并对它们进行度量。最后，我希望你能做一个合理的选择。
以下是我们用于查看内存使用量的方法：
我们将在脚本的结尾处使用这些方法，以便于我们了解哪个脚本一次使用了最多的内存。
我们有什么选择？
我们有许多方法来有效地读取文件。有以下两种场景会使用到他们。我们可能希望同时读取和处理所有数据，对处理后的数据进行输出或者执行其他操作。 我们还可能希望对数据流进行转换而不需要访问到这些数据。
想象以下，对于第一种情况，如果我们希望读取文件并且把每 10,000 行的数据交给单独的队列进行处理。我们则需要至少把 10,000 行的数据加载到内存中，然后把它们交给队列管理器（无论使用哪种）。
对于第二种情况，假设我们想要压缩一个 api 响应的内容，这个 api 响应特别大。虽然这里我们不关心它的内容是什么，但是我们需要确保它被以一种压缩格式备份起来。
这两种情况，我们都需要读取大文件。不同的是，第一种情况我们需要知道数据是什么，而第二种情况我们不关心数据是什么。接下来，让我们来深入讨论一下这两种做法.
逐行读取文件
php 处理文件的函数很多，让我们将其中一些函数结合起来实现一个简单的文件阅读器
我们正在阅读一个包括莎士比亚全部著作的文本文件。该文件大小大约为 5.5 mb。内存使用峰值为 12.8 mb。现在，让我们使用生成器来读取每一行：
文件大小相同，但是内存使用峰值为 393 kb。这个数据意义大不大，因为我们需要加入对文件数据的处理。例如，当出现两个空白行时，将文档拆分为多个块：
有人猜测这次使用多少内存吗？即使我们将文本文档分为 126 个块，我们仍然只使用 459 kb 的内存。鉴于生成器的性质，我们将使用的最大内存是在迭代中需要存储最大文本块的内存。在这种情况下，最大的块是 101985 个字符。
生成器还有其他用途，但显然它可以很好的读取大型文件。如果我们需要处理数据，生成器可能是最好的方法。
文件之间的管道
在不需要处理数据的情况下，我们可以将文件数据从一个文件传递到另一个文件。这通常称为管道 (大概是因为除了两端之外，我们看不到管道内的任何东西，当然，只要它是不透明的)。我们可以通过流 (stream) 来实现，首先，我们编写一个脚本实现一个文件到另一个文件的传输，以便我们可以测量内存使用情况：
结果并没有让人感到意外。该脚本比其复制的文本文件使用更多的内存来运行。这是因为脚本必须在内存中读取整个文件直到将其写入另外一个文件。对于小的文件而言，这种操作是 ok 的。但是将其用于大文件时，就不是那么回事了。
让我们尝试从一个文件流式传输 (或管道传输) 到另一个文件：
这段代码有点奇怪。我们打开两个文件的句柄，第一个处于读取模式，第二个处于写入模式。然后，我们从第一个复制到第二个。我们通过再次关闭两个文件来完成。当你知道内存使用为 393 kb 时，可能会感到惊讶。这个数字看起来很熟悉，这不就是利用生成器保存逐行读取内容时所使用的内存吗。这是因为fgets的第二个参数定义了每行要读取的字节数 (默认为-1或到达新行之前的长度)。stream_copy_to_stream 的第三个参数是相同的（默认值完全相同）。stream_copy_to_stream 一次从一个流读取一行，并将其写入另一流。由于我们不需要处理该值，因此它会跳过生成器产生值的部分
单单传输文字还不够实用，所以考虑下其他例子。假设我们想从 cdn 输出图像，可以用以下代码来描述
想象一下应用程度执行到该步骤。这次我们不是要从本地文件系统中获取图像，而是从 cdn 获取。我们用 file_get_contents 代替更优雅的处理方式 (例如 guzzle)，它们的实际效果是一样的。
内存使用情况为 581kb，现在，我们如何尝试进行流传输呢？
内存使用比刚才略少 (400 kb)，但是结果是相同的。如果我们不需要内存信息，也可以打印至标准输出。php 提供了一种简单的方法来执行此操作：
其他流
还存在一些流可以通过管道来读写。
- php://stdin只读
- php://stderr只写，与php://stdout相似
- php://input只读，使我们可以访问原始请求内容
- php://output只写，可让我们写入输出缓冲区
- php://memory与php://temp(可读写) 是临时存储数据的地方。区别在于数据足够大时php:/// temp就会将数据存储在文件系统中，而php:/// memory将继续存储在内存中直到耗尽。
过滤器
我们可以对流使用另一个技巧，称为过滤器。它介于两者之间，对数据进行了适当的控制使其不暴露给外接。假设我们要压缩shakespeare.txt文件。我们可以使用 zip 扩展
这段代码虽然整洁，但是总共使用了大概 10.75 mb 的内存。我们可以使用过滤器来进行优化
在这里，我们可以看到php:///filter/zlib.deflate过滤器，该过滤器读取和压缩资源的内容。然后我们可以将该压缩数据通过管道传输到另一个文件中。这仅使用了 896kb 内存。
虽然格式不同，或者说使用 zip 压缩文件有其他诸多好处。但是，你不得不考虑：如果选择其他格式你可以节省 12 倍的内存，你会不会心动？
要对数据进行解压，只需要通过另外一个 zlib 过滤器:
自定义流
fopen和file_get_contents具有它们自己的默认选项集，但是它们是完全可定制的。要定义它们，我们需要创建一个新的流上下文
本例中，我们尝试发送一个 post 请求给 api。api 端点是安全的，不过我们仍然使用了 http 上下文属性（可用于 http 或者 https)。我们设置了一些头部，并打开了 api 的文件句柄。我们可以将句柄以只读方式打开，上下文负责编写。
创建自定义协议和过滤器
在总结之前，我们先谈谈创建自定义协议。
我们并不打算实现其中一个，因为我认为它值得拥有自己的教程。有很多工作要做。但是一旦完成工作，我们就可以很容易地注册流包装器：
同样，也可以创建自定义流过滤器。
可被轻松注册
highlight-names 需要与新过滤器类的 filtername 属性匹配。还可以在 php:///filter/highligh-names/resource=story.txt 字符串中使用自定义过滤器。定义过滤器比定义协议要容易得多。原因之一是协议需要处理目录操作，而过滤器仅需要处理每个数据块。
如果您愿意，我强烈建议您尝试创建自定义协议和过滤器。如果您可以将过滤器应用于 stream_copy_to_stream 操作，则即使处理令人讨厌的大文件，您的应用程序也将几乎不使用任何内存。想象一下编写调整大小图像过滤器或加密应用程序过滤器。
如果你愿意，我强烈建议你尝试创建自定义协议和过滤器。如果你可以将过滤器应用于 stream_copy_to_stream 操作，即使处理烦人的大文件，你的应用程序也几乎不使用任何内存。想象下编写 resize-image 过滤器和 encrypt-for-application 过滤器吧。
总结
虽然这不是我们经常遇到的问题，但是在处理大文件时的确很容易搞砸。在异步应用中，如果我们不注意内存的使用情况，很容易导致服务器的崩溃。
本教程希望能带给你一些新的想法（或者更新你的对这方面的固有记忆），以便你能够更多的考虑如何有效地读取和写入大文件。当我们开始熟悉和使用流和生成器并停止使用诸如 file_get_contents 这样的函数时，这方面的错误将全部从应用程序中消失，这不失为一件好事。
以上就是详解php如何读取大文件的详细内容，更多关于php如何读取大文件的资料请关注www.887551.com其它相关文章！
