重新访问HHVM

Just over two years have passed since the last post about HHVM by Matt Turland. What changed in that time? Did anything? Let's see just how successful PHP's quest for performance was.

自从Matt Turland 发表关于HHVM的最新文章以来，已经过去了两年多。 那时发生了什么变化？ 有事吗 让我们看看PHP追求性能的成功程度。

HHVM –那又是什么？ (HHVM – what was that again?)

Like Matt says in his article, HHVM is

就像Matt在他的文章中说的那样，HHVM是

[…] a Just-In-Time (or JIT) compiler. Rather than going through the C++ compilation phase to translate PHP to native code, hhvm translates PHP to an intermediary bytecode language called HipHop Byte Code (HHBC) that can be translated to native code in real time when it’s needed […]

[…]即时(或JIT)编译器。 hhvm无需经过C ++编译阶段将PHP转换为本地代码，而是将PHP转换为称为HipHop字节码(HHBC)的中间字节码语言，该语言可以在需要时实时转换为本地代码[…]

In other words, your PHP code is executed in near-native (near C++) speed on-the-fly. HipHop started out as a compiler whose binaries, when produced, you would deploy – much like Zend Guard or IonCube. HHVM is different in that it's real-time. There's still no manual compilation process per se, and the development cycle remains swift.

换句话说，您PHP代码以即时(接近C ++)的速度执行。 HipHop最初是一个编译器，在生成二进制文件时，您便会进行部署–非常类似于Zend Guard或IonCube。 HHVM的不同之处在于它是实时的。 本身还没有手动编译过程，并且开发周期仍然很快。

So what is it? A server? How does it actually execute my PHP? Does it work with Apache/Nginx/IIS? Does it replace them? Can it even compete with them? How do you use it? Do you install it as an extension? These types of questions can cause some proper headaches when it all sounds so abstract, I know. Let's try and demystify it a bit further.

那是什么 服务器？ 它实际上如何执行我PHP？ 它可以与Apache / Nginx / IIS一起使用吗？ 它会取代它们吗？ 它甚至可以与他们竞争吗？ 你如何使用它？ 您是否将其安装为扩展程序？ 我知道，当这些听起来听起来很抽象时，这些类型的问题可能会引起一些适当的头痛。 让我们尝试进一步揭开它的神秘面纱。

HHVM实际上如何工作？ (How does HHVM actually work?)

HHVM, when given a PHP file, compiles said file to HHVM bytecode. It literally rewrites it to a lower language, which is quicker to further rewrite into native code – something a CPU can interpret directly. As you might imagine, doing this over and over again every time a file is accessed would be overkill and would actually make the whole application slower. This is why HHVM uses an SQLite database on disk to remember the compiled files.

当给定一个PHP文件时，HHVM将所述文件编译为HHVM字节码。 它实际上将其重写为较低的语言，这样可以更快地进一步将其重写为本机代码-CPU可以直接解释的内容。 就像您想象的那样，每次访问文件时都要一遍又一遍地执行此操作会过大，实际上会使整个应用程序变慢。 这就是HHVM在磁盘上使用SQLite数据库记住已编译文件的原因。

If you're familiar with APC, this is more or less the same thing. When HHVM first starts up, the cache is empty, so everything seems slower in the first few requests. In time, however, things warm up and the app speeds up. There's one crucial difference between APC's way of working and HHVM's. APC stores the compiled code in memory, while HHVM does this on disk (the SQLite DB). This means the compiled results survive restarts – when you reboot your server, the cached compiled files are still there, thus not needing the warm-up period. While this is somewhat slower than reading from memory (every disk will always be slower than RAM), it also means you can further improve your app's speed by hosting it on an SSD server.

如果您熟悉APC，那么或多或少是同一件事。 当HHVM第一次启动时，缓存为空，因此在前几个请求中一切似乎都变慢了。 但是，随着时间的流逝，事情逐渐升温，应用程序加速。 APC的工作方式和HHVM之间存在一个关键的区别。 APC将编译后的代码存储在内存中，而HHVM在磁盘(SQLite DB)上进行存储。 这意味着编译后的结果可以在重新启动后保留下来 –当您重新启动服务器时，缓存的编译文件仍然存在，因此不需要预热期。 尽管这比从内存中读取要慢一些(每个磁盘总是比RAM慢)，但这也意味着您可以通过将应用程序托管在SSD服务器上来进一步提高应用程序的速度。

A further boost in performance is achieved through JIT. This is an option, but it's on by default for server and daemon mode. What JIT does is further compile the HHVM bytecode into native code as it learns about the most frequently used files. Again, this brings along a certain warmup period, but once the ball is rolling there's quite a bit of inertia to compete with.

