DEV Community: James Sansbury

Xdebug 3 is here: Massive performance increase, simpler config, and PHP 8 support

James Sansbury — Wed, 25 Nov 2020 16:43:24 +0000

If you're using Xdebug for PHP debugging, there's a new version that just released today: Xdebug 3. Check out the announcement! Promising massive performance boosts, a simpler configuration paradigm, and support for the upcoming (tomorrow!) PHP 8.0 release.

// Detect dark theme var iframe = document.getElementById('tweet-1331621484607967232-603'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1331621484607967232&theme=dark" }

Upgrading

To read about how to upgrade from Xdebug 2 to Xdebug 3, read the upgrade guide. Some highlights below:

Performance

The benchmarks of Xdebug 3 have shown that Xdebug 3 is 34% faster for step debugging, and 25% faster when in develop mode. In addition, if you have the Xdebug extension installed, but aren't actively using it (features are disabled), Xdebug 3 is over 99% faster than Xdebug 2.

Configuration highlights

One of the big shifts with Xdebug 3 is the introduction of the xdebug.mode ini setting. If you've ever struggled getting just the correct incantation or flavor of Xdebug ini settings to get debugging working, feast your eyes on this thing of beauty:

xdebug.mode=debug

That's it. No more deciphering if you need remote_enable on, profiler_enable on, or trying to remember what exactly remote_autostart does.

Multiple Xdebug modes

You can combine Xdebug modes together with a comma. These other modes for xdebug.mode are:

off Everything is—ahem—off. This means you can have the extension installed but disabled, and a negligible performance hit. ✨ I'm guessing you can't really combine this with the other modes? 🤷‍♂️
develop Turns on development aids. If you like stack traces or if var_dump() is your friend, you'll want this setting.
coverage If you're running code coverage reports with PHPUnit, turn this on.
debug Enables step debugging. 😋
gcstats Collect statistics about PHP's garbage collection mechanism. 🗑
profile Use this to analyze performance with tools like KCacheGrind.
trace Enables the Function Trace feature, which allows you record every function call, including arguments, variable assignment, and return value that is made during a request to a file.

Time will tell, but I'm guessing xdebug.mode on most of my projects will be:

xdebug.mode=develop,debug,coverage

Starting a step debug session

Remember the XDEBUG_CONFIG="idekey=wtf" days? No longer. Now it's simplified to an XDEBUG_SESSION environment variable to turn on step debugging. Set this environment variable to the key you'd like for that step debug session.

XDEBUG_SESSION=wtf

Step debugging? Port 9003

⚠️ Heads up: the default step debugging port has changed from port 9000 to port 9003.

Win, win, win: performance, simpler config, PHP 8 support

What's not to love about this release? I'm excited to be able to have the extension installed and available without a huge performance hit. I'm looking forward to simpler configuration. And tomorrow, PHP 8.0 will land, which is the first release to have JIT compiling.

What the dill with pecl: Is pear still around for PHP 8?

James Sansbury — Tue, 24 Nov 2020 14:57:26 +0000

