Refactored PHP engine makes Wordpress 20% faster

http://news.php.net/php.internals/73888

by mrsaint • 12 years ago

293 139 12 years ago

news.php.net

trebor4• 12 years ago

Good news, any idea which version this will be included in? I know PHP 5.6 is already in beta, so I'd assume this'll be PHP 5.7, but this is really good news. We have some sites that are just begging for an actual 10-30% increase in speed.

mrsaint2• 12 years ago

It's PHP 5.7.0-dev right now. You can download and compile the development branch yourself: https://wiki.php.net/phpng

kolev11• 12 years ago

Great. Any ETA on phpng stable release?

LawnGnome• 12 years ago

I suspect this'll be the basis of a new major version, based on early discussions. It probably won't be a 5.x release.

BorisMelnik• 12 years ago

With claims / benchmarks like this I am sure you are right, particularly for a product that ships as much as WordPress does.

Wordpress 3.6 – 20.0% gain (253 vs 211 req/sec)

I have a few enterprise sites that I am constantly looking for ways to optimize for speed: DNS, CDNs etc. This looks like an easy win.

frik2• 12 years ago

There are already PHP 6 books out there from 2009 (planned v6 renamed to 5.3): https://www.google.com/search?q=php+6&tbm=bks

They could name it PHP 7 to avoid further confusion.

fastest963• 12 years ago

Can't wait to play around with this once they support a few more extensions!

neals• 12 years ago

I love how, through all the hate and bandwagoning, some people don't get discouraged and actually do something to improve the product.

We still do new projects in PHP and we couldn't be happier.

adamors4• 12 years ago

We still do new projects in PHP and we couldn't be happier.

I concur, especially when frameworks like Symfony exist. Reading all this smack talk about PHP on HN is so alien considering how thriving the PHP community actually is.

awestroke• 12 years ago

Nobody mentions how much or little the PHP community thrives. People point out how bad PHP compares against other languages. The fact that you enjoy using PHP and that you can create great products with it does not imply that it has no flaws.

Many have been where you are now, and then moved on to other languages to never ever look back. From what I've seen, the reverse is much less common.

Kiro• 12 years ago

What's so good about Symfony compared to other PHP frameworks?

muppetman3• 12 years ago

Dmitry is the man who originally wrote eaccelerator, Zend caught wind of him and hired him! Then he worked on opcache and has done some amazing things in getting the Zend Engine and PHP itself flying. He's a very smart cookie.

mtdewcmu2• 12 years ago

His good sense is obvious by the way he stopped going down the JIT route and zeroed in on the bigger performance drain, memory allocation, instead. The smart programmer knows how to write a JIT; the wise programmer knows how to not write a JIT.

pan69• 12 years ago

About a year ago I was ready to jump ship on PHP. Then someone introduced me to Composer, Symfony 2 and Doctrine 2. I fell in love with PHP again, not because of the language but because of the tools. Its now clear to me that the language doesn't really matter that much, it's the tooling around the language that makes the difference.

alttab• 12 years ago

Agreed. One thing to consider is how the features and performance of a language shape the tools. The tools can be great, but to some degree you're riding a long distance skateboard with a generator on the back...

Edit: This comment comes off as me making fun of PHP, when I simply meant to say that tools can make something effective but what underlies an effective work environment can still be crap. I don't think PHP is "crap," but at a certain level of complexity its easier to get the "average developer" to be effective using another set of tools.

devNoise2• 12 years ago

This sounds like a nice improvement to PHP performance. Are there any parts of the language that will have to change for this enhancement? I expect that that changes will be minimal, if any are needed.

rossriley• 12 years ago

From what I can see there shouldn't be any userland breaks unless it's very obscure.

In the internals all of the zend_hash apis have been updated so it may have an effect on some extensions, though the core extensions can all be updated.

devNoise2• 12 years ago

I think you're right. The line that made me think that something might change is:

"we changed the basement trying to keep most of the building unchanged."

The "most" part made me wonder what obscure part of userland it would be.

frik2• 12 years ago

Great news. HHVM and now PHP 5.7, both with JIT - the future of PHP looks bright.

dparoski• 12 years ago

To my knowledge a JIT compiler is not being added to PHP 5.7. Can you clarify your comment or provide a link to the source where you heard this?

