Decaflon

It's kind of funny, actually. The reason that PHP sites in general are slow, is because the technology is fast. Let me explain.

When PHP was first developed, one of the main driving points for people switching from ASP was speed. PHP was benchmarked, optimized, and tested like no other. As a result, it's one of the leas resource intensive technologies on the web. However, that resulted in people being happy with the other parts of the serving chain -- like Apache. Apache & friends are slow behemoths that don't really cater for super-fast processing, but rather focus on features galore.

Newer technologies like J2EE, Ruby, .NET, etc are a lot more resource intensive. As a result, running these on Apache/CGI/etc is dead slow. It's painful. Pain forced innovation, and as such technologies like FastCGI, lighttpd, mongrel, etc have come into the main stream.

Also realize because these technologies are more resource intensive, programmers are more often focused on caching, which adds IMMENSE speed to applications. A cached site can easily perform 1000 faster (at minimum, and no I'm not joking). A lot of PHP programmers don't focus on caching since execution of scripts is fairly cheap in relation.

Wow Kyle this is fascinating. I always thought that PHP was the weak link in the chain. Back in the semi old days I remember someone telling me that Apache was efficient because you could activate and deactivate modules to improve performance.

Thanks Kyle I think I get it now!

PHP isn't slow. The sites you mention are. Compiled CGI apps can be faster, but aren't always. I run dozens of php sites.

There's really way too many variables to just guess at, but I'll guess anyway. Facebook and digg are immensely popular, but not huge dollar investments (quite yet,) compared with some other equally popular sites. They don't have the bandwidth/resources to pump out their pages as fast as some people might like.

I actually haven't noticed digg being slow, but I only go there about once a week.

I don't agree with Michael. PHP is not slow at all. It's how you write the code and the way web servers handle and process that code. Recently I had written an application [company Internal] to select couple of thousands of records from few million records, and I found PHP to be very slow in doing that. Later, a DBA looked at the queries I was using, changed them and I couldn't believe it... right from ~35+ seconds to less than 4 seconds to do the same task.. I think the main area of concern is the way code is written.

PHP is generally not slow. However like any language, people need to know how to use the language properly. I will often see unoptimized code that depresses me to see. I'm no optimization expert by any means, but some of these things you see are a result of lazy programmers.

Now, PHP does have it's slow features. For example, writing a script that uses inheritance for a few levels of decent size c lasses can be slow, but then that can be expected.

There is also the factor of the server, and any other technology PHP may be working with. A chain is only as weak as its weakest link. If a site is getting thousands of hits per day, and the server can't handle it, then you problem lies there.

Ya, it's really not PHP that's slow. It's probably a factor of programming skill, user base size and lack of sufficient hardware. As far as I know, with proper code caching PHP is one of (if not) the fastest web-oriented scripting languages. Sure, you could write a C app... but man.

Michael, you are right that programming languages are getting slower and slower. On the flip side, it's becoming easier and easier to write great applications. Imagine writing a CMS in assembly (and having to build in your own http server)!

I'm afraid I have to disagree with people that say the language is not the slow part. As languages go, PHP is terrible. Check out some direct algorithm comparisons and you'll see that PHP's runtime is only just kept off the bottom (in almost all the benchmarks) by things like Ruby, which usually runs even slower.

I agree that a lot of what you program does matter on how good you are at that language (knowing what's the best way to do something) but PHP doesn't help you optimise things when there's no native caching/application store.

@ Kyle

Newer technologies like J2EE, Ruby, .NET, etc are a lot more resource intensive.

PHP sites are often slow due to poor programming- since it's a fairly simple server scripting language, the barrier to entry is very low. Many designers use PHP, despite not being particularly well versed in any other programming languages. This leads to poorly optimized code that works but may not work as fast as it could, had it been written better.

PHP isn't the greatest language written by a long shot- its not super fast, but I would say that it is fast enough. A massive supercomputer might seem slow- it all depends on the code being put into it.

Oli: Mind we are talking about a functioning website. The performance indicators for these generally have nothing to do with algorithm speed (this is a minor impact). The slow link is almost always in overhead (for instance, mongrel/fastcgi/etc for Rails sites + the rails codebase in memory) and database linkage. Pure algorithm tests are great for comparing languages to program things like desktop apps, but not for web programming. We're not crunching SETI information, we're serving up a dynamic page.

Also, keep in mind Java is hardly equivalent to J2EE + Struts/Hibernate/etc. Java itself may be faster, but the overhead required for a typical J2EE site is almost always massive (in comparison to PHP)

I'd say a lot of it comes down to bloated coding, not optimized servers, and just plain old bad coding. Other than that, I find PHP to be a rather fast language if caching is done properly and whatnot.

I don't think it's fair really considering the two sites given as examples or in the top 50 sites in the world. You have to expect that they are going to be hit hard no matter what. We can confirm that a lot of it comes down to how you code things because we go back and try to refactor our code as much as possible and it is amazing the stuff you can fix up the 2nd time around once you haven't seen code for a while.

Wow, that's really interesting Kyle.

I'm just starting to get into web development (stupid gen-ed credits...), so this is interesting info for me right now. In all honesty, PHP has seemed to be one of the fastest server-side technologies out there to me, but then there are the sites like Wordpress, Digg, Facebook, Last.fm, yadda yadda that can't keep up with the huge numbers of users...

Another reason a site may be slow: Lousy HTML or XHTML code. It may execute nice and fast on the server side, but then it chokes your computer to death when your browser tries to display the page.

Often ignored, but HTML code bloat can slow a site down even more than slow server-side code. I've found lots of sites that are well-coded server side but slow folks' computers to a crawl.

Kyle I know you wrote that reply almost a decade (in internet time) ago but I agree with one thing you said (or at least hinted) and that'll I'll concede: it's mostly not about the code execution time.

However, ASPNET has a really powerful caching system built right in. You can (as I do) write a layer of business logic that performs all database interactions. These objects persist in memory (not disk) so if I pull out my blog's data as a tree of objects and leave it in there, that's it. Database IO is the slowest part of a website.

PHP can cache things to disk and memory through memcached (et al) but they're nowhere near as fast as the native cache managers built into IIS and Tomcat and it's practised far less in PHP not, as you said earlier, because it's overlooked because PHP is so fast, but because it's royal pain in the arse.

I'll admit that it [IIS's cache] doesn't scale particularly well (yet) but for small-medium websites (even on shared hosting - as mine blog is), it will annihilate a site labouring under PHP even with a caching mechanism.

And I've tested this using exactly the same display logic. Memory caching was 1.8 seconds faster than doing all the DB work at runtime to display a fairly typical page. I haven't tested memcached in a similar scope because it would take a lot of reegineering for the sake of a silly test but that does have a TCPIP overhead (similar to a database's).

========================================

Scale does have something to do with this argument. Small PHP sites running off one database fare considerably worse [vs ASPNET alternative] than large, load-balanced and most importantly memcached sites.

When you're talking big, I'd be tempted to say PHP (et al) are the right choice because those technologies scale over multiple servers very well.

Just use a PHP accelerator. I can do 100K page loads a day on my Drupal (PHP based) site using eAccelerator. Makes a HUGE difference.

@Oli

I've done quite a bit of ASP.NET (1.0/1.1/2.0) work and in general practice, its never *seemed* as fast as a proper PHP environment. Granted, I haven't done any low level tests like you've mentioned - but I've even had ASP.NET apps running on dedicated servers and the speed on a shared PHP still *seems* much faster.

Anyways...the point is, PHP isn't slow, thats up to the programmer. None of the server-side technologies are slow if you optimize their environments properly, even Ruby on Rails.