It's a bit confusing determining whether pear/pecl are still around in PHP 8.0. There's been talk of removing it entirely from PHP for years (just do some searching and you'll see the various RFCs).

There’s a lot of confusing stuff out there. The official PHP Docker images currently do not have it installed for their 8.0-RC images, citing that pear has been removed in PHP 8.0. However PHP's documentation on Migrating from PHP 7.4.x to PHP 8.0.x doesn’t mention removal of it. In fact, it even mentions that the XML-RPC extension "has been moved to PECL."

So what gives?

It appears that the --with-pear option is still around for configuring PHP builds from source. When you use it, the build states:

configure: WARNING: The --with-pear option is deprecated

This is the same warning you'll see if you build PHP 7.4.

As far as I can tell, Pear and Pecl are here to stay in PHP 8.0. As such, I created a Pull Request on the official PHP Docker images to add the --with-pear option to the 8.0-RC builds.

⁉️ Those in the know: can you weigh in on this? Are pear and pecl still going to be the official way to install Pecl extensions in PHP 8.0.x? Or should we start transitioning to pickle?

PHP 8.0 is here! How to turn on JIT compiling

James Sansbury — Mon, 23 Nov 2020 20:30:25 +0000

As of Nov 26, 2020 PHP 8.0 will be “generally available.” (I learned today that that’s what the GA means on that page.)

Folks have been benchmarking and found that an upgrade to PHP 8.0 will likely mean a performance boost for your website. Faster loading pages is important both for SEO purposes, and of course for the actual users of your sites.

PHP 8.0 now ships with a JIT compiler that can increase that performance boost even further. JIT stands for “Just in time,” and means that PHP can compile its code directly into machine code (code that the CPU understands) without needing the help of an interpretation layer. For CPU-intensive tasks, having a JIT compiler in PHP boasts significant performance gains.

PHP developers everywhere are missing out on this:

If you’re interested in learning more about the new stuff in PHP 8.0, here’s a few articles to check out:

🔦 How to turn on JIT compiling

If you’ve been using PHP 7.x, you’re probably familiar with the OPcache extension. (And if you’re not, go make sure it’s turned on now. It’s a huge performance boost.)

For PHP 8.0, the JIT compiling is enabled via this same OPcache extension. So step one in getting JIT compiling turned on for your project is making sure the OPcache extension is installed and enabled.

The process for installing the OPcache extension will depend a lot on the platform you’re running PHP on. Check the docs for your flavor of Linux. If you’re using the official PHP Docker images, installing it is pretty easy:

$ docker-php-ext-install opcache

To check if you’ve got it installed, you can run php -i on the command-line to print out phpinfo().

$ php -i | grep 'opcache\.enable '
opcache.enable => On => On

🖊️ Tweak the Opcache settings to enable JIT compiling

Now that you have the Opcache extension installed, that doesn’t mean JIT is turned on. We’ve got to override a few default ini settings to actually enable JIT compiling. To do this, you can see if you can find the existing opcache.ini file. Here’s how I usually do that (again, with phpinfo()).

php -i | grep opcache\.ini
/usr/local/etc/php/conf.d/docker-php-ext-opcache.ini

As you can see, this is a Docker image I’m using, so any changes I make here are liable to get wiped out, but I’m okay with that for now. I’m just tinkering at this point. I’m going to edit that file and add the following settings:

# Turn on the OPcache for command-line PHP, like drush or 
# wp-cli, etc.
opcache.enable_cli=1

# The amount of shared memory to reserve for compiled JIT
# code. A zero value disables the JIT.
opcache.jit_buffer_size=50M

# JIT control options. Either accepts a string or a 4 digit 
# int for advanced controls. See 
# https://www.php.net/manual/en/opcache.configuration.php#ini.opcache.jit
opcache.jit=tracing

Note: if you wanted a more permanent solution for Docker, create your own ini file that gets copied or mounted into the $PHP_INI_DIR/conf.d/ directory in your container.

For more details on these settings, check out the OPcache Runtime Configuration or the PHP RFC: JIT. You read that right: three three-letter acronyms. 🤦‍♂️

You can double check that your settings worked by using php -i again:

$ php -i | grep -E '^opcache\.(enable_cli|jit|jit_buffer_size) '
opcache.enable_cli => On => On
opcache.jit => tracing => tracing
opcache.jit_buffer_size => 50M => 50M

That’s it! You’re now taking advantage of JIT compiling in PHP 8.0. (And if you’re using the Apache PHP module, don’t forget to apache2ctl graceful). Go forth and test. 🧪

"It worked on my local!" 😭

James Sansbury — Wed, 04 Nov 2020 22:12:40 +0000

If you’re in webdev and stuck with a single staging or testing server, my heart goes out to you. That probably means you and your team work real hard on designing and developing amazing things, and then at the end of the sprint when it’s all supposed to come together in a glorious, jaw-dropping demo, something goes 💥.

😭

Developers are confused, Project Managers are embarrassed, and Stakeholders are frustrated. Morale tanks like a swiss cheese submarine 🧀. The team is stuck with a few bad options: ship the broken thing and hope to have time to fix it later, scrub the launch and do it right, or pull an all-nighter to hotfix the release.

I don’t know about you, but I don’t like any of those options.

What caused the “boom”? Often the team will find it was something small, like a missing semicolon, or maybe as embarrassing as [cough, cough] misunderstanding entirely how a new feature was supposed to work.

But those things are actually symptoms of a deeper issue. Underneath the huge gaping crater of that failed demo is a pernicious anti-pattern in the entire agile webdev process: a single staging / testing server.

The bottleneck of a single staging server

Given the rise of tools like Docker and Kubernetes, the amount of time, money, and hair lost to the bottleneck of limited staging servers is truly a tragedy. Friends, how are we still in this place?! We don’t need to be stuck with just one or two servers to test on.

We talk all day about “Agile”, “Scrum”, or “Kanban”, but our process doesn’t actually work that way. We can’t see what is being worked on in an “agile” manner, and then guess what happens: 💩 meet fan.

To me, this bottleneck is the most frustrating anti-pattern of our day. The technology is there. And, there are tools that make use of it. (If you’re in the market, Tugboat is obviously the best option. 💅 )

Remove the bottleneck: ship every commit.

No matter where you host or what your budget is, there’s a solution to this problem. Stop being reactive and start being proactive with your QA and demos. Get some tooling in place to give you automated, fully working website previews for every pull request.

Test everything all the time, and demo anything any time. And if you're not sure how, reach out, I'm glad to help.