 Alright welcome everyone. Thank you for coming to the first session track of the day and honoring us with your presence. We are here to talk about PHP performance, a subject near and dear to all of our hearts I am sure. The topic is gonna cover a little bit of like the background of PHP performance and what we the history has been there and then we're gonna talk about things that are on the horizon or just now possible to do and and we've got some benchmarks and some other neat things to share with you. So who are we? I'm my name is Josh Koenig. I'm a co-founder of Pantheon. I made my name in Drupal Performance with this project Mercury thing which was like a Amazon machine image with all the stuff cobbled together to do as about a good a job you could do in circa PHP 5.2 in making Drupal really fast and up here with me is David Strauss. He's a CTO at Pantheon and he did press flow which was the high performance variant of Drupal for Drupal 6 and Drupal 7. So you know we got a pretty deep background of this stuff so we know some of you and happy to meet more of you afterwards if you guys want to chat. So the first thing I'm gonna do is I'm gonna ask David who's gonna play the role of Doc Brown in today's presentation take us back in time to you know actually when we were first started working together you could really call that the dark ages of PHP and set the scene. So in the dark ages of PHP the goal was to have as little run in PHP as possible and it still is to a limited degree but there was just no other option. You knew the PHP was never gonna get better and you knew that the frameworks were only gonna get more bloated to cover the difficulties in PHP so you would just try and yank as much stuff out of it as possible. In fact this was largely the principle behind a lot of things in press flow and project Mercury is the idea that let's make these tweaks to the framework so that you can remove this part from PHP or remove that part from PHP and the the problem was is that there was a very stagnant upstream with a very broad downstream in terms of frameworks using PHP. There was no upstream progress because there was infighting, there was defection to other projects that were sexier at the time and this led to really poor reuse options because there were missing language features and tools like Peckle and Pear were just not convenient to use. The communities were fairly insular in terms of people who could join those and release packages on those systems and then that caused frameworks to bloat which is why if you look at say the Drupal 6 style way of working with databases we reinvent a whole bunch of things so that we can operate securely with the database system whereas in Drupal 7 we've rebuilt on top of PDO which is a fundamental language feature that provides a lot of the capabilities that we need and because there wasn't really good reuse and we had to build so much in every framework there was a strong not invented here syndrome that was proliferating through the community where each framework would reinvent these fixes on top of the language so that they could cover the gaps that were in PHP and then this had the effect of repeating the cycle. It's a reifying thing. The more discontent people could become with PHP the more they leave the community for things like Ruby on Rails, Node.js, later Go, things like that because they're not getting satisfaction that the fundamental core of where they're working was moving fast enough and advancing but fortunately that is changing. A couple other points on that. One of the things examples of this that come to mind to me I don't know if I'm an old-timer in Drupal but at DrupalCon in Copenhagen we had Rasmus as our keynote speaker and he was talking about the making Drupal faster and his suggestion at the time was to rewrite core components of Drupal in C and then load them in as shared libraries which was kind of a that was the best alternative anybody could come up with and it would that would have just continued to promote this kind of balkanization and what happens when you have all of the talent in the community working on essentially reinventing the wheel to cover over features that are missing from the core language in their various frameworks is the core language doesn't improve very fast and that's also because they had like as David said for a while a PHP core like you literally had people going in late at night and reverting other people's commits it's like classic poor like open-source community juju like in Drupal we're very lucky to have a pretty awesome and pretty high functioning there's lots of Drupal drama but other projects have had it way worse at various points in time and like the mid to late aughts was a really bad time for PHP core they also had all this legacy right so there's like all there's still all this PHP for that's out there on like the crappy shared hosts of host Gator and Bluehost and all those things because it's like you know and they're there people who are just never gonna want to upgrade and that that at a certain point that was really holding a lot of things back because that's that's pretty old stuff PHP for honestly that's like not very modern and they face these headwinds of like the other things in addition that were that would slow down development but as you are alluding to David thankfully this is no longer the case yep and so there this this broke fortunately this this reifying cycle and I think that you could make a lot of arguments but I think Facebook is largely the credit for breaking the cycle in PHP and I think they broke the cycle when they decided to create a competitor to the Zend engine with hip-hop PHP not because hip-hop would become the runtime of many people in fact probably very few production PHP implementations are running on hip-hop or its derivative or its later incarnation HHVM right now but the important thing is it refocus the community and it recreated urgency around making those improvements to the project getting the community in order getting contributions in order providing the features that people would need in the base language so they would not have to continue to repeat themselves in every single framework with filling in those gaps and it's actually kind of analogous to what I've seen happen with the C language with GCC with Apple's work on LLVM where they created a competitive open-source compiler and that's much more broadly used relatively than say hip-hop is in the PHP world but it created a competitive atmosphere where it was no longer sufficient to just have a large installed base and rust on those laurels and just have no progress shown for years and I think the other thing you'll see is it's this notion of competitive implementation that are easily interchangeable drives innovation and the other thing I would say and again credit to Facebook prior to their even doing the hip-hop project they said we are gonna make a big bet on keeping PHP which a lot of people laughed at at the time because PHP gets like people look down their nose at it especially in Silicon Valley but they said no we're gonna do this we're gonna make it work and we're gonna go out to all the open-source communities and like try to help them and get our engineering teams working together and I think that also kind of provided a boost of energy so a lot of the language features that we have also seen recently not just the performance stuff but like namespacing improvements in the opcode cache to like not just be faster but also be less buggy stuff like that I think is a credit to that kind of push they put behind PHP as a project and that enhanced the ability to get more reuse going on the community and enabled projects like composer to be able to have get traction and the reason why and a PHP performance doc I'm raising this idea of code reuse it's because there's a bit of a kind of Maslow's hierarchy of needs in terms of how people approach technology where optimization is somewhere mid to upper on that triangle and on the base is kind of basically getting stuff working and getting it working reasonably well in your own little sandbox and as long as everyone is completely focused on doing that it's really hard to focus on harder performance issues because you don't have enough people who are using the same implementation to focus the the optimization work and you're too busy solving those other problems to be able to even spend your time working on optimization work so long story short PHP is no longer in a dark age I was trying to spread around the notion that PHP is experiencing a renaissance hashtag PHP renaissance so tweet tweet that out if you like what we're seeing here there's a lot of good things that are going on and and in particular you know PHP is the most popular language on the web by a long shot PHP runs more of the web than anything else and it doesn't get enough respect and we don't have enough pride in ourselves as developers that use that tool and the point is for a long time it was kind of in this iffy state and it was a bit touch-and-go but I think we can say now at this point there's a you know nothing is certain but I feel very confident that PHP is again on the rise it is experiencing renaissance and will continue to draw it be the most popular language on the web for many years to come and we can all take pride in that and take pride in our work so give yourself you know a pound on the chest or raise your fist in the air this PHP rocks so let's talk about speed that's why we're here this is a this is a PHP performance talk you feel the need the need for speed everyone knows this is very important as in the Dries note we talked about the experience web and a core part of the experience web is that it is very fast because your experience when you have to wait for things to happen is lame that's been scientifically proven and the our page ranking overlords at Google will now penalize your website if it is slow because they know that it provides a worse experience than a website that's fast and it also indicates like if you have a fast website you're taking yourself seriously we have to do a slow website you might just be some scammer malware guy so everyone needs speed and we are going to be talking about speed at the runtime layer which is just the PHP part of the speed equation this is not everything you need to to make your Drupal website fast I'm gonna repeat that several times as I don't want anyone to get overexcited about what we're gonna show here and think that it's just game over and you know all our work here is done no there's a lot of work to be done at every layer in the stack to make sure that Drupal is fast and responsive and that all of our applications are what they should be but we have some good news to deliver today at least on the runtime front so what is this not about this is not about caching right cash does rule everything around me it's caches all the way down but this what we're talking about today is what happens when you are not caching so to kind of reiterate what I said before in different terms you should still be caching you must cash you must cash multiple times at multiple layers in the stack in order to have good performance particularly for the front end because if you don't have you know most of the time when you're running a content-oriented site you at least have Drupal's page cache if not something higher performance like varnish in front of your website that is going to deliver the anonymous page view almost instantaneously as soon as the network request comes that comes in as fast as you can blink the response will come from the server but your end user right so you have to have that in place that's like table stakes now used to seem kind of magic but now if you don't have that you're behind the times but to the end user to your your of the person who really matters the person experiencing the web that doesn't deliver anything until the page renders in their browser and there is a whole field of front end performance optimization that I actually know less about than I should that's incredibly important for delivering good experiences because you can deliver a response from the server lickety-split but if it takes two to three seconds for it to parse the DOM and load the necessary derivative assets and get everything together before it can paint the page that's still a three second page load even if you responded in 20 milliseconds from from the server side so this this what we were talking about today just does only heightens the need for to be focused on front end performance because that is a make or break for the actual experience similarly this does not obliviate the need to be aware of your back end performance particularly on the sequel side like sequel is the king of nonlinear performance degradation right most of the time at the runtime layer if you get a bunch of traffic things will slow down kind of linearly just like it takes a certain amount of time and you have twice as many people your capacity it'll take roughly twice as long because people are just being cute and waiting at the database layer when things are going sideways that's when your website goes from being kind of responsive to totally dead in a heartbeat and that's because you can just you know send your disc you know this guy other locking issues can crop up there and what we're talking about now does not in any way ameliorate any of the risks of of sequel performance you need to optimize your queries you need to be aware of your slow queries if anything speeding up your PHP runtime just allows you to throw more queries at the database at the end of the day so it's very important to be aware that this is still key in delivering good site performance but this is about the PHP engine and let me say the new PHP has definitely got some muscle days to confuse awesome reference for everybody and and so this is what we did was we decided to do some benchmarking I wanted to submit this talk originally because I had seen some relatively lame benchmarking that would like say test different versions of PHP and hip-hop virtual machine on different systems and then claim like extremely unbelievably different results and then afterwards that and the comment thread of the blog post like oh yeah I realized on the second case engine X was just reverse proxy caching everything and yes that's why it's a thousand times faster because you're not actually exercising PHP at that point so we used our platform to do this test and so we have a high degree of confidence that you know it's literally the same container the same website the same installation and we're just swapping out the PHP engine in each case and I'll talk a little about what each of those tests was we used Panopoli as our site so it's not just a straight install of Drupal core Drupal 7 core is actually still very lean and it doesn't have a whole lot in it especially if you don't enable all the modules and so you know you it's it's fat Drupal 7 core if you don't do anything else to it is fast enough to make it not a great thing for benchmarking whereas Panopoli has about 70 modules that come enabled it's got a pretty thick set module stack of panels and all the other things you need to build a kind of neat modern site the site that we're exercising this on does not have a ton of content because we weren't interested in testing the database performance we're particularly interested in testing the PHP runtime the site that we tested this on has all caching disabled at all layers except for the APC opcode cache that's a core part of PHP and we just it with Apache Apache bench at that point because we're just going straight through and seeing how quickly the PHP engine can respond to uncached page requests and I'll show a little live demo of how we did this just so you can see so like I will toggle this site into hip-hop mode this is some unreleased stuff some day will come out and and then I need to do that because this is unreleased I need to do a quick restart of the container and I'm going to make sure that it's actually running hip-hop it is okay and then we would do something like I'm just going to do a hundred to make it quick but this is like the real-world test that we did and when we were doing the benchmark to spend a whole afternoon on this to kind of repeating it over and over to make sure that we were getting accurate results we weren't being getting fooled by anything and so in this case HHVM because it's just in time compiler takes a little while like the first few requests are slower because it's actually just in timing and then they get much faster and then like we would do something like okay let's go back to 5.3 and that takes a second and I know you can speed that up with a restart here I think not there yet there we go so now it's back on 5.3 and rerun the benchmark same site same thing you can notice that it's taking a little bit longer and that's that's what we did sort of with a little bit more rigor and more depth across the whole thing and so we'll talk about the results of this benchmark so PHP 5.3 with APC enabled and everything else tuned and dialed kind of you know the way the way that we have it so there's there's none of none there's no like gotcha in this in this in this setup in a long run of requests where everything has had time to warm up it averaged out to eleven point three eight requests per second and a 98th percent response time of 509 milliseconds and that's not that right half a second response time for an uncached page coming out of your Drupal site is not terrible and and and this is you know this is kind of the best you could do circa last year the end of last year with PHP 5.3 and APC well tuned well put together you know you could if you had different hardware or whatever maybe you could get slightly better or if you you tricked something else out on the on the infrastructure side you could do slightly better but this is a like a pretty good runtime pretty good setup and this is so this is the baseline for our benchmark is just just over 11 requests per second and just under 509 milliseconds PHP 5.5 we're we're planning on skipping PHP 5.4 because it mostly included new language features and not a lot of other stuff whereas PHP 5 it doesn't and it didn't really matter so much for Drupal 7 especially PHP Drupal 8 will acquire at least PHP 5.4 because of those language features but PHP 5.5 is out now so why not just jump the chump and get with the hero because it contains a totally rewritten opcode cache that remarkably and noticeably impacted performance this is the same exact site on the same exact infrastructure behind the same exact network stack and the same exact test and it's like a little bit almost 25 percent faster we were able to get 14.3 requests per second instead of 11.3 and the average response time was down 100 milliseconds that's not trivial that's a non-trivial improvement in performance and that is a good signal for us so and it's not that hard to run Drupal over under PHP 5.5 there's just some of those things you might have seen crop up as warnings or deprecation notices before you might have to pay more attention to but this is certainly an encouraging direction and you can actually use this right now in a lot of places out on the web PHP 5.5 is currently in wide distribution the last test that we did which was the Facebook's hip-hop version machine version 3.1 it's kind of badass we got 20 and in a sustained test we got 21.49 requests per second and our average response time per request was down another 100 milliseconds so this is if we go if we go back almost twice as fast as the current 5.3 state of the art and with the release of PHP they had this in 3.0 but 3.1 has some other bug fixes this is more or less as far as we can tell ready to run Drupal core out of the box it works with Panopoli that Panopoli site we went through and sort of dilly-dallyed with all the features everything works can make no guarantees as to the long tail of contrived because again there's it's a slightly different implementation it acquires you to kind of be on the more modern language patterns but there is a lot of I think it is realistic to be excited about running Drupal sites in hip-hop and having at least the PHP layer of your performance problem improved by something like 50 to 60 percent in the relatively near future David do you want to explain why that is well a lot of it is that hip-hop is as a just-in-time compiler is able to progressively optimize the actual execution of the code as those parts get busier and busier in the system they're able to do things like type inference that can then propagate through the code one of the worst things about the standard PHP runtime is that everything is a Z val which is this kind of it's to provide the loose typing in this at the C layer they have this kind of container that can hold any type at any point in time and then any time you're it's exchanging that around the PHP system it's it's trading all of that information around and it's possible for that to convert at any point in time into another type whereas on the HHVM another thing it does is with this type inference is it's able to work with much more native typing where possible where if something is actually an integer and has passed around as an integer and continues to be used as an integer at no point is there a kind of string equivalent tracks with it or an array container being held next to it as part of the data structure and then one of the other big optimizations and this has happened since the original compiled hip hop was that they completely changed the way that functions get called in the standard Zend runtime all functions go through a hash lookup map where any time a function gets defined it gets kind of pushed into this map and then anytime function gets called it tries to find the hash of it and then look up where to run that in the code and that's a layer of indirection that affects every single function call whereas ever since the compiled hip hop runtime they've actually made standard fully formed function calls where it's not being say where the name of the function is not being constructed out of strings and say the hook way but you're just calling a function name directly and they're having that work just natively and these kind of optimizations go a surprisingly long way toward improving the performance of PHP applications especially something like Drupal where you're you I don't know if you've ever dumped out a renderer array or something else but we pass a lot of data around in Drupal as we're building pages and building responses and we have a lot of modules all of which are loaded with plenty of functions and so you can easily see how given the way the native Zend engine works those tendencies in our architecture start to make PHP just at its raw computational level slower because it has to do a lot of this busy work essentially and the architecture of HHVM eliminates that busy work and as you can see it has some pretty stark results so these slides will be available online afterwards if you want to check it out you want to tweet it out that'd be awesome so here's like your basic speed graph which is awesome here's your scale graph which is also awesome in terms of how how many you can actually handle and this is what I'm talking about when I say PHP Renaissance right this is this is exciting stuff this is this is going to help us build stronger and better websites that are more appealing to people because they provide a better experience by being able to respond more quickly to requests if we think about things we want to do with Drupal 8 where we want to be able to legitimately run restful services that are going to be like you're going to have a like your mobile even not even a mobile website your mobile app on here could be talking to Drupal that restful service needs to be able to respond very quickly and a fast runtime is a really key component to being able to deliver a fast response to a restful request and so it starts to make Drupal and PHP more and more legitimate in filling this role in sort of the overarching architecture of the web and one area that we haven't gotten into in any of these benchmarks is that HHVM has a bit more controversially introduced a supplemental language called hack which allows having this kind of typing and several other language features be more strictly defined and then be able to run alongside and integrated with standard PHP applications where PHP can call hack and hack can call PHP without a lot of trouble and that opens up optimization paths that are considerably more sensible toward projects like Drupal and contrib then say writing a C extension to the language itself yeah exactly like better than Rasmus's suggestion and the other thing is that you know we're excited about this obviously but other people are already implementing this and making this possible so the cloud software platform company Heroku recently relaunched all their PHP support and the default is that you get this like they don't want you to run the old version of PHP they want everyone who's using them and building on PHP to use only HHVM and hack because it's just they consider that to be let's just make that the new baseline for how we do PHP development and they have a broad appeal I would expect the other platformers in service the generic pass providers that offer PHP run times do more along those lines and I expect to see more things from core framework groups like symphony taking advantage of these features and so forth so it's really you know again to reiterate it's an exciting time to be a PHP developer our a rising tide is lifting all of our boats and that's a very very good thing and it's been a long time coming I gotta say but I want to again close with the reminder that performance is a full stack challenge you can't just swap out the engine and expect everything else to to to work better you have to be aware and cognizant of each layer of the performance problem and so you know I start with you can start anywhere but actually it's the weirdest place to start is in the middle because like if your front end performance is terrible and the web page that you're delivering takes a million years to render it really doesn't matter how fast the user gets that page because they're in browser experience is going to be poor and their their web experience will be poor and they won't like your website likewise if your database is slow as balls then your it doesn't really matter how how fast you can send requests to it because it's going to be slow getting them back out and you're not going to be able to deliver a good experience even if your front end is optimized so you really have to have this trifecta of an optimized front end that renders quickly in the browser and gives a snappy experience and a good database back end that's like well-tuned and not abused and then you can put a great php engine runtime in the middle and then you're really totally cooking all right so that's actually all of the the presentation we have but we're happy to take questions on performance on our benchmarks on these other things if you want to do questions please just come up and start a line right here hi mr son about so uh you mentioned you that benchmark was penopoly i'm guessing it was say like the front page anonymous user right uh front page on anonymous user but with all caching disabled okay so do we know how many i o calls were involved in that page um not off the top of my head but it's non-trivial it's like something like a hundred ish queries okay it'd be great like when you publish that if we had that information so we could see because i feel like maybe i'm a little skeptical whether that's representative like that two times improvement whether that's representative of like what most drupal sites will actually do because i think they will probably have more i o calls um yeah that's that's an excellent point so the the the uh the caveat on the benchmark is this is a i what i what i'm warranting is a 2x improvement in the php runtime portion of the equation um and uh and not necessarily a two times improvement in your overall site performance it may have to be actually bigger than 2x improvement given the the i o overhead that's involved in there too to be able to cut the request time in half yeah so so we'll but yes uh we'll we'll we'll follow up with like a blog post and i will find that information because it's not that hard to get yeah have you run your benchmark on php ng no we wanted to do that um but unfortunately we weren't able to get uh a build up and in place in time to test it last week when we were sort of pulling together all the numbers finally but that's we didn't mention that before but the php ng is another exciting innovation coming out of the same space in the php project i don't know if you want to talk about it it's also jet-based not really um but it is um so core developer sorry um so php ng is basically a branch of the php runtime that attempts to simplify and make simplify a lot of the internal data structure such as the zed vals that you mentioned um within php uh to basically improve performance and reduce memory use um the inter certainly the bench a little bit of benchmarking i've done suggests it's quite a bit better but i'm interested since you guys have controlled this much better i'm just hoping you've had numbers we we actually that was in our original outline when we submitted the talk that was like bullet that was like the fourth bullet point that we wanted to have and we just were not unfortunately able to get uh a you know we only had a one full day to pull all the benchmarks together and we ran into enough like little snags and getting the a build that we were sure was was correct together that we didn't do it but i would love to be able to follow up with that sure um and it is it is a very cool project and so that uh correct me wrong what the idea is php ng is sort of this alternate now but if it works out really well then people get behind it that could become a default for like php six pretty much yeah um i think the hope is assuming it all works out it'll get merged into master and then the major version number will get incremented and then a whole bunch of previously dead rfcs will become alive excellent um other questions yeah come on up you can you guys can make a little line if you want have you guys um are you planning to do any uh Drupal 8 benchmarks comparing uh yeah i would love to do a Drupal 8 benchmark i would probably want to wait a little longer because i know but to be honest that's kind of a sensitive topic right now and um and it's not fair to look at something that's still like clearly in an alpha state and benchmark and say ah this is slow because there's a like part of what you get through when you get more people with eyes on things is optimizations like everything we talked about is really optimization inside php core my strong sense is that Drupal 8 has another has like a similar like road of optimizations between now and the release candidates at least um to go through to where you know you could make a benchmark however it wouldn't be a bad idea to if we could get we mean we have some of the stuff scripted out we could get it together to start doing some benchmarks and then after each release rerun them and just see if anything what if anything has changed thanks sure any other questions all right is any he's coming oh you're coming okay so you talked a little bit about php 5 5's um warnings yes um is there a good list and potential patch available for that i mean obviously triple seven it would have to be something that we're somewhere to have to add on but if you wanted to eliminate those warnings how i mean how bad is it so so the the i'm not gonna say that it's not a problem because it is um but it's not uh the sort of thing where you uh necessarily have to like think about are you are you pulling something out yeah this is just like the the short list of like five five backward and compatible changes but just to give a kind of idea of like the kind of things that people encounter a lot of it's stuff that has been long deprecated and should have been removed a long time ago like you i don't think that magic quotes were ever supposed to be used in drew bull applications they've always been awful um safe mode has been uh is more of a runtime configuration thing for hosting providers that was popular on crappy shared hosts and uh almost all of these have a much better alternative to them uh or should not be affecting code that was written with best practices even as of five three yeah the the what i would say is by um by volume in terms of we're gonna take the census of all the warnings that we see from we even actually see this sometimes with people trying to in five three it's the things like you know an array that's being referenced without a proper index and other stuff like that which is honestly a signal that the code itself is doing something improper because it's trying to reference a very or referencing a variable that that uh that doesn't exist yet um those are the most common ones they're not um signs that like the uh it's gonna fall over but they are things that would need to be fixed the problem is that there's not a way to fix them in one place because what they are is places in contrib especially where the contrib author is just you know done their work and it works well enough for them but there's a little bit of uh there's the potential to reference a variable that is is unassigned or reference an array with an invalid key which previously in versions of php five two earlier would just be null um it would just say oh i don't know what you're talking about null um and some people wrote code that depended on that but that's not really a great it's not good to to make an assumption you could ask for something like you should know when you're asking for something if it's gonna exist or not so i guess as a follow-up i mean how helpful would it be if everybody here started using php five five because of that 10 percent oh speed difference and started filing bug reports against all of that for seven and for eight yeah 100 percent 100 percent so i um this is like one of the ways i think we will be able to help contribute to this is by hopefully making this the ability to experiment with this stuff more and more easily available to people but if you have control of your own php version now i would definitely like you might it might not it might be a very small amount of work and even just getting a php five five is a non-trivial bump in performance that 20 percent is not something to sneeze at that's a real that's a real number that like if you're looking like when you sit down and you do a performance optimization or something like a 20 percent win you can get just like that is solid goal so i really like one of the takeaways from this is be excited for the future but be ambitious for the now because you can get a faster run time if you get your site up on five five also a drupal seven core should be already running fine with five five yeah the issue in drupal seven has just some contrived modules so you obviously ran these tests on drupal seven with drupal six still having some remnants of php four how ready is it to be run on hip hop i would i might i don't know but my guess would be not very there's uh there's at least one uh regular expression uh that's i believe still in drupal six core with the deprecated regular expression support uh it's not um it's not the pearl compatible eric eric yes and i don't think that's ever been written for hip hop so at least that line of code would probably just cause a fatal error uh not massively hard to replace or avoid if you can if you need to but i would say if you're working on performance for your project then um drupal six is definitely gonna hold you down but if you want to try i mean it might not be that hard like like i said i don't know it's just a guess um have you run any of these tests over sustained periods like hours or multiple um multiple restarts you know incubations of the php run time over a long period time for things like you know degradation over time or stuff like that and also did you track memory usage or memory um consumption because honestly for my systems the memory usage is my limiting factor not cpu or even code performance um you know memory right now is the most expensive resource for me to acquire interesting um so uh the the answer is do we try this over a long period of time no we we we tried it with uh the longest one i ran was like 10 000 requests um so that's a sustained garage that lasts that lasted like 15 minutes um and the thing is at that point you know uh if and given our knowledge of the system i'm not trying to load test this this is still just the same like concurrency level five so this is not like let's keep adding more people to see where the the system breaks down it wasn't a stress test this is just a benchmark and my my feeling is or and my understanding my experience is if something holds up and is steady for like 10 to 15 minutes i mean it's a computer it's going to do the same thing the next 15 minutes the next 15 minutes after that what would change it is if like you doubled the number of people or something else happened but there's no um there are no known issues with like sort of memory leakage or other runaway things i did not check the memory utilization values for these so i don't have that that's another thing we can consider throwing in as well as the mark's request for the back end queries um that were resulting from this um i would be curious though if you're if you feel like you're in a memory constrained environment you should work with whatever wherever you're memory from because that shit is getting cheaper and really fast memory is the new disk and it's what everybody else says so you should be able to get more memory with less money yeah a lot of the what we benchmarked was influenced by the fact that we're cpu constrained for our application servers yeah okay hey thanks for the talk that was great um optimizing the php layer is a great step but you also mentioned the database layer and um cache and other so in your experience having a great hosting environment and where you when you deal with triple size that are non-trivial that have complex structure a whole bunch of nodes what are the you know the top five bottlenecks that you see that are not i mean that maybe the whole conversion to 5.5 or hip hop wouldn't make a dent what what are the typical things that we are doing to explain wrong so the the biggest things are with larger sites is when you have a lot of data it's relatively easy to click around and configure a view that will make your database server very unhappy because views is kind of just doing the best it can to give you what you the things you need but it's not a dba and when you have a few hundred nodes it'll actually almost always work fine but when you have like a hundred thousand or a million nodes that may no longer be the case so that's that's common the other thing that's common is um you know again harkening back to the driss note we are increasingly in this world of integrating extra external services and we really need to develop better practices around how and when and we do that because one of the things you know larger sites typically do integrate many external services one of the things to be aware of is because php is a blocking language anytime you attempt to integrate an external service you create the potential for that external service to hold up a page request hold up a php thread and so a less thoughtful external service implementation can sometimes become a problem for sites and then the the the pure pure front and performance there's other like weird drupal gotchas that come along to me though there's not really like any one thing it's usually the first thing is are you bound on your database if so then that's the only thing that matters to work on and until you're no longer stuck until your database is is happy it doesn't make a ton of sense to focus anywhere else unless you also have very poor front end performance because you can cache to cover that and then work on the front end and and get that resolved that's kind of the general gist of it i would say thanks for the update uh do can you share your thoughts on both php is a long-running process and drupal as a long-running process on php is a long-running process so do you mean php is a long-running process as a like an active a single php script or like an fpm um yeah more like an fpm so fpm is perfectly fine as a long-running process in terms of it being a supervisor of php processes that are then running scripts or web or you know website traffic uh none of the actual requests that are going through the php runtime or long running usually for for things with fpm and uh i believe fpm even has a configurable life cycle for the sub processes that it's managing in the same way that apache can with mod php for discarding it in case there's any kind of memory leak in that which often there is some um for running php itself like where you've written written a dot php file and you're executing it in some sort of long running capacity i don't know if i would recommend that right now and and and how about drupal on top of all of that uh same thing is true for drupal that uh i would say that um the closest you should get to a long-running process with drupal is where you have something that is maybe queuing up things and then there's a worker that comes along during cron and is working its way through a handful of queue items but in a way that is not necessarily long running like not necessarily working its way through the whole queue maybe capping it at some number of items or some duration of time before it exits and then picks it up in another run of the script okay great thanks yep well thanks for the talk is certainly entertaining um one of the things we run into is that it's really easy to scale sites out horizontally when you're dealing with a larger number of requests because uh you just throw a bunch of servers and cpu cores and so on but then sometimes when you have content editors hitting a site or you're just doing local development we've all seen scenarios where you've got like one out of your 16 cores pegged with cpu doing all of the compute resources and it's just not very efficient as far as trying to thread anything at all and i know like on the drupal and php app side of things you know we're not writing a multi-threaded application but is there anything on the hhvm side which tries to make better use of sort of the multi-core architectures that we have i i'm not currently aware of anything that actually distributes a single request to multiple cores but i could be wrong so yeah as far as like the benchmarks you've got right now you're basically going to have the same results on you know a two core versus an eight core system with one request at a time uh yeah but so for a single request that's true um uh but obviously you uh most websites are sure yeah yeah concurrent requests but yeah there's not not at this moment anything that uh breaks up uh and and takes a single request across multiple cores that that we're aware of um it's certainly you know if you if you're seeing that type of process where the cpu really is your bottleneck just speeding the runtime is going to have a a good effect on that and um uh yeah having a single page request take it to a hundred percent of one core could be could be bad yes yes if you make a 50 percent faster than it's you know 50 percent of a core hopefully hhvm has been optimizing the opposite direction though which is uh to be able to make one core more effectively able to juggle multiple requests through um async primitives hey so uh you guys mentioned that php is a blocking language knowing that node j s is coming up and that php has things like react coming along to make it non-blocking i o do you guys have plans to investigate anything like that for performance or have you already or hhvm does have non-blocking i o oh does it yeah did you want to test on that or we that we were we were not testing using any of it but it has apis for that okay i personally think node j s is a terrible language yeah yeah it's the non-blocking so we're in a world where where every server we're getting is getting more dense in the core for in the in terms of the core distribution and the job of a runtime for an application is just is to distribute that workload out to as many cores as possible to take advantage of that horizontal scale in modern systems and the basic node j s philosophy is let's pack everything possible into one core one thread uh that is event oriented and if you want to distribute it out to multiple cores they have some hacky ways to run multiple processes on the system and the distribute requests out to them that we've we've actually not find found reliable even though we use node j s for a few of the things that pantheon and i just don't like that at all and um and then of course it's being built on top of v8 which is a google managed project and google does not consider v8 to be really a server-centric just-in-time system so we've seen bugs in both node j s and v8 in terms of things like memory leaks for long running processes which is just how event-oriented applications like that operate so i i don't think it's that great i've i've even written code in that even in coffee script that's supposed to make some of the coding constructs simpler so you don't end with a mess of callbacks because i think it was apt when someone said callbacks are the new go-tos and it's just not it's hard to create maintainable code on a large scale with the way that node j s operates uh i was gonna say does that give you trepidation then for projects like react which are supported by symphony so you could kind of see them bubble up in drupal 8 which would make php kind of that same form as node j s with lots of callbacks um i think callbacks are terrible i and i've done twisted programming too with callbacks and i ultimately think that the first language that really handles things well in terms of looking like you're writing blocking programming and has things being properly juggled by an event handler at the core of the runtime in a way transparent to the actual developer is the thing that's going to take over and really bring event-oriented coding to the masses because one of the most expensive resources on projects is developer time and it sucks to have a language that developer productivity takes a huge hit for uh when uh they're coding in the normal way that that language forces them to operate thank you any more for any more all right cool well thank you guys for coming thanks for attending hopefully tweeting about the php renaissance and uh let's go ahead and make the web faster