Beat the Deviltowards a Drupal performance benchmark
http://drupal.org/user/770300@rodricelshttp://drupal.org/user/8859@perusiohttp://drupal.org/user/39078@NITEMAN_es
Well kill a lot of sacred           cows
the murder weapon      will be  Occams razor
which amounts to theprinciple of least effort
laziness is good
hopefully in the end youll       be puzzled
good things happen to puzzled people who       obsess
simplest laziest easiest
performance is for     everyone
do you haveperformance issues?
system thinking   http://www.flickr.com/photos/irisheyes/148134965/sizes/o/in/photostream/
mathematics is for everyone
request per second         vsseconds per request
MTTR  Mean Time To    Recovery        vs      MTBFMean Time Between      Failure
do you monitor live      system  performance?
live monitoring toolsMuninCacti
drupal accesslog tablehas tons of useful data
beware the logslogstash / graylog  aggregate them
economics      costs perrequest/volume/peek  operational costsReturn On Investment
were talking about $peed$peed = cost_effective_performance
slowness   downtime   operationscosts you money
its not thetools you haveits the use youmake of them
have you benchmarked     your Drupal?
complex is easy and fragilesimple is hard and resilient  Keep It Simple Stupid
Know your stack   Know your targetsMonitor your performance
find where the problems aredont fix things that arent broken         the worse the first         one change a time        ...
dissecting  frontend vs backend         backend    static vs dynamic        dynamicprocessing vs data gather
beyond development &     operationsgood developers are those that take   all aspects in consideration
test systemskeep everything as close as  possible to production
test systems     take advantage ofconfiguration management  to reproduce your live       infrastructure
test systems   some software has its   performance directlytied to the number of cores           and/or    the amount of RAM
sacred cow of frontendCDN (expiration logic)cloud servers
frontend vs backendnumber of req. / parallelizationblocking eventsdata side: DNS resolutiondata side: download timedata si...
frontend vs backend tools            Firebug         Chrome tools     Google Speed Tracer             YslowWeb services [*...
sacred cow of backendload balancing: how? failover strategy?more webheads: cache consistency?another server: what for?
backend: static vs dynamic  anonymous vs registered cacheable vs non cacheable
HTTP benchmarking tools             ab          Jmeter         Httperf            wrk         Gatling        TCP copy
sacred cow of PHPHipHop (hacked libs)PHP Extensions (C / PECL)
sacred cow of PHP                                APC Tuning       profile, profile, profile and profile  upgrading PHP ver...
dynamicprocessing vs data gather             locks      difficult to dissect             devel
benchmarking / profiling PHP           Xdebug          Webgrind           Xhprof dont even try without an       opcode cac...
sacred cow of databases              NoSQL              denormalization              sharding        http://www.flickr.com...
sacred cow of databasesNoSQL             => helps with writesdenormalization   => helps with HUGE DBssharding          => ...
MySQL Tune & Benchmarkingtoolshttps://tools.percona.com/Percona toolkit [*] (formerly maat-kit)tcpdump + Percona toolkitLo...
root hardware causes      network & DNS play a role static content depends mainly on I/Odynamic content (php) depends on C...
extra balls:Drupal known issues (DB): Watchdog, sessions,accesslog... history...Please do stress, load & stability tests r...
This is our way, what is         yours?(no cows were harmed in the making of this              presentation)
¿Questions?  Pablo Picasso [speaking of computers]:"But they are useless. They can only give you                 answers."
Beat the devil: towards a Drupal performance benchmark
Beat the devil: towards a Drupal performance benchmark
Upcoming SlideShare
Loading in …5
×

Beat the devil: towards a Drupal performance benchmark

3,461 views

Published on

Slides from the session we (@perusio @rodricels @NITEMAN_es) gave on Drupal Developer Days Barcelona 2012:
http://barcelona2012.drupaldays.org/sessions/beat-devil-towards-drupal-performance-benchmark

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Beat the devil: towards a Drupal performance benchmark

  1. 1. Beat the Deviltowards a Drupal performance benchmark
  2. 2. http://drupal.org/user/770300@rodricelshttp://drupal.org/user/8859@perusiohttp://drupal.org/user/39078@NITEMAN_es
  3. 3. Well kill a lot of sacred cows
  4. 4. the murder weapon will be Occams razor
  5. 5. which amounts to theprinciple of least effort
  6. 6. laziness is good
  7. 7. hopefully in the end youll be puzzled
  8. 8. good things happen to puzzled people who obsess
  9. 9. simplest laziest easiest
  10. 10. performance is for everyone
  11. 11. do you haveperformance issues?
  12. 12. system thinking http://www.flickr.com/photos/irisheyes/148134965/sizes/o/in/photostream/
  13. 13. mathematics is for everyone
  14. 14. request per second vsseconds per request
  15. 15. MTTR Mean Time To Recovery vs MTBFMean Time Between Failure
  16. 16. do you monitor live system performance?
  17. 17. live monitoring toolsMuninCacti
  18. 18. drupal accesslog tablehas tons of useful data
  19. 19. beware the logslogstash / graylog aggregate them
  20. 20. economics costs perrequest/volume/peek operational costsReturn On Investment
  21. 21. were talking about $peed$peed = cost_effective_performance
  22. 22. slowness downtime operationscosts you money
  23. 23. its not thetools you haveits the use youmake of them
  24. 24. have you benchmarked your Drupal?
  25. 25. complex is easy and fragilesimple is hard and resilient Keep It Simple Stupid
  26. 26. Know your stack Know your targetsMonitor your performance
  27. 27. find where the problems aredont fix things that arent broken the worse the first one change a time & keep a log of your actions
  28. 28. dissecting frontend vs backend backend static vs dynamic dynamicprocessing vs data gather
  29. 29. beyond development & operationsgood developers are those that take all aspects in consideration
  30. 30. test systemskeep everything as close as possible to production
  31. 31. test systems take advantage ofconfiguration management to reproduce your live infrastructure
  32. 32. test systems some software has its performance directlytied to the number of cores and/or the amount of RAM
  33. 33. sacred cow of frontendCDN (expiration logic)cloud servers
  34. 34. frontend vs backendnumber of req. / parallelizationblocking eventsdata side: DNS resolutiondata side: download timedata side: size / weightorder matters
  35. 35. frontend vs backend tools Firebug Chrome tools Google Speed Tracer YslowWeb services [*] [*] [*] [*]
  36. 36. sacred cow of backendload balancing: how? failover strategy?more webheads: cache consistency?another server: what for?
  37. 37. backend: static vs dynamic anonymous vs registered cacheable vs non cacheable
  38. 38. HTTP benchmarking tools ab Jmeter Httperf wrk Gatling TCP copy
  39. 39. sacred cow of PHPHipHop (hacked libs)PHP Extensions (C / PECL)
  40. 40. sacred cow of PHP APC Tuning profile, profile, profile and profile upgrading PHP version (if youre brave)
  41. 41. dynamicprocessing vs data gather locks difficult to dissect devel
  42. 42. benchmarking / profiling PHP Xdebug Webgrind Xhprof dont even try without an opcode cache & remember the hard disk
  43. 43. sacred cow of databases NoSQL denormalization sharding http://www.flickr.com/photos/rebeccaselah/3942904359/sizes/l/in/photostream/
  44. 44. sacred cow of databasesNoSQL => helps with writesdenormalization => helps with HUGE DBssharding => helps with Big DBs
  45. 45. MySQL Tune & Benchmarkingtoolshttps://tools.percona.com/Percona toolkit [*] (formerly maat-kit)tcpdump + Percona toolkitLogs are vital!Every engine has strongs & weakness Better on bare metal!
  46. 46. root hardware causes network & DNS play a role static content depends mainly on I/Odynamic content (php) depends on CPUdatabase server mainly depends on RAM
  47. 47. extra balls:Drupal known issues (DB): Watchdog, sessions,accesslog... history...Please do stress, load & stability tests regularlyin your live system
  48. 48. This is our way, what is yours?(no cows were harmed in the making of this presentation)
  49. 49. ¿Questions? Pablo Picasso [speaking of computers]:"But they are useless. They can only give you answers."

×