PHP 7 deployment at Dailymotion • Hacker News Board

Re: PHP 7 deployment at Dailymotion

#101

Post by babyrainbow » Fri, Oct 14, 2016, 8:07 AM UTC

SomeCallMeTim wrote: post #46

Goopplesoft wrote: post #44

Earlier quoted context omitted.

> What's with people expecting frameworks to do everything for them these days? I don't think that's the expectation. PHPs reputation seems to surround the fact that it tends to be (or was) the first language amateur coders dabbled with. That crowd is especially susceptible (at least before mysqli, etc) to making mistakes that amount to serious security vulnerabilities. Historically, these seemingly benign things tha…

>PHPs reputation seems to surround the fact that it tends to be (or was) the first language amateur coders dabbled with. That's certainly part of it. JavaScript suffers the same hate today -- amateur and junior developers produce thousands of lines of crap per year, and people blame it on the language. But PHP itself is just a mess. I'm an experience developer (about 30 years at this point), and about 12 years ago I…

>JavaScript suffers the same hate today..

The difference between Php and Javascript is that Javascript have competent people driving it forward. Php is still developed by college students with no real world programming experience, in their spare time....

Downvotes? Don't think this is true? See the following. These are couple of most prominent people working in the language.

[1] https://nikic.github.io/aboutMe.html

[2] https://ajf.me/

Re: PHP 7 deployment at Dailymotion

#102

Post by Chyzwar » Fri, Oct 14, 2016, 8:13 AM UTC

babyrainbow wrote: post #87

developer2 wrote: post #64

Earlier quoted context omitted.

