Hacker News Reader

Comment by ddw | Hacker News Reader

But program managers and CTOs and other non-engineers at a company care about scalability, performance, technical debt and quality, right? Let's not pretend that these don't matter once you've gone past the "users actually care about our app" phase, because they do and they affect the bottom line of a company. And IMHO PHP falters in these regards.

View on HN

At this point, I would have no problem arguing with a straight face that your choice of technology stack might be the least important factor in whether your business succeeds or fails. I don't mind if I get torched for this, it's just my current, non-Silicon Valley, non-substantiated opinion at this time (though I don't think it's without merit).

> But program managers and CTOs and other non-engineers at a company care about scalability, performance, technical debt and quality, right?

Rarely. Mostly they care about meeting quarterly goals and budgets; and ease of finding inexpensive, more-or-less competent talent. In both of these, PHP excels.

I'm currently maintaining an app stack for a Fortune-100 company that, if I told you what it was, you simply wouldn't believe I was telling the truth. That's how out of date it is. "Scalability, performance, technical debt and quality" never entered into it. All anyone ever cared about was "does it get the job done and what does it cost to keep it running for another year as-is?"

I'd upvote this many time if I could. I am in the same boat--my team helps maintain a ten year old web application that is used by the largest companies in our domain. The application is literally the backbone of data used by these companies to make money. We have reliability issues, and sometimes clients get a little upset, but every year it is the same thing: how much do we need to budget for support?

> Rarely. Mostly they care about meeting quarterly goals and budgets; and ease of finding inexpensive, more-or-less competent talent. In both of these, PHP excels.

This. In my previous job, I was literally told by my boss, that they'd consider switching from PHP to something like Ruby or whatever, but PHP programmers are cheaper so that's why they stick with it.

Performance? You need to update your act. PHP7 is 3x faster than python and now faster than Java 8 . The only people that can call php slow are masochistic c++ web hacks.

https://blog.famzah.net/2016/02/09/cpp-vs-python-vs-perl-vs-...

This benchmark shows things a little bit differently.

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

But I think, what's important to note is that PHP 7 has improved in speed department by a great deal.

It's probably worth mentioning that the regex-dna test time is kind of incorrect and provides an inaccurate view of what's happening.

Java-8 is using java.util.regex which is written in Java, PHP is passing the regex requests to it's own regex process which is actually a C package and performs a lot faster.

What we're actually comparing here is:

time(java.util.regex) > time(php compilation + c regex package)

> Java-8 is using java.util.regex <

No, the fastest Java program shown does not use java.util.regex

The fastest Java program shown uses com.basistech.tclre

> a C package and performs a lot faster <

You're welcome to contribute a Java program that uses the PCRE library --

http://benchmarksgame.alioth.debian.org/play.html

PHP's execution performance is highly dependent on whether you are piggybacking the C implementations, or pure-PHP ones. That said, this is still a correct benchmark, if your use case involves a lot of regex.

Perhaps the problems are with the way the Java program is written and run?

Back in 2012:

"5) The idea is to help you understand that you aren't comparing what you say you're comparing.

If your intention is to compare time taken to grow a list, then shouldn't you start with lists that are the same size, and start with program heap that's the same size, and use the same max heap size?

        user+sys for your Java program = 20.56s

But change

        ArrayList<Integer> s = new ArrayList<Integer>();

        ArrayList<Integer> s = new ArrayList<Integer>(8192);

and run with

        java -Xms1G PrimeNumbersBenchmarkApp

        user+sys  = 6.9s

I don't think you're comparing what you say you're comparing."

http://www.famzah.net/download/langs-performance/java-discus...

I don't care about performance. Unless we are speaking about orders of magnitude and my use case has an absolute need for performance. If I only cared about performance I would write everything in assembly optimised for every specific architecture. But strangely I'm much, much, much more productive writing in c#, Java, groovy, f#, ruby and whatever language is appropriate for what I need to do at a certain time. For sure I won't start a new project using a language in which writing such abominations as accessing the database in the presentation layer is not even discouraged, but it is actually encouraged and taken as an example on HN in this thread. Enjoy your marvellous php. But please stop the bullshit that pushed a lot of people to use that franken-language rather than using a better approach.