captain_mars2• 12 years ago

I'm not the person you replied to, but I got the same impression.

The linked email in turn links to the PHP NG page (https://wiki.php.net/phpng) on which the version number mentioned is 5.7.0-dev

smsm425• 12 years ago

While it indeed is marked as 5.7-dev, which is because it is forked from master branch which is always marked next minor version from current release one (5.6), it is very likely that it would be next major version. The changes in this refactoring are extensive and deep, and more are probably to follow. Pretty much every extension will need to be ported. This is what major versions are for.

nijiko• 12 years ago

The parser needs to be rewritten really.

nly2• 12 years ago

Why do you say that? The parser looks no more or less horrible than the rest of the code base.

cwt137• 12 years ago

I thought they switched to Lemon, or am I wrong?

nodesocket• 12 years ago

Love the work, but honestly by the time PHP 5.7 is ready for mainstream (with extension support mysqli, memcache, mongo), Facebook HHVM will be the defacto standard. FB has a huge head start and can throw nearly unlimited money and engineering hours at the problem. Seems like a losing battle, but perhaps I am wrong.

batmansbelt• 12 years ago

No one ever says that the different python implementations are fighting a losing battle. People generally seem to say that having multiple implementations is good for the language.

pjmlp• 12 years ago

When there is only one, people tend to confuse implementation with language.

Additionally there is also a way to sort out possible bugs in language specification, as differences across implementations are sorted out.

NameNickHN• 12 years ago

PHP's success is the result of PHP being available at even the tiniest webhost. I don't see that happen for FaceBook HHVM, though. FaceBook HHVM performance results will spur on Zend's efforts in making the PHP engine faster, though.

beaumartinez• 12 years ago

It's Facebook, not FaceBook. Spelling it like that makes reading it jarring.

whatts• 12 years ago

90% of people write DropBox, as well ;)

smsm425• 12 years ago

Not likely. HHVM is Facebook's private implementation and it would require a lot of time for it to be anywhere near wide acceptance, let alone "de facto standard".

>> an throw nearly unlimited money and engineering hours at the problem

They can, but they won't. Because it already works for them, so the amount of resources they are willing to commit to something that no longer gives any upside to them will be limited.

>> Seems like a losing battle, but perhaps I am wrong.

There's no battle and this is not a zero sum game. HHVM will have its market and standard PHP engine will have its market.

ohwp• 12 years ago

Refactoring Wordpress will make it even faster. Look at the difference between Drupal and Wordpress. It's amazing Wordpress is still used for big sites while a ton of recourses could be saved.

But great work on the PHP engine!

nacs2• 12 years ago

Agreed. I ran a benchmark against CodeIgniter on a test box recently and was suprised that a single query app performance went from around ~20k req/s with raw PHP (no framework) to around ~3k req/s with CI and thought that was bad for a framework. I didn't realize Wordpress performance was so much worse especially given its popularity.

Most Wordpress sites use a caching plugin like WP Super Cache or Varnish-type setup if they get decent traffic though.

raverbashing• 12 years ago

Depends on the WP plugins, I suppose (and Indexes created, and MySQL tuning, etc)

jafaku7• 12 years ago

CI is a badly designed and outdated framework. For real speed you should use something more professional like Symfony2.

Joeri• 12 years ago

You should check out the framework benchmarks. Raw php is competitive with other web dev platforms performance-wise, but the major php frameworks slow it down by an order of magnitude. I blame the PSR / on-demand class loading java-style architecture which was adopted by all the frameworks. They've copied a java architecture into a platform that doesn't have java's performance characteristics.

In my own benchmarks i've noticed all that class loading and instantiation slows things way down, even with an opcache. I find that a namespaced procedural / functional architecture performs much better, but no PHP framework works that way.

http://www.techempower.com/benchmarks/

woah2• 12 years ago

The speed of wordpress does not matter in the slightest.

erming• 12 years ago

I don't think it's fair to say that Drupal is faster than Wordpress by just looking at the req/sec.

According to https://wiki.php.net/phpng, they benchmarked against Wordpress 3.6 (the current version is 3.9). I couldn't find anything about the Drupal benchmark, but it could be a simple "Hello world" for all we know.

will_work4tears2• 12 years ago

