There's a lot of high-performance, widely used PHP projects: MediaWiki, Drupal (to a certain degree though), Wordpress, Facebook...

Now let's take a look at some popular Java apps: Eclipse, SAP's frontend, Lotus Notes, Atlassian JIRA/Confluence, JDownloader... recognize the pattern of slowness?

PHP might have been designed by monkeys (and many of the early design mistakes are gone by now, anyway!), but at least PHP kept the 10-abstraction-layers-minimum monkeys away. Also, a PHP web (or CLI, or GUI) app will in most cases eat far less RAM than a Java app of same functionality.

Also, PHP projects are far faster to develop because the intermediate step of compiling is removed, and it's far easier (and faster) to deploy PHP projects than a Java web app.

Edit: did some quick measurement on a RPi 1, java hello world vs PHP hello world vs C hello world:

javac takes 16.8s wall time, 28MB peak RSS. Running the program itself is 1.99s wall time, 13MB peak RSS.

PHP in contrast is a single process with 0.7s wall time, 14MB peak RSS.

C takes 1.24s wall time for the compile, 15MB peak RSS. The resulting program takes 0.01s wall time, 1MB peak RSS.

Versions are openjdk 7u91-2.6.3-1+rpi1, php 5.6.14+dfsg-1+b1 and gcc 5.2.1-23+rpi1.

That compile time of javac is simply... wtf.

Simply not true: "modern" PHP apps, usually built with Symfony or Laravel, might appear simple from their controllers, but their abstraction stack is just as huge as Spring's. Just take some time to read Symfony's HTTP code. Or step-debug one from the first point in the first controller and see how many layers of abstraction you have before the actual application code.

Indeed, but in PHP it is at least possible to not use the performance sucker parts of the frameworks.

Java? Not so much.

Well, Symfony's Security component is actually based on Java Spring. It says so in the readme :)

The biggest hits to performance however seem to stem from components that you can happily do without -- annotation magic for example, and the Doctrine ORM.

Doctrine may be a complex beast, but it is so dead easy to use... I believe it's worth the performance hit.

> There's a lot of high-performance, widely used PHP projects: MediaWiki, Drupal (to a certain degree though), Wordpress, Facebook...

Facebook had to develop their own PHP-to-C++ transpiler to achieve something vaguely resembling useful performance. I wouldn't quote that as positive example…

Facebook also has 968 Million daily active users.

I just don't understand PHP bashers always using Facebook as a metric to bash PHP. "Oh PHP is so horrible, the second (sometimes even first ranked) most visited site on the internet had to write their own PHP-to-C++ transpiler to handle the load. Clearly PHP isn't a good choice for my 3 user site! I need that performance!"

Get over yourselves already. Every language has it's strengths and weaknesses.

Why so defensive? I'm just saying Facebook is not a good example. Of course there's fast PHP software – for example, all I wrote. ;-)

Because elitest attitudes garner idiotic responses and I'm sick of them.

Yes, Facebook had to write their own interpreter, but you also know what? Facebook also actively helps the PHP community and is ushering the community too. So anything Facebook creates they open source and PHP7 has taken cues from them. The whole net benefits from it.

Not to mention the next biggest website that is powered by PHP is Wikipedia, whom uses stock PHP to serve their sites.

Facebook has so much interactions and that, that they warrant the need for what they did. 99.9999% of most people don't need that. Not even Wikipedia. They just render a html page. Done.

Of which PHP 7 now equals/ surpasses in performance in a lot of areas.

Java is used in the back end of several high performance web applications as well. Twitter uses JVM and so does The Guardian, for example. Not sure what your point is.

Your criticism of Java for being slow is 1) very 2006 and 2) incorrectly based on desktop apps which require JVM restart and warmup time before they get going.

Put Java on the server and see the speeds. Using spark as your web framework, it's possible to achieve rates of over 40k requests per second ( I've seen claims of 160k requests per second after sufficient JVM warmup).

Citation needed, my friend..

As part of my day job we regularly deploy Wordpress sites that efficiently handle hundreds of thousands of page views per day (and yes I realize that's not HUGE but it's not trivial either) and we do it on cheap hardware that would barely run the stock JVM, let alone an actual Java app server.