Most professional PHP developers I've anecdotally worked with use a Model-View-Controller pattern these days, where the SQL is abstracted away in the model under something like Doctrine2-DBAL, Propel2 or PDO. If I was hiring for a developer and they suggested putting raw SQL in the view layer, I would reject them. If I received a pull request from my team which did the same, I would reject it.

You seem unnecessarily argumentative about this, almost like you're angry and I really don't understand why. There really isn't that much difference between languages like Ruby and PHP to warrant this and almost anything can be expressed in almost the same way, the only real differences are syntactic sugars and the "flexible" type system.

This exactly. Never been a PHP developer, but I did get handed a PHP webapp to copy some functionality out of for a replacement C# webapp. I was a little surprised to find out that it was written in a rather Rails-like architecture using some PHP MVC library, I think it was CakePHP. Rails was a hit, and a great step forward in web development, so naturally every other language copied as much of it as possible, including PHP. There may be plenty of weird quirks about the language still, but at least the architecture is much improved.

Many/most PHP platforms these days do claim to be either MVC or Rails-based or both. CakePHP is not a bad example there. There are however a few other very large projects whose take on MVC is lacking to some degree. Drupal is not bad, Joomla is worse, and of WordPress the less said the better. Note also that those projects are listed in order of increasing popularity.

Modern PHP frameworks and tools are good, perhaps even excellent. Composer and the PSR-# efforts have spurred a renaissance in code quality and interoperability, and PHP7 brings some truly impressive speed improvements. For those of us who aren't stuck supporting legacy code, that is. One of these days I will be working with a language whose syntax I enjoy, but until then the language that puts the "sin" in "syntax" will (for better or worse) keep getting the job done.

Performance is directly related to profit on consumer apps. See http://glinden.blogspot.co.uk/2006/11/marissa-mayer-at-web-2...

plus like you say PHP might be faster to get started with but becomes much slower on larger projects due to inconsistent error handling and language design.

Funny that people complain about js performance. In this benchmark it was 3 times as fast as php7 and about 7 times as fast as java 8. Have not checked the details of the benchmark yet.

It's worth noting that it's compiled JavaScript vs. interpreted PHP. With something like HHVM the PHP version would likely be a lot faster.

Compiled JavaScript?

I think he meant JIT compilation.

Looks like you're reading that wrong? Java 8 is listed twice. Java 8, when using the non-standard library version of the program is second only to C++. This is pretty much as expected.

> Have not checked the details of the benchmark yet. <

"Will your toy benchmark program be faster if you write it in a different programming language? It depends how you write it!" ;-)

> now faster than Java 8

Don't trust everything you read on the internet, run the benchmark yourself and see if that result is actually reproducible. (Depends on the heap size.) There is also a "non-std lib" java test case, which doesn't generate as much garbage and, of course, performs much better.

Managers caring about technical debt? You must live in a parallel universe. They may care about maintenance costs, but that is not really the same thing.

They don't until things break, your app can't handle the amount of requests coming in, can't insert and fetch data in a reasonable amount of time, etc.

It's at this point that shit falls apart and the manager starts to care about these technical choices and all of the time and money that will be needed to be spent to rewrite.

Call it maintenance costs if you want but those costs are directly affected by the technology decisions you make.

the end result of technical debt ==> maintenance costs makes it same enough.

Looking at things from the other side: being a manager and trying to sell projects to reduce technical debt is really freaking hard in a world of short-term outlooks and revolving door of CEOs that want to improve numbers this quarter or the next, not a few years down the road.

This is entirely true, but I have never worked with someone beyond the leader of my immediate who though the same. Most managers don't care what cruft is in there when it ships.

The scalability of PHP is great, because each request is fully independent. This is like the Amazon lambda model. You /have/ to put your state in some storage back end, network attached RAM or such. This is a scalability best practice!

Yeah, but you also have to fork a whole process per request to do it.