Drupal is pretty slow if you disable the default caching, and sometimes even with the caching (depends on modules loaded) - part of the problem is Drupal's table bloat. I swear a naked install has 100+ tables (and with a few plugins and a few fields enabled, has 250+ tables - so you end up with tens and hundreds of queries per page load).

brokentone• 12 years ago

Performance hasn't been a priority for WP in the last several releases. WP 3.3 gave a very nice bump, but no much since then.

rabino• 12 years ago

Not sure what this has to do with the topic at hand, but since you derailed the conversation let me tell you that I run several WordPress sites with a few dozen million visits a month without much trouble.

jakejake• 12 years ago

Agreed - fantastic news for PHP in general.

As far as Wordpress, in my experience the number of db queries is really a bigger problem than the PHP processing. A factory-default install with no plugins runs 30 queries on every home page load. With a fancy theme and a few plugins it can be over 100 queries per page! A caching plugin is pretty much essential for any Wordpress site.

woah2• 12 years ago

Why does it matter? Visitors should never hit WP anyway if you are smart. Set up caching.

andy_adams• 12 years ago

It makes a big difference if your site isn't just for displaying static HTML content - for example, a WordPress-powered community where users log in to your site.

lucb1e6• 12 years ago

Wordpress 3.6 – 20.0% gain (253 vs 211 req/sec)

How do you generate 211 pages per second on Wordpress to begin with? My server does page generation for my own custom-built blog in ~15ms, but takes a whopping three seconds for a single Wordpress page. I know it's somewhat offtopic and it's about the relative results, but what hardware is this?

muppetman3• 12 years ago

Are you running an opcache like Zend Opcache, APC, XCache etc? 3 seconds is amazingly slow.

lucb1e6• 12 years ago

I meant raw page generation times. With caching it was much quicker of course. I assume the PHP benchmarks are also non-cached, else you're just benchmarking the caching method.

pjbrunet• 12 years ago

Could just be your hosting. For example, with Media Temple (years ago) I found it often took 7+ seconds just to redirect www to non-www, up to 12 seconds. Pingdom is a good tool to see where you're getting stuck http://tools.pingdom.com/fpt/ Another common problem, your MySQL database could be overloaded (especially with shared hosting) and more caching won't necessarily solve the problem.

lucb1e6• 12 years ago

If it's my hosting (which was an eee pc btw) then why does my self-written blog load in 15ms? But yeah on shared hosting with more cpu power, wordpress performed much better.

dangrossman• 12 years ago

My Linode VPS spits out WordPress pages in 33.811ms (via ApacheBench, concurrency=10 for a couple hundred requests). I don't use any kind of content/page cache. There's no reason WordPress would be 200 times slower than your custom blog -- WordPress isn't some kind of complex software. It's a handful of very small PHP classes that choose a theme file based on the URL, include it, run a database query to select some posts, wrap the result rows in objects, and pass them to the theme to spit out. I've had hundreds of concurrent visitors on my blog without registering any load. If your site is taking 3 seconds to return a page, there's something wrong and it's not the choice of blog platform.

lucb1e6• 12 years ago

I meant a clean wordpress install. No themes, no plugins, just a basic install. Three seconds. My own blog does about 3 mysql queries and manages that in 8ms at best (usually 22ms at worst; typical seems to be around 15ms). The most limiting factor for Wordpress was cpu speed.

driverdan• 12 years ago

This is not a WP issue. It's most likely a bad plugin or theme. You can use something like P3 (Plugin Performance Profiler) to see where the issue is. It could also be a misconfigured system. WP requests should never take 3 sec.

thefreeman2• 12 years ago

Judging from your other responses, it sounds like you are running it on something like this: http://www.ebay.com/itm/like/181342056669?lpid=82

You really can't judge it based on that hardware. Of course it runs slower then your "custom" blog... it is probably orders of magnitude more complex.

Also you haven't mentioned what platform you are using. I don't know if those netbooks run linux or windows, but if you are trying to host this on a desktop version of windows with something like Xampp it is really incomparable as well.

munimkazia• 12 years ago

It is good to hear that they even managed to refactor their code, even if you don't look at the performance benefits. Now, I hope that their next major upgrade will be a complete API overhaul, though it means making the existing thousands of themes and plugins incompatible.

Refactored PHP engine makes Wordpress 20% faster

Related Stories