1. Scaling rails with performance in mind from the beginningTom Caspytom@tikalk.comun.orthodoxgeek.co.il
2. Performance - what itactually iswell, code which does what itssupposed to, and doesnt do it asslow as rails 3.0s boot time.in every part of a projects lifecycle, the way wetreat performance is very different.
3. When youre young
4. When youre young and naivewhen you start with a project, and its still smallon traffic, write naive code!
5. Do TDD! To avoid this :)
6. Write short and concise code
7. Dont bother with prematureoptimization
8. (when you prematurely optimize, thishappens)
9. READ!prepare for growth, because youre optimisticand all that. make sure youll know what to dowhen shit gets real.
10. be naive but not TOO naive, thoughthere are some things which just scream - dontdo this! its gonna suck, BAD!the n+1 query issue is a good example of toonaive code.
11. The controller
12. The view
13. The view
14. The problemwe have an array of users, and when we iterateover that array we reach for profile_image andfor posts, which triggers two queries to the DBfor each user. ending up with 2n+1 queries, nbeing number of usersThe solutionActiveRecords includes prefetches the extraqueries, so they turn into two queries, insteadof 2n queries
15. The new controllernow there are only 3 queries, instead for 2n+1 (n being the amount of users)note that this might not be the right thing to do in larger scale projects. youmight want to cache the profile image in redis, for instance, and completelyavoid bringing in the profile_image object from the database.
16. The importance of TDDOne of the roles I took upon arriving to FTBProis kickstarting and leading the move to TDD, wealso wrote a bunch of specs for our legacycode. Difference was incredible.
17. Daily deploys(instead of weekly deploys)
18. New codes clean and awesome
19. More focus on featuresbecause codes fairly covered, theres lessissues that come up in production (less beingrelative, yeah?)
20. Upgrading made easywe moved from rails 3.0 to 3.2 within twoweeks. mostly because a vast majority of theissues were discovered in tests.
21. But this talk is about performance!When writing TDD, your code will be faster.● TDD forces you to write short and atomic methods● we try to make these methods fast because we hate slow specs :)● code doesnt fail on production, because if it fails, we know about it before deployment.● no long-running methods, because theyre short and concise
22. More performance specific TDDusing rspec you can test the time a methodtakes to run, set a threshold above which thespec fails!when using the bullet gem, you can set a limiton number of queries you allow a controller torun.Do benchmarks and performance tests
23. original code- writtenwithout tests
24. Rewrite - thespecs
25. the actual codedoes exactly thesame thing, but itsmuch shorter, andmuch morereadable, becauseits TDD, everymethod does onlyone thing, and istested well.
26. Conclusion - do TDD!● code is shorter● easier to maintain● its tested so when it breaks we know it before its on production● when we need to refactor or change it, we can be fairly certain it will still work as intended because of the tests.
27. When youre growing
28. Now, you start growing, and thereare growing pains● because youve written TDD, when you optimize, youre not going to break anything (or are, but will see it when tests run)● your code is short and concise, so optimizing it will be easy● because you didnt optimize anything, youll feel what needs to be optimized first (using newrelic and the such)● again, dont optimize whats easy to optimize, optimize the parts which start causing pain.
29. How to get the feelin`
31. shows you whats hurting the most
32. And gives you a breakdown of that
33. Google Analytics
34. Browse your site (that crazy!!)
35. Listen to usersthey may come and complain, and may just goaway. use google analytics to look for pageswith unusually high bounce rate.
36. Custom toolsstatsd and graphite can be quite handy
37. Real life examplein FTBPro, we have a scoretable for each league, it getsdaily(ish) updated from anexternal source.We noticed in Newrelic that theleague page took a long time toload. A short investigationpointed to the table, which ledto a tiny change in the code.
40. What? wait! it looks the same!well, almost. there are two changes - one is atiny change in variable names to make codemore readable.the second change is we used a cachingmechanism to bring in the team (called Subjectin our code) without making any queries.the difference was HUGE. time to build thetable when cache was cold went down from 7seconds to 0.5 seconds.
41. So - what have we done exactly?● we removed an n+1 query not by including stuff, but by avoiding the query altogether● we used a caching mechanism for teams, which takes the teams nick (Barcelona can be referred to as barca, or F.C. Barcelona) and returns the cached team.● used that cache to speed up a very painful part of the site by a lot.● and yes, of course the view is cached so the rebuild of the table only happens once a day.
42. When you need to refactor, orrewrite.refactoring is taking code and changing it, whilerewriting is starting from scratch.different reasons for refactoring or rewriting● code is causing performance issues● code is too clumsy, and makes debugging very hard and costly● code just looks horrid● Tom said so.But when do we rewrite and when is it enoughjust to refactor?
43. When to refactor● code is generally ok, maintainable and worth keeping● small changes would get the desired result easily● code is well covered with specs● were too damn lazy to rewrite it all (yes, its a valid reason, lazy programmers create short code)
44. When should we just throw it awayand rewrite.● if the maintaining the code costs more than rewriting it, rewrite, and do it well!● if the code does not have any test coverage and is untestable.● when code looks like the Flying Spaghetti Monster● when it was written by Avi Tzurel :)make sure that new code is good, if you rewriteshit code to new shit code, youve donenothing!
45. A little bit about queuesDelayedJob, Resque, Sidekiq, they all gotstrange names with typos in them. They allsave us from hell.
46. Move long running stuff to thebackground!Lets talk about user registration - a user comesto the site, signs in with facebook, we get hisimage, his facebook friends, etc. It takes awhile, even a long while.
47. Put it aside!Calculating all that stuff is long.This doesnt have to be that way. We really onlyneed to save the users name, facebook details,and thats it. Well do the rest in thebackground, using one of the queueingmechanisms Ruby has to offer us. This willallow us to give the user a better, fasterexperience.
48. Starting to get seriously huge(ok, maybe this isnt a good image)
49. Hitting large scaleQ - when do you know youve hit large scale?A - when your servers crash daily.now, when youve reached that, you know youneed to do some really drastic stuff to adjust toyour new position.
50. A quick detour to the land of DevOps● handling large scale requires a lot of resources, and managing these resources effectively.● cloud services such as Amazon AWS give companies some simple tools to handle scale very well.● but if you dont know what youre doing, call for help :)
51. FTBpros setup on AWS
52. Mysql with RDSRDS is Amazons mysql. Its optimized andeasy to set up. saves us a lot of time on systemadministration.
53. Memcached with elasticacheElasticache is the Amazon memcachedservice. same as RDS, saves us time bother ofmessing with memcached servers.
54. Custom redis serverthinking about moving to cloud services to saveus the trouble.
55. Web servers with nginx+unicornnginx+unicorn are like milk and cookies. Withthe right setup we also get zero-downtimedeploys, which are awesome.
56. Resque serverstheyre also built for automatic scaling. justbecause were awesome!
57. CDN cache with cotendo (akamai)logged out users dont even touch the webservers - their content is served by the CDN.
58. Build it for quick and automatic scale● self-deploying servers - when you start the server from its image, it will deploy to itself and start serving traffic / run resque workers● adding servers is automatic - when theres high traffic, start them up, then kill them when traffics low● this allows to pay the minimum for hosting, while keeping scalability
59. careful with these self-deploying robots! make sure they know the robot rules...The rules:1. A robot may not injure a human being or, through inaction, allow a human being to come to harm.2. A robot must obey any orders given to it by human beings, except where such orders would conflict withthe First Law.3. A robot must protect its own existence as long as such protection does not conflict with the First orSecond Law.
60. ok, back to Ruby (kind of)When reaching massive scale, wed startlooking for custom solutions - relational dbswould stay forever, but some things should bemoved to other customized solutions.● consider using mongo for document-like data● consider using neo4j or other graph dbs for representing graph data (sorry Avi, mongo aint no graph DB!)
61. And dont forget to stay naive!being large scale, but still fun and lean, can behard, but pulling it off is worth it!