Process fork, CoW overhead every time you mutate a page, and a full OS thread per request. Oh, and let's not forget negotiating a new database connection per request.

I think by the time you've added up all those overheads, you're not off to a scalable start. It's possible to work around the limitations, but it's not easy.

"fork" is not a major problem in PHP. In Drupal, every single request compiles a file "common.inc", of several thousands of lines of PHP code. That is what slows it down. It's remarkable that PHP still manages to do that in just 100ms.

In Zend Framework it's slightly better because it includes an autoload option, which implies only PHP files that are actually used by athe request, get loaded. That way the overhead is "only" 50ms.

Wow. Is this comment from 2003? Uh. Why don't turn on opcache [1]? PHP7 is fast. Real fast [2].

http://php.net/manual/en/intro.opcache.php

https://blog.famzah.net/2016/02/09/cpp-vs-python-vs-perl-vs-...

> PHP7 is fast. Real fast [2]. <

You need a lot more than a "Sieve of Eratosthenes" code snippet to back that up :-)

> In Drupal, every single request compiles a file "common.inc", of several thousands of lines of PHP code.

This only proves Drupal is slow.

> Yeah, but you also have to fork a whole process per request to do it.

Eh, any PHP developer worth their salt is implementing PHP-FPM. The days of forking expensive Apache processes have long been over.

The whole reason your Apache was (kind of) expensive to fork was PHP. You've only moved that forking to the PHP-FPM process.

But that said, forking processes is not really a problem unless you do really long lived connections (such as longpoll handlers). Many other languages do that. Not many other languages have kept the CGI-like request model that PHP has, though.

