Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP 7 deployment at Dailymotion

engineering.dailymotion.com

Post reply on HN
Print view View original

31–40 of 166 posts

Re: PHP 7 deployment at Dailymotion

#31

Post by jpgvm »

brianwawok wrote: post #28
jpgvm wrote: post #25

Earlier quoted context omitted.

By all means, but having the language nudge people in the right direction makes a world of difference. PHP, much like Javascript is terrible for new developers for this very reason. Learning a "good" language for lack of a better term is no more difficult than learning PHP/JS and is always worth the effort, if anything learning "good" languages is usually much easier because they are usually internally consistent.

See I can't decide on this. What is a good language? Java? If all newbs picked up Java as language #1.. would their apps be better? Or would the really bad devs writing copy paste stack overflow code just be unable to understand it, so they would quit? Like is it safer because it keeps out knuckle-draggers, or safer because it is actually safer? Cuz I can write some horrible Java code that will rival anything you can…

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 that modelling tools are so explicit and forced on the user makes the user at least think about how to use them better.

Other peoples opinion may differ from mine but I maintain this is incredibly important in speeding up new programmers towards writing good code.

Re: PHP 7 deployment at Dailymotion

#32

Post by mgkimsal »

geerlingguy wrote: post #8
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…

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).

Re: PHP 7 deployment at Dailymotion

#33

Post by mgkimsal »

brianwawok wrote: post #30
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…

have you ever loaded a stock magento server? Set it up, add maybe 10 products with basic images, and turn it loose. Give it a reasonable box. 2 CPU cores, 2 GB of ram. You are capped at something like 3-5 requests per second, with an average load time of 5 seconds.. Just blows my mind. Simple Java web app on the same server is doing 500 requests per second. Python app, with the horrible gil and all that nasty is goin…

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.

Re: PHP 7 deployment at Dailymotion

#34

Post by Grazester »

alien3d wrote: post #27
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…

why not using filter_input or casting it ? e.g $userId = (int)$_GET["userId"]; and also when query to db using parameter binding ?

Yeah, a prepared statement would take care of this just fine

Re: PHP 7 deployment at Dailymotion

#35

Post by [deleted] »

alien3d wrote: post #27
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…

why not using filter_input or casting it ? e.g $userId = (int)$_GET["userId"]; and also when query to db using parameter binding ?

[deleted]

Re: PHP 7 deployment at Dailymotion

#36

Post by TurningCanadian »

brianwawok wrote: post #30
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…

have you ever loaded a stock magento server? Set it up, add maybe 10 products with basic images, and turn it loose. Give it a reasonable box. 2 CPU cores, 2 GB of ram. You are capped at something like 3-5 requests per second, with an average load time of 5 seconds.. Just blows my mind. Simple Java web app on the same server is doing 500 requests per second. Python app, with the horrible gil and all that nasty is goin…

Likely need to enable and/or tune opcache

Re: PHP 7 deployment at Dailymotion

#37

Post by brianwawok »

mgkimsal wrote: post #33
brianwawok wrote: post #30

Earlier quoted context omitted.

have you ever loaded a stock magento server? Set it up, add maybe 10 products with basic images, and turn it loose. Give it a reasonable box. 2 CPU cores, 2 GB of ram. You are capped at something like 3-5 requests per second, with an average load time of 5 seconds.. Just blows my mind. Simple Java web app on the same server is doing 500 requests per second. Python app, with the horrible gil and all that nasty is goin…

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.

Re: PHP 7 deployment at Dailymotion

#38

Post by Akujin »

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 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 `table` WHERE `id`=".$_POST['ID']);

There's absolutely NOTHING wrong with having $_POST['whatever'] inside a controller as long as you're doing proper checks.

Are you expecting it to be an integer? Easy

if(!ctype_digit($_POST['ID'])) { // throw exception here }

Contrary to the hive mind you don't need some special encapsulation class to pull your post and get variables.

HHVM does not in any way solve this issue. You still have to write proper validation into your code or you'll get hacked. What's with people expecting frameworks to do everything for them these days?

Re: PHP 7 deployment at Dailymotion

#39

Post by vcarl »

wyager wrote: post #21
madeofpalk wrote: post #11

Earlier quoted context omitted.

I would assume by this point that PHP devs would be fairly confident and comfortable with their decision to continue with PHP and would be used to others bagging on it unnecessarily. As a JS/Web developer you learn to ignore the hatred of the web that it seems to get from the HN crowd.

>As a JS/Web developer you learn to ignore the hatred of the web that it seems to get from the HN crowd. As an occasional full stack developer (not by choice), I can confidently say that the reason people hate on popular web tech is that it is uniformly terrible compared to non-web tech. I'm no fan of Java, for example, but I'll take it over PHP any day. JavaScript is so bad that I (and many other developers) will pu…

This is the typical "hatred of the web" that I usually ignore. ES2015 brought a ton of huge language improvements that are still filtering out into usage, Babel means you can use them all now without waiting for browsers to implement them, Webpack gives you a ton of flexibility for packaging it, Eslint allows you to lint in a completely pluggable way, NPM (and now Yarn, which fixes many of NPM's problems at scale) allows you to effectively manage dependencies, Typescript or Flow allow you to incrementally add the benefits of static types, and Javascript's "functions as a first class object" allow it to behave as a powerful functional programming language.

It's very possible to write--and deploy--very high quality Javascript today.

Re: PHP 7 deployment at Dailymotion

#40

Post by nkozyra »

verelo wrote: post #3

We did the same thing with HHVM, and had VERY similar results; getting it to work was plain hard, and i had a lot of concerns about our ability to ever go back. Before we ever launched with HHVM completely, PHP7 came out. With only a few weeks of work, we managed to make the switch. The gains were identical to what we saw on HHVM, only the experience of working with PHP7 was so much easier for everyone involved. Havi…

Hack's influence is all over PHP7, unsurprisingly. As someone still bound to PHP due to technical debt, I'm thrilled this happened. PHP still has warts, but changes in 7 are tantamount to ES5 :: ES6. The language feels more mature, real, sensical.
Post reply on HN