Rasmus Lerdorf: Simple Is Hard - DrupalCon 2008 Key Note

The talk is about how we use php today vs. how Rasmus thought it would be used. PHP was all about separating your biz logic from your presentation layer. So that you don't have to recompile your code when you change a sql query - two levels of the presentation layer - the design / html / css and the sql.  He never took a CS course in his life, didn't know how to write a parser - so he wrote php in a way that would make it easy to parse.

Slides for this talk: http://talks.php.net/show/drupal08

Back in '95 he could make a change to php and email everyone using - had logins to most of their servers even, so he could fix their code if the change broke it - but he can't do that today :) so we are stuck with a lot of old version - which is also a problem for Drupal - people aren't upgrading.

We are writing more and more complex code in php directly and it hurts Performance, Latency, and Scalability - it's slowing things down, and complexity also impacts Security - even with frameworks - you have people writing to frameworks who still introduce secuirty problems - with great ease Rasmus found security flaws in every open source cms system (Drupal has fixed the one's he's reported).

PHP is rarely the bottleneck - 80 to 90% is front end - see yslow - rendering issues, javascript (don't have js in the head, move it to the bottom). Yslow is an amazing tool - if you aren't using it you should!

Because of all the problems scalling twitter, Rasmus decided to benchmark Laconica (behind identi.ca) - with php 5.3 you can do 20 requests per second (based on his laptop - not server class hardware) but still 20/s is poor. By adding an op-code cache and you get 46 reqeusts per second with a faster response time - but still not good enough... so he looked at the system calls using strace with apache and he looks at all the system calls for one request. There are 153 stat calls, and anything that touches the disk is slow. By using relative paths the system has to find the full path, and check to make sure there are no symlinks... the realpath calls are cached, but the misses aren't cached - so include once or require once - if you miss the path it's very expensive. Whenever you have some relative to the current directory ALWAYS use include path - this cut the stat calls down to 26 (tho this didn't show massive gains b/c he was using vmware which does aggresive caching). Also, you can turn off stats in APC. This will lead to huge gains on older linux systems <=2.4

Check your include hierachy - so that files that include other fiiles don't in turn try to include previously included files - it's a waste and redundant. You should be able to manage your code such that you only require files once.

Then he used valgrind and callgrind with apache; the output of call grind shows at the c level what's happening. the hand off from apache to php - this is done as a sanity check ot ensure there wasn't a back end call like an ldap call, that ius taking up all the cpu time. Most of the time Laconica is executing php - so the sanity check passed.

The next step is to use xdebug and sanity check at the php level.     The more complex the code the more confusing the output is, but it gives you good insight into where you are spending your processing time. He noticed functions calling xml writer functions that were taking a fair amount of processing time. Turns out Laconica uses xml writer for all it's output. They build up all their html output by calling into xml writer. Which is "kinda cool" he said, but bloody slow. Rasmus tweaked only the page header (not all Laconica code) and improved the performance; so it's a nice abstraction layer but it's a performance hog.  They had an abstraction laywer between the app and the browser, and the app and the back end - and both these had a cost the developer was unaware of - you should know what the cost is.

It makes a huge difference how you write your code... it's great that your code is abstracted, but at what cost? and his cleaned up code was still abstracted - it does only what it needs to do, no more, no less.

then he ran callgrind again - and he found that his code wasn't notice clean - and even though he wasn't outputing notices, php was still building the notice string and then just throwing it out - it was costing 10% of the work. you should make sure your code isn't throwing notices. he fixed the error (he didn't set a local time zone) and he gained 20 requests / second.


Static PHP baseline - simple PHP hello world scrpt - .01 seconds response time, 606 trans/sec. (With an opcode cache) which is almost as fast as static html (611 trans/second) so the only thing slowing you down is the code YOU write.

Rasmus wrote a hello world test in 9 of frameworks.

CAKE PHP was .19 response and 25.88 trans/sec (just a simple hello world script in cake!). The include tree is HUGE. The tree is a trade off of what people need v.s performance.

He ran the same "hello world" test with Symphony, Agavi, Zend Framework (.04 response time, 130 trans/second). The zend framework has TONS of require once that aren't needed (per the above note). Below a certain entry point the user of a framework isn't going to be dealing with files - you should be able to clean it up.

CodeIgniter (some people don't consider it a framework - but Rasmus likes it b/c it's simple) .03 and 300.
Drupal 6.4 response time .10 response time, 51.37 transactions/sec. NOTE drupal does a lot more then the other frameworks... so it's not apples to apples - he wrote a hello world module. But there are still a ton of "require once" that don't need to be in there... most can be turned into just include (not include once). Which would really help performance. But overall it's not TOO bad.

How to speed up drupal? It's a framework, but it's targeted at CMS type problems. Drupal 7 will be in php 5.2, which will help. Get rid of your "time" calls - b/c this goes out to the system. in php 5.2 there is a way to avoid the system calls (there are 107 of these in drupal 7 that calls time directly) $server_request_time. The other suggestion is looking at some sort of code geneartion - the thing that slows us down is that there is code we run that we aren't using - so if we read the config on each request and can more intellegently choose what code is run - getting rid of some runtime checks...might require a c extension, i.e. common.inc that could be optional for high performance sites. This would make Yahoo and other enterprise clients more happy with using drupal. You nee to figure out ways of not repeating runtime requests.

yahoo has a lot of c extensions - so yes, yahoo is written in php it's the presentation layer that's in php. same with facebook, the biz logic is written in c. no scripitng language is fast enough...

if we could take all the web apps in the world and speed them up by 100, we could have a lot less data centers and servers - we used to count cycles when writing c code, and no one tracks that level today. Green computing - we need to save the trees (and kittens) by writing cleaner code - we'd need fewer servers...

Xdebug Profiling: http:/xdebug.org/docs/profiler
YSlow: http://developer.yahoo.com/yslow

Questions (note: rasmus didn't repeat the questions so it was hard to hear what people were asking):

Is there a real cost to do require once more then once? YES, there is a real path call that has to be done, and this is cached - so the real cost is on a miss - when the include path setting is incorrect - it's traumatic, terrible. The cost is when the server config isn't correct - when the config is great it's not a problem.

How does ruby perform? It's not the absolute slowest (it's the second slowest - if he would have included it on this list).

Where is PHP going? People always ask me this.. it's going where the web is going - it's written by devs for devs... but... unicode is a big problem we need to solve. Developers want to work on cool, sexy code tho - features people will notice, they don't want ot make extensions unicode safe. "if you tell me where the web will be in three years, i'll tell you where php is going"

security of php? whats the status? there hasn't been a remotely exploitable security hole in over 6 years. it's not like putting sendmail on your sever. it's all about making it easier for application writers to write secure code. we get a lot of bugtrack posts about safe mode (which was a bad idea - and won't be part of php 6). 90% of security things you read about on bugtrack is about safe mode. there isn't a php security issue - there is an issue with php devs not understanding secuirty - which is a direct result of it being more approachable as a language. cross site scripting is a big thing for web sites.

Not really part of the presentation - but check this out:
Search Monkey: http://developer.yahoo.com/searchmonkey (semantic web). This is part of the yahoo search results. PHP + XSLT