通过JIT可以进一步提高性能。 这是一个选项，但on服务器和守护程序模式下默认情况下on 。 JIT的工作是在了解最常用文件的同时将HHVM字节码进一步编译为本地代码。 同样，这带来了一定的热身期，但是一旦球滚动，就会有相当大的惯性要与之竞争。

HHVM与流行服务器的兼容性 (HHVM compatibility with popular servers)

HHVM is installed via a package manager or built from source. It is, in essence, just a program you need to install like any other – currently available on Ubuntu, Debian, CentOS and Fedora. Initially, HHVM replaced the entire PHP+server stack – it had its own server. It still does, in fact. HHVM's server is not unlike something you might see when working with NodeJS – you run it from the command line, tell it to accept requests on a given port, and everything else you usually tell Apache, Nginx, IIS, Tomcat, Lighttpd or any other server. There is a plethora of configuration options for your perusal (https://github.com/facebook/hhvm/wiki/runtime-options) and most of them are rather self explanatory and straightforward. In fact, if you follow HHVM's excellent WordPress tutorial from a while back, you'll see how simple a basic server configuration is.

HHVM通过软件包管理器安装或从源代码构建。 从本质上讲，它只是您需要像其他任何一样安装的程序-当前可在Ubuntu，Debian，CentOS和Fedora上使用。 最初，HHVM替换了整个PHP +服务器堆栈-它拥有自己的服务器。 实际上，它仍然如此。 HHVM的服务器与使用NodeJS时可能会看到的东西没有什么不同–从命令行运行它，告诉它接受给定端口上的请求，以及通常告诉Apache，Nginx，IIS，Tomcat，Lighttpd或其他任何其他信息服务器。 您可以仔细阅读许多配置选项( https://github.com/facebook/hhvm/wiki/runtime-options )，其中大多数都是自我解释和直接的。 实际上，如果您从前跟随HHVM 出色的WordPress教程 ，就会发现基本服务器配置有多么简单。

However, on December 17th, 2013 the HHVM team announced FastCGI support. FastCGI is a protocol for a server's communication with the application server. This allows for a separation of responsibilities – HHVM runs PHP code, which is what it was meant for, and your server handles all the HTTP aspects, forwarding PHP processing to HHVM. While the original HHVM server isn't bad, it's good to know HHVM can now be used in tandem with your usual server of choice. It's important to note it currently only supports communication through TCP – once Unix socket support is added, the network bottleneck that's currently plaguing it will disappear, and HHVM's performance will improve even further.

但是，在2013年12月17日，HHVM团队宣布了对 FastCGI的支持。 FastCGI是服务器与应用程序服务器通信的协议。 这实现了职责分离– HHVM运行PHP代码(这是要这样做的意思)，并且您的服务器处理所有HTTP方面，并将PHP处理转发到HHVM。 虽然原始的HHVM服务器还不错，但是很高兴知道HHVM现在可以与您选择的普通服务器一起使用。 重要的是要注意，它目前仅支持通过TCP进行通信-添加Unix套接字支持后，当前困扰它的网络瓶颈将消失，并且HHVM的性能将进一步提高。

性能考量 (Performance considerations)

When considering speed, the actual performance of HHVM FastCGI vs HHVM alone depends on the number of static resources. While pure HHVM will almost always be faster in execution of PHP scripts, when it comes to the number static resources, a server optimized for such a task just might do a better job – as confirmed by HHVM's tweet:

考虑速度时，HHVM FastCGI与HHVM的实际性能仅取决于静态资源的数量。 尽管纯HHVM几乎总是可以更快地执行PHP脚本，但是当涉及到静态资源数量时，针对此类任务进行了优化的服务器可能会做得更好-正如HHVM的推文所证实的那样：

@matthieunapoli Depending on the number of static resources? Possibly. Nginx will certainly beat us for non-php content.

@matthieunapoli取决于静态资源的数量？ 可能吧 Nginx肯定会在非PHP内容上击败我们。

— HipHopVM (@HipHopVM) December 18, 2013

— HipHopVM(@HipHopVM) 2013年12月18日

Naturally, this is void if you use a third party CDN for static resources, so it's up to you. The good news is – both approaches are simple to implement, and doing some a/b testing on performance and serving shouldn't be too hard should you decide to find out which approach is better for your app.

自然，如果您将第三方CDN用于静态资源，则这是无效的，因此由您自己决定。 好消息是–两种方法都易于实现，并且如果您决定找出哪种方法更适合您的应用程序，则对性能和服务进行一些a / b测试并不难。

Ways to improve general speed altogether are: – deploying on SSD for faster cache reads/writes – pre-analyzing – authoritative cache – follow these micro-optimizations

总体上可以提高总体速度的方法是：–在SSD上进行部署以实现更快的缓存读/写–预分析–权威缓存–遵循这些微优化

预分析 (Pre-analyzing)

Pre-analyzing is a concept well covered on their official blog, but I'll try and sum it up here. When HHVM is compiled/installed, it has a binary called hhvm-analyze (or hphp if you built it from source). This binary is what's run when doing optimizations in runtime – it's executed before the server spins up to serve the request results. With HHVM, you have the option of running analyze before the app is live – you can pass a list of files to it which you want included in the cache, and pre-cache them. This has the added benefit of avoiding the warmup period and does some more detailed, slower optimizations because no one is waiting for it but you. The assumption is you ran it to pre-optimize, so it takes some extra time to do it super-right.

预分析是他们的官方博客中很好介绍的概念，但我将在此处尝试进行总结。 编译/安装HHVM时，它具有一个名为hhvm-analyze的二进制文件(如果是从源代码构建的， hphp )。 该二进制文件是在运行时进行优化时运行的二进制文件-在服务器启动以提供请求结果之前执行。 使用HHVM，您可以选择在应用程序上线之前运行分析–您可以将要包含在缓存中的文件列表传递给它，并对其进行预缓存。 这具有避免预热期的额外好处， 并且可以进行更详细，更慢的优化，因为没有人在等待它，而是您自己。 假设您运行它来进行预优化，因此花一些额外的时间来做得非常正确。

权威缓存 (Authoritative Cache)

When you set the cache as authoritative in the web server or daemon configuration like so…

当您在Web服务器或守护程序配置中将缓存设置为权威时，如下所示：

Repo {
  Authoritative = true
}

…HHVM assumes the compiled code cache is the only source of code. When this is false (default), HHVM checks if a file was changed, and if it was, it needs to recompile. This means extra disk work (even if no recompile is needed, it still had to read the file header to see if it was changed at all), which means additional performance hits. With Authoritative cache set to true, HHVM never even looks for the original file. If it changed, you manually need to rebuild your cache. If you updated HHVM to a newer version, the cache is invalidated, and you need to rebuild the cache manually again. Due to these extra steps, the authoritative flag is usually only used in production where there is little to no chance of individual PHP files changing on a regular basis.

…HHVM假定编译后的代码缓存是唯一的代码源。 如果为false(默认)，则HHVM将检查文件是否已更改，如果已更改，则需要重新编译。 这意味着需要更多的磁盘工作(即使不需要重新编译，它仍然必须读取文件头以查看是否已更改)，这意味着会带来额外的性能损失。 将权威性缓存设置为true时，HHVM甚至不会寻找原始文件。 如果更改，则您需要手动重建缓存。 如果将HHVM更新为较新的版本，则缓存将失效，并且需要再次手动重建缓存。 由于采取了这些额外的步骤，因此权威标记通常仅用于生产中，在这些生产中，几乎没有或根本没有定期更改单个PHP文件的机会。

结论 (Conclusion)

HHVM has evolved rapidly and significantly over the past 2 years when we last covered it. The performance improvements are measured in factors, the usability has increased impressively, the installation learning curve has all but disappeared and recent tests show it even supports most of today's popular frameworks and open source PHP apps, from PhpMyAdmin to Symfony2 and beyond.

HHVM在我们上一次介绍它的过去两年中已Swift而显着发展。 性能的提高是通过因素来衡量的，可用性得到了惊人的提高，安装学习曲线几乎消失了， 最近的测试表明它甚至支持当今大多数流行的框架和开源PHP应用程序，从PhpMyAdmin到Symfony2等。

With this level of maturity, SitePoint will be covering HHVM to a much greater extent. Follow the HHVM tag for further articles and tutorials, including but not limited to demo apps, custom framework installations, live deployments, and more.

在这种成熟度的前提下，SitePoint将在更大程度上覆盖HHVM。 请遵循HHVM标签以获取更多文章和教程，包括但不限于演示应用程序，自定义框架安装，实时部署等。

If you'd like a special HHVM use case covered, or would like to talk about your own experiences with it, please do get in touch with me via +BrunoSkvorc and we'll talk more! Leave your comments and thoughts below!

如果您想了解特殊的HHVM用例，或者想谈谈自己的使用经验，请通过+ BrunoSkvorc与我联系 ，我们将继续讨论！ 在下面留下您的评论和想法！

翻译自: https://www.sitepoint.com/hhvm-revisited/