It encourages things like parsing code or even opening database connections on every request, unless you cache them. (Which you probably do if you are a PHP developer. But it's not always as automatic as one would hope. Have you checked your application still fits in the cache you set up?)

And even whey they were not over yet there was no fork for each request. A pool of workers was forked beforehand, and each worker could handle requests one by one without restarting (only PHP environment is cleared, OS level process is not restarted).

It is easy if you are just willing to spend more money on servers. Often it's worth it.

Its also a problem that has been solved a long time ago and is well understood. Unlike trendy microservice architectures....

Only if you extract a ton of value per user or can serve a huge number of users per machine. Otherwise, upping the number of servers by an order of magnitude will start requiring an operations team to maintain.

That was a pretty common truism 10 years ago, but machines haven't gotten faster at the same rate lately.

it's the "good problem". and the good problem can always be solved, though lack of reliability can seriously hurt your growth. but that doesn't mean that it's as easy as people make it out to be.

i wrote and ran a big php app (Zynga's Mafia Wars). this is just about the app server (apache + php side), single-master MySQL will give you far greater problems at that scale.

everyone is tearing away adding features, and the code just keeps getting bigger. everything includes everything else. so you can't just start fresh with every request, it takes way too long. so you use APC or whatever. now you have global shared state (and people start using it), but as long as no one really fucks it up that's ok.

php processes are always erring and dying in weird ways that no one can figure out, especially if anyone uses the half-baked OO stuff (circa 2008-9), and tracking down obscure php state errors ranges from difficult to impossible since you're never quite sure when or where something went wrong, but it works for most people most the time, as long as you remember to clear out the error logs so they don't get big enough to crash the box.

memory use still sucks at around 30M a process, meaning you can only have around 500 workers on at 16G RAM server, but it's workable. at least it's not rails.

because it takes a while to talk to even Memcache (go forbid you talk to MySQL) and do all your silly user updates (games are really write-heavy) you are taking a few hundred ms per request, so 16G mem servers (it's 2008) safely top out at around 500-600 req/sec, and i think would melt close to 1000 or so. remember, your throwing everything you have at growth and features so you're not really optimizing shit.

cool, just need more hardware. which is no problem. if you can get hardware. when you're co-located it takes forever to get new hardware online. not really an option. and even the F5 load balancers can only take so much. and there are issue with getting too many app servers talking to too many memcache servers. or something like that. after i left i think they saturated the data drops, which really puts you in a bind.

but that's not a problem now, with cloud services, right? except that those are not limitless either. i think FarmVille ran into a wall where AWS wouldn't / couldn't supply more instances (again, this was around 2009-10 so prob a lot better now). and those are still physical machines in physical datacenters somewhere that will have all the same problems and limitations and then some.

but you're going to have problems with any app runtime at that scale. and php's performance was an order-to-two or magnitude better than rails, and we never figured out how to get significantly complex and traffic-heavy java apps to stop leaking memory. though i'm sure you can. and you will! like i said, it's all solvable. hell, even MySpace didn't fail because of tech infrastructure.

what i'm saying is that php wasn't (and maybe still isn't?) particularly fun when throwing hardware at it doesn't work, and you end up losing a lot of the purity / simplicity of the model because it's too damn expensive. ffs, Facebook re-wrote the runtime. that's what it took for them. and my friends there tell me it's pretty much like writing java at this point. it's a fine choice, but i'd rather not use it again. had a much better time with python before javascript ate the world.

>php's performance was an order-to-two or magnitude better than rails

Again PHP (the language) vs. Rails (the framework).

What framework was that `big php app` using?

> What framework was that `big php app` using?

PHP is a framework. True it's not a particularly nice one, and some people build even more layers on top, but it comes with all manner of HTTP/url/DB/etc. stuff out of the box. It's also a templating language (that's what the "<?php" tags are for); although, again, not particularly great, and some people layer more abstractions on top.

In the sense of comparing PHP and Rails, then no PHP is not a framework. Codeignitor, Laraval, Cake, Yii; those are PHP frameworks and fair comparisons to Rails.

I can (and have) just grabbed Rack and rolled most everything myself in Ruby and it has way less overhead and is much more performant than Rails. Ruby also has it's own templating language; ERB is part of Ruby core.

So comparing PHP to Rails is a bit apples and oranges.

it's a business decision comparison, not a technical categorical comparison. you need something to receive http request and return http responses, and you're comparing different popular (because hiring, training, and available community / support resources) ways to do that. they might be apples and oranges but at that level you're concerned with comparing fruits.

In this case it was a technical comparison; the original poster stated, "php's performance was an order-to-two or magnitude better than rails".

If you are making a technical comparison then it needs to be at the correct layer of abstraction. If we were to compare performance of Laraval and Rails that would be a fair comparison.

If we are comparing on performance then PHP should be probably be compared to Ruby+Rack since that is sort of the lowest common denominator.

I'm not dogging on PHP here either. Even comparing at the correct level; PHP is still faster, but lets make sure we are making the right comparisons.

i am the original poster.

i was clarifying the compassion.

Very true. It's basically an interface to a C framework.

as the other commenter said, php is a web framework... and it's what we were using. it's actually more of a web framework than a language in my opinion (or at least was at that point). it's centered around receiving http requests and writing http responses. the article mentions this in fact.

it was a huge pain to try and get php to do anything else. it was totally unpractical to do the kinds of back end processing that we needed (since the database was pretty much off limits during a http request)... long running processes with hundreds of millions of objects were a no-go. believe me, we tried. which meant you had to sync all your logic into Java or something else that could handle the job. which is really error prone when you have a bunch of people moving fast on something.

one of the greatest things about php is that it's a super minimal focused framework. it's also one of it's major short-comings when that model no longer suffices.

you can layer something else on top of it, but the stuff available at the time certainly didn't help the performance or memory characteristics.

I think I sat next to you at zynga back in 2008 and remember your php struggles vividly.

hey Josh!

I feel your pain, I also worked on a large MMO style mobile game backend, but my situation was a lot better because as you say AWS is a lot more mature at this point.

Dealing with limited resources such as MySQL and Redis is a problem you still have to fix when you move away from PHP though.

As for the Facebook runtime, for us it was a case of drop in HHVM, fix a handful of issues and get a 4x or 6x speed increase for free. You only need to change the way you write if you move to Hack, but I think I agree with you that's probably getting to the limit of the effort reward tradeoff before you rewrite in a different language.

Why didn't you choose Python/Django instead of PHP then?

Reply on news.ycombinator.com