> Are you expecting it to be an integer? Easy > if(!ctype_digit($_POST['ID'])) { // throw exception here } ctype_digit is broken. Try passing integer values. ctype_digit(50) === true, but ctype_digit(100) === false. And "0000001" passes as true, which most people in the majority of scenarios would prefer not to pass. I can't remember what the even-worse-bug is with ctype_digit is, but even if you cast the value to st…

>try passing integer values. ctype_digit(50) === true, but ctype_digit(100) === false. That is hilarious! I love how even stuff that is supposed to fix other stuff itself end up being completely broken. But hey, it is documented. Learning Php is like taking a massive loan. It get you started easily, but causes eternal suffering in the long run...

Yes, The worst part is that it will make you worse developer. It is like drinking a lot of soft drinks, side-effects will kill you.

Re: PHP 7 deployment at Dailymotion

#103

Post by proyb2 » Fri, Oct 14, 2016, 8:35 AM UTC

SomeCallMeTim wrote: post #48

jpgvm wrote: post #31

Earlier quoted context omitted.

As I said, by all means you can write bad code in good languages. I'm not saying choosing a good language excludes all possible bad code, only that they provide some guidance on better practices. So you mention Java. Java enforces OOP. Now OOP may not be the best paradigm always, however its a vast improvement on inline procedural PHP. That isn't to say you can't write some horribly modelled Java code, but the fact t…

It rare that I see good Java code, especially that written by junior developers. I think OO is a hard concept to get right. I know it took me years to master, and one of my epiphanies about OO design is that it's not always appropriate. Yes I can tell you the best OO approach to a problem, but I can also often tell you a better approach that isn't OO.

Functional and OO always go hand-in-hand. I love Swift Protocol, Generic and soon Reflection.

Re: PHP 7 deployment at Dailymotion

#104

Post by ucho » Fri, Oct 14, 2016, 8:46 AM UTC

haimez wrote: post #54

cjhanks wrote: post #51

Earlier quoted context omitted.

if predicate: A = 3 else: A = 5 B = A / 2 ... Why forward declare A = None?

Because it announces that you intend to use the name 'A' in the current scope after some assignment happens in a nested one. It's intentional. It /can/ be useful, but it should be opt-in. JavaScript had to figure this out with their 'var' declaration scoping too. Also, try: A = (predicate) ? 3 : 5 Or, in a language that embraces expressions instead of statements: val A = if (predicate) { 3 } else { 5 } These are all…

Java has also alternative approach:

    final a;
    if (predicate) {
     a = 3;
    } else {
     a = 5;
    }

`final` makes it possible for variable to be assigned exactly once. Verbose but useful when "?:" is not a good fit.

Re: PHP 7 deployment at Dailymotion

#105

Post by Noony » Fri, Oct 14, 2016, 8:55 AM UTC

nchelluri wrote: post #4

> It took less than a week to migrate our codebase (a 10 years old PHP monolith)... > And it took 4 hours to migrate our custom extensions. That seems like a very small amount of work; I'm impressed at how smooth a transition that must've been. I'm also quite surprised that > we can handle twice more traffic with same infrastructure. Wow, I didn't think that PHP application code would be such a bottleneck. Maybe it's…

Hey, I'm the author of this blog post, I'll try to respond to your questions:

> Wow, I didn't think that PHP application code would be such a bottleneck. Maybe it's not that, but if the entire codebase is written in PHP, and you replace it all in one shot, you just get such an improvement. But I thought DBs, etc. would play a bigger role

Indeed front-end servers not the only bottleneck to handle more queries. We also made data migrations on mysql databases to optimize memory utilization, two months after the php7 migration. Code migration and the validation that we hadn't introduced new regressions / errors by redirecting a small percentage of the traffic through two servers with php7 configured during few days before full deployment. Full deployment on our production farm (more than 250 servers) was done in less than two hours with the possibility of rollback)

>> It took less than a week to migrate our codebase (a 10 years old PHP monolith)... >> And it took 4 hours to migrate our custom extensions. >That seems like a very small amount of work; I'm impressed at how smooth a transition that must've been.

We used phan and phpcs to discover our incompatibilities, it doesn't find 100% of problems, but it really reduced time to find where there was backward incompatibilities. It's a first step before unit tests / small load test on production. I wrote a small blog post on how to use this tools to migrate your applications : https://medium.com/@colomb.thomas/php7-how-to-migrate-your-a...

Thanks!

Re: PHP 7 deployment at Dailymotion

#106

Post by blowski » Fri, Oct 14, 2016, 8:55 AM UTC

brianwawok wrote: post #37

mgkimsal wrote: post #33

Earlier quoted context omitted.

comparing "simple java app" to something as complex (overly? needlessly in some cases? sure) as magento is nowhere near apples and oranges. compare it to broadleaf or konakart, maybe. I've no doubt java will probably still be faster, but it won't be 500 rps vs 3 rps.

Except I have built Java apps that did the same kind of things as Magento, and yes it really was 500 to 3.

At a guess, you left everything in development mode. I've seen similarly specced hardware easily handle around 100 requests per second just by configuring Magento and Opcache for production (as per documentation).

Re: PHP 7 deployment at Dailymotion

#107

Post by ucho » Fri, Oct 14, 2016, 8:56 AM UTC

mgkimsal wrote: post #32

geerlingguy wrote: post #8

Earlier quoted context omitted.

For a lot of array-heavy applications (where you store all kinds of data in giant multi-level PHP arrays), the memory usage alone counts for most of the speedup; instead of wading through tens or hundreds of MB of array structures, PHP 7 trimmed things down by a factor of 2 or more. There are a lot of PHP apps/CMSes/etc that gained 30-50% speedups due to just that improvement. Other more optimized apps/scripts saw a…

IIRC, a PHP array entry had 127 bytes of overhead. PHP 7, that went down to 42(?). Also, IIRC, for JVM, it's .. 37? 40? PHP7 got array overhead down a lot, and I do believe that's where a lot of speed improvement came from (though certainly not all of it).

PHP array is equivalent to LinkedHashMap and yes, it has 40 bytes overhead per entry in Java.

Re: PHP 7 deployment at Dailymotion

#108

Post by Noony » Fri, Oct 14, 2016, 9:05 AM UTC

LinuxFreedom wrote: post #100

“how to scale without investing too much in people/servers” This exactly is the antisocial and greedy attitude that we have to actively fight if we want peace, freedom and prosperity for all people. Please cancel all your dailymotion accounts and let these disgusting people disappear forever.

Hey, I'm the author of this blog post, I'll try to respond to your comment : This is not an antisocial and greedy attitude, every society have this problem. Dailymotion invests a lot in teams, and servers. But sometimes you have to think differently, "is there something to do before I buy new servers / rewrite all our application ?", to let more time for co-worker to implement a new architecture.

Re: PHP 7 deployment at Dailymotion

#109

Post by m_t » Fri, Oct 14, 2016, 9:09 AM UTC

babyrainbow wrote: post #89

Akujin wrote: post #38

Earlier quoted context omitted.

I don't get why people keep harping on super globals are being inherently bad. The variables are there. You can use them or ignore them. A variable definition harms you in no way other than a tiny bit of memory usage which is capped by the HTTP limit on POST and GET limits anyway. What? You think you're gonna get hacked because $_POST['ihaxyou'] is set to 'w00ts'? No one does this anymore: mysql_query("SELECT * FROM…

> The variables are there. You can use them or ignore them... Ever worked in a team?

Yeah. We solved that problem by still not using those variables.

Re: PHP 7 deployment at Dailymotion

#110

Post by Juliate » Fri, Oct 14, 2016, 9:27 AM UTC

nikcub wrote: post #14

Hack and HHVM solves what is, IMO, the worst feature of the default PHP runtime environment[0] - and that is the superglobals. It wasn't mentioned in the post from Slack, but default superglobals and the earlier register_globals design decisions are the worst and most impactful wart in PHP. Because it was designed as a templating language, the default web server interface, which is CGI - will auto-expose all variable…

> I've seen this so often - because it's so easy to do it.

That's the very point. PHP was/is _easy_ to pick up. You get something working quickly. Then you meet problems. And hopefully, you learn along the way and fix that (and see, this whole thread is from people that learned how not to use $_GET/$_POST).

This "build/make it work/fail/fix" loop was an ingredient that made PHP so popular. The "happy code path" was not a pain to setup.