"High performance" is relative to your costs & needs, and it's all about using the right tool for the job. If you know how to configure and optimize PHP applications properly, you can make them extremely performant.

Either way, it seems you're arbitrarily ignoring whole classes of apps or languages because of some outdated bias (that i bet you just accepted from others and never tested yourself), so you're obviously not interested in an objective discussion.

> cheap hardware that would barely run the stock JVM

I run two stock JVM instances and Redis on a $10 DO VPS that serves ~700k pageviews per day

> arbitrarily ignoring whole classes of apps or languages because of some outdated bias (that i bet you just accepted from others and never tested yourself)

hmm

Point taken on my rather glib final statement there. I deserved that..

I'll admit that my experience with Java web apps was never against bare JVMs, but against app servers (Liferay, etc). How common is it for people to roll their own no-framework bare web apps in Java?

Dropwizard and similar micro-frameworks are getting more popular. It's been several years since I ran a Java web application on an application server, and that was an application I was tasked with decommissioning.

In case you're not familiar with it, Dropwizard is a collection of libraries packaged up with some conventions and glue; it uses Jetty to serve HTTP and also integrates Jersey and Jackson (RESTful routing and JSON encoding) so that you don't have to do it yourself.

I, too, can put nginx microcaching in front of anything.

Why would I need that? It's not like I'm running Wordpress or something. haaaaaaaaaa (I'm so sorry)

> Anyway, calling wordpress or drupal "high performance" is a joke.

Well, these two platforms are by far the leader in the CMS space. It's either usability, ease of administration or speed that keeps people using WP/Drupal over alternatives in other languages/frameworks.

Seeing it from the point of view of a company with a few hundred Wordpress deployments: Definitely usability (if you want laypersons to be able to author content, there's little competition), largely availability of plugins, a bit ease of administration (it's getting better), but definitely not speed. Wordpress is so mindbogglingly slow that we have to use excessive amounts of caching for anything even remotely resembling medium traffic.

Honest question: do you not consider caching to be a normal part of a dynamic web application?

I've never worked with a CMS or web app - in any language - that didn't include caching as a core part of the performance layer once it reaches a certain amount of load..

I'm sure it's possible, with enough money to throw at hardware, to scale without it, but why would you? Caching is a completely valid optimization approach in my view..

> Honest question: do you not consider caching to be a normal part of a dynamic web application?

We should not be needing bare metal servers with 4 GHz CPUs to serve a non-interactive site with ~4000 visitors a day. Yet, without full-page caching (i.e., bypass Wordpress/PHP entirely and serve .html files straight from nginx), the servers would melt under the load.

Rendering twenty images and forty text fields out of database should not take several seconds on a modern server. Yet, Wordpress has no problems taking a dozen seconds even under light load conditions – mind you, that's time purely spent in PHP, for rendering, not on the database.

Wow.. So I work with Wordpress on a day to day basis as well and we don't see anything like this.. We have pretty DB-heavy sites (lots of ACF Pro fields and lots of relationships) and we're handling bigger loads than that, on much smaller virtual hardware..

I'm not making any specific value statement about your setup here, I'm just surprised by what you're seeing on your end.

It could just as well be our ACF+CPT fuckery that leads to this – I'm not that involved in the actual application side of things; I just provision the hardware and OS stack.

Still, we're usually seeing a lot better performance with everything that's not wordpress – be it our in-house PHP framework, or node, Rails or Python apps.

Opcache is enabled, SSDs are in hardware raid and the whole time is spent inside PHP, MySQL finishes all queries after 0.02 seconds. The usual suspects are all dealt with.

Well Wordpress long came without any caching at all, dunno if that's changed by now. Drupal in contrast comes with its own DB caching.

Both can be plugged into memcache and friends, and if done right you can put in Cloudflare or other frontend caching systems in front.

Biggest performance +1, though, is enabling php opcache.

The answer to "what's the best language?" should not be "language X", but "what are you making?"

Once you've defined the requirements, restrictions, and personal abilities, only then you can have a meaningful discussion on what the "best" language is - and even then there is more than one answer.