Running Drupal 8 on PHP 7
Running Drupal 8 on PHP 7
[Check out or free Installing Drupal 8 on PHP7 tutorial]
Drupal 8 was released with full PHP7 support:
But the fact that the Drupal 8 codebase is able to run on PHP7 does not mean that you can run PHP7 Drupal 8 deployments. Why? Because there is more than just "Drupal" to run a decently performing Drupal 8 based application.
There are at least 3 additional components that need full PHP7 support:
- In-memory caching (Wincache/APCu)
- Database PDO driver
- Key/Value store or NoSQL alternative for high performance caching
Depending on what your software stack is these might be ready or not yet.
Our stack of choice is Wincache + SQL Server + Couchbase. The reasons are varied, but these (at least the two last of them) are enterprise level products that outperform their competitors in many ways, will scale without issues and keep innovating at a faster peace than their competitors do.
For example, SQL Server 2016 with the improved in-memory tables feature is able to speed up database operations (including transactional ones, joins and other complex situations) up to x15 without changing a single line of code (you will need some extra RAM but with today's pricing that is not an issue).
Couchbase is x4.5 faster than MongoDB.
So how is each one of those components ready for PHP7 and Drupal 8?
- In-memory caching - Wincache: I have been working closely with the maintainer on the last releases, and both 184.108.40.206 (for PHP 7) and 220.127.116.11 (for PHP < 7) and these are both production ready. Special thanks to Drophone for his continued - and personal he is not getting paid to work on this - efforts on this PHP extension. We uncovered and (he) fixed some tough bugs that were affecting Drupal 8. The Drupal Wincache module has also been brought up to date, updated to Drupal 8 and made PHP 7 ready.
- Database PDO driver - MSSQL: The MS team is working intensively into making PHP 7 on SQL Server a reality, and providing Linux support. You can follow their work here . With the latest release (4.0.4) installing Drupal 8 using PHP 7 is now a reality. The Drupal SQL Server driver has been tested and updated to work with PHP 7 and the latest PDO driver from Microsoft. Bugs in PHP itself were fixed in order to make the MSSQL pdo driver work and the minimum required PHP7 version is 7.0.6
- Key/Value - NoSQL - Couchbase: Early work has been posted by the Couchbase team, but no official PHP binaries yet. We recommend to hold on before trying PHP7 with Couchbase until a more stable release is made and an official statement done regarding PHP7 support.
Overall, you can start deploying Drupal 8 on PHP7 for applications that will need not to rely on Couchbase. I am wondering if that will ever be needed, considering that with the new in-memory enhancements fo SQL Server 2016 cache backends can be tunned to work x15 times faster with just some more RAM.
I would like to give special thanks to Drophone and the MSSQL Server team for making this a reality.
What to expect from here on?
Now that there is full SQL Server and Wincache support for Drupal 8 since - more or less - day 1, our customers are asking for Azure Apps support. The latest Drupal SQL Server driver is 100% comptatible with Azure SQL V12. On the upcoming months, I will be releasing specific guides for deploying Drupal 8 (and probably 7) on Azure Apps.
Why using Azure Apps? There are lots of reasons and these are some:
- Host anything from brochureware (from €5/month) to sites with millions of hits with predictable performance (yes this is no crap shared cloud hosting)
- Infrastructure as code.
- Automatic deployment slots per branch.
There's much much more to azure apps, but you can see that this is just awesome devops from a reliable provider.
mikeytown2 replied on Permalink
What does 15x really mean? In-Memory sounds like MySQL's innodb_buffer_pool_size being set big enough with innodb_flush_log_at_trx_commit set to 0. MySQL 5.7 with some expensive off the shelf hardware can do over 1.5 million queries per second to the same table; this number is also kinda out there but at least it tells me some real numbers and explains how to replicate it http://dimitrik.free.fr/blog/archives/2015/10/mysql-performance-yes-we-c... (noted that this result is with the query cache disabled).
Due to all the performance improvements to MySQL we no longer need a key/value memcache like store, we just use the database; drupal.org also did the same https://twitter.com/mcarper/status/720063584185626624.
This post makes some bold claims; please back them up with some real world comparisons :)
root replied on Permalink
Writing a well documented - with references - article takes some time, which I unfrotunately am quite scarce of lately. But your concerns are valid, and I understand that a plain x15 improved performance statement is poor without context.
In-memory OLTP was introduced in SQL Server 2014, but had too many limitations to be used as a drop-in headache-less replacement for current database storage:
In SQL Server 2016 they made it faster, more robust and - most important - removed all those limitations.
This article claims a single server sustained throughput of 1.2 million batch requests per second (little shorter than what you posted for MySQL) with 4Kb per request, resulting in a total throughput of 4.8Gb per second.
But.... in-memory OLTP is not just about throughput... claims are that they bring x30 improved performance for transactional workloads wich is the actual intented performance gain of in-memory OTLP: making things fast - very fast - while still being ACID. Making things fast for read-only single tabled non relational scenarios is - sort of - "easy" , the challenge here is to bring this performance to complex relational data models in transactional scenarios.
I have attached to this article a white paper detailing the internals of the new in-memory OLTP in SQL Server 2016.
Unfortunately, SQL Server 2016 is still in RC3 and there is very little in the wild usage/benchmarks.
mikeytown2 replied on Permalink
Thanks for the links! In the December 2015 article the 1.2 million number comes with this condition "This workload is purely in-memory using SCHEMA_ONLY tables, which are not logged and not persisted to disk". The MySQL 1.5 million number is for a database that is on disk and logged (durable). For a durable table it seems like the MSSQL QPS number is closer to 250k; which is impressive, it's within an order of magnitude of MySQL.
PostgreSQL has caught up to MySQL as well, it seems to hit 1.6 million; not sure it its a single table or multiple tables (MySQL does 1.6 million when hitting multiple tables) - http://akorotkov.github.io/blog/2016/05/09/scalability-towards-millions-....
All 3 tests (MSSQL , MySQL, PostgreSQL) seem to use a 4 socket board (MySQL & PostgreSQL both72 cores total; MSSQL doesn't say) so I'd guess that the hardware is fairly even.
Add new comment