{"id":7684,"date":"2019-07-15T02:00:19","date_gmt":"2019-07-15T09:00:19","guid":{"rendered":"http:\/\/softwareengineeringdaily.com\/?p=7684"},"modified":"2021-10-07T07:36:48","modified_gmt":"2021-10-07T14:36:48","slug":"facebook-php-with-keith-adams","status":"publish","type":"post","link":"https:\/\/softwareengineeringdaily.com\/2019\/07\/15\/facebook-php-with-keith-adams\/","title":{"rendered":"Facebook PHP with Keith Adams"},"content":{"rendered":"

Facebook was built using PHP, a programming language that was used widely in the late 90s and early 2000s. PHP allows developers to get web applications built quickly and easily, although PHP has a reputation for being difficult to scale.\u00a0<\/span><\/p>\n

In the early days of Facebook, the company was scaling rapidly on every dimension.\u00a0<\/span><\/p>\n

New users were piling into Facebook. Existing users were increasing their interactions and developing new patterns of usage. The Facebook application was rolling out new features quickly, adding them into the Facebook PHP codebase.<\/span><\/p>\n

A common pattern for scaling a large software application is to use a microservices architecture, breaking up the monolithic application into small services which can scale independently. For many applications, this pattern works well. But for some applications, microservices makes less sense.<\/span><\/p>\n

Microsoft Excel is one example. In Excel, a user is making updates to a complex data model using formulas, functions, and other in-app tools that need to be fast, performant, and integrated. The user needs to have a sense that the Excel data model will update quickly in response to changes.\u00a0<\/span><\/p>\n

A software team working on a spreadsheet product such as Excel might prefer to keep all the application logic in a monolithic application.\u00a0<\/span><\/p>\n

A monolith can centralize logic and make it easier to reason about. A monolith can reduce the number of network hops, cutting down on distributed systems problems. Testing and deploying a monolithic application can be less complex than doing so in a distributed, microservices system.<\/span><\/p>\n

Facebook chose to scale its PHP monolith rather than breaking it up into distributed microservices. Scaling PHP allowed Facebook to continue moving fast without going through a painful refactoring that would have slowed down the entire company.\u00a0<\/span><\/p>\n

The first effort to scale PHP involved transpiling the entire PHP application into C++. This C++ version of Facebook ran faster and with a lower memory footprint. But C++ required ahead-of-time compilation: the PHP codebase had to be converted to C++ in one synchronous step.<\/span><\/p>\n

The Hip Hop Virtual Machine (HHVM) is a just-in-time compiler that serves as an execution engine for PHP as well as Hack, a language that Facebook created as a dialect of PHP.<\/p>\n

HHVM allows for dynamic execution of code that is written in PHP or Hack. The code is first transpiled into HHBC, a high-level bytecode format that serves as an intermediate language. This bytecode is dynamically executed by the HHVM. As a bytecode virtual machine, HHVM has similarities to V8, the JVM, or the CLR.<\/p>\n

Keith Adams was an engineer at Facebook for six years, where he helped develop infrastructure to scale PHP effectively. Keith is now the chief architect at Slack, which is also a scaled PHP application. Keith returns to Software Engineering Daily to discuss why and how Facebook scaled PHP.<\/span><\/p>\n

ANNOUNCEMENTS<\/span><\/h2>\n