1. Caching: Improving Rendering Time & Database Performance (ESaaS §12.6) © 2013 Armando Fox & David Patterson, all rights reserved

2. The Fastest Database is the One You Don’t Use Caching: Avoid touching database if answer to a query hasn’t changed 1.Identify what to cache –whole view: page & action caching –parts of view: fragment caching with partials 2.Invalidate (get rid of) stale cached versions when underlying DB changes 2

3. Cache Flow

4. Page & Action Caching When: output of entire action can be cached –Page caching bypasses controller action caches_page :index –Action caching runs filters first Caveat: caching based on page URL without optional "?" parameters! /movies/index?rating=PG = movies/index /movies/index/rating/PG ≠ movies/index Pitfall: don’t mix filter & non-filter code paths in same action! 4

5. Example Bad: caches_page :index def index if logged_in?... else redirect_to login_path end 5 Better: caches_page :public_index caches_action :logged_in_index before_filter :check_logged_in, :only => 'logged_in_index' def public_index... end def logged_in_index... end

6. Fragment Caching for Views Caches HTML resulting from rendering part of a page (e.g. partial) - cache "movies_with_ratings" do = render :collection => @movies How do we detect when cached versions no longer match database? Sweepers use Observer design pattern to separate expiration logic from rest of app 6 http://pastebin.com/fCZJSimS

7. How Much Does Caching Help? With ~1K movies and ~100 reviews/movie in RottenPotatoes on Heroku, heroku logs shows: Can serve 8X to 21X more users with same number of servers if caching used

8. 8 END

9. (ii) & (iii) (iii) only (i), (ii) and (iii) (i) & (iii) ☐ ☐ ☐ ☐ 9 Under-17 visitors to RottenPotatoes shouldn’t see NC-17 movies in any listing. A controller filter exists that can determine if a user is under 17. What kinds of caching would be appropriate: i) Page ii) Action iii) Fragment

10. 10 END

11. Avoiding Abusive Queries (ESaaS §12.7) © 2013 Armando Fox & David Patterson, all rights reserved

12. Be Kind to the Database Outgrowing single-machine database => big investment: sharding, replication, etc. Alternative: find ways to relieve pressure on database so can stay in “PaaS-friendly” tier 1.Use caching to reduce number of database accesses 2.Avoid “n+1 queries” problem in Associations 3.Use indices judiciously

13. N+1 Queries Problem Problem: you are doing n+1 queries to traverse an association, rather than 1 query Solution: bullet gem can help you find these Lesson: all abstractions eventually leak! http://pastebin.com/QKxqcbhk

14. Eager Loading Naive way: @movie = movie.where( … ) reviews = @movie.reviews May be faster: @movie = movie.where( … ).include(:reviews) @movie.reviews.each do |review| # reviews are already loaded!

15. Indices Speeds up access when searching DB table by column other than primary key –e.g. Movie.where("rating = 'PG'") Similar to using a hash table –alternative is table scan - bad! –even bigger win if attribute is unique-valued Why not index every column? –takes up space –all indices must be updated when table updated

16. What to Index? Foreign key columns, e.g. movie_id field in Reviews table –why? Columns that appear in where() clauses of ActiveRecord queries Columns on which you sort Use rails_indexes gem (on GitHub) to help identify missing indices (and unnecessary ones!)

17. How Much Does Indexing Help?

18. 18 END

19. reviews.movie_id reviews.moviegoer_id moviegoers.review_id movies.review_id ☐ ☐ ☐ ☐ 19 Suppose Movie has many Moviegoers through Reviews. Which foreign-key index would MOST help speed up the query fans = @movie.moviegoers

20. has_many :through  moviegoer: has_many :reviews has_many :movies, :through => :reviews  movie: has_many :reviews has_many :moviegoers, :through => :reviews  reviews: belongs_to :moviegoer belongs_to :movie reviews moviegoer_id movie_id... movies id... moviegoers id

21. 21 END

22. Defending Customer Data (ESaaS §12.8) © 2013 Armando Fox & David Patterson, all rights reserved

23. Common Attacks on the App 1.Eavesdropping 2.Man-in-the-middle/Session hijack 3.SQL injection 4.Cross-site request forgery (CSRF) 5.Cross-site scripting (XSS) 6.Mass-assignment of sensitive attributes …more in book

24. SSL (Secure Sockets Layer) Idea: encrypt HTTP traffic to foil eavesdroppers Problem: to create a secure channel, two parties need to share a secret first But on the Web, the two parties don’t know each other Solution: public key cryptography (Rivest, Shamir, & Adelman, 2002 Turing Award)

25. What SSL Does, and Doesn’t Each principal has a key of 2 matched parts –public part: everyone can know it –private part: principal keeps secret –given one part, cannot deduce the other Key mechanism: encryption by one key requires decryption by the other –If a message can be decrypted with Bob’s public key, then Bob must have created (“signed”) it –If I use Bob’s public key to create a message, only Bob can read it

26. How SSL Works (Simplified) 1.Bob.com proves identity to CA 2.CA uses its private key to create a “cert” tying this identity to domain name “bob.com” 3.Cert is installed on Bob.com’s server 4.Browser visits http://bob.com 5.CA’s public keys built into browser, so can check if cert matches hostname 6.Diffie-Hellman key exchange is used to bootstrap an encrypted channel for further communication Use Rails force_ssl method to force some or all actions to use SSL

27. What It Does and Doesn’t Do Assures browser that bob.com is legit Prevents eavesdroppers from reading HTTP traffic between browser & bob.com Creates additional work for server! DOES NOT: ✖ Authenticate user to server ✖ Protect sensitive data after it reaches server ✖ Protect server from other server attacks ✖ Protect browser from malware if server is evil

28. SQL Injection View: = text_field_tag 'name' App: Moviegoer.where("name='#{params[:name]}'") Evil user fills in: BOB'); DROP TABLE moviegoers; -- Executes this SQL query: SELECT * FROM moviegoers WHERE (name='BOB'); DROP TABLE moviegoers; --' Solution: Moviegoer.where("name=?", params[:name]) xkcd.com/327

29. Cross-Site Request Forgery 1.Alice logs into bank.com, now has cookie 2.Alice goes to blog.evil.com 3.Page contains: <img src="http://bank.com/account_info"/> 4.evil.com harvests Alice’s personal info Solutions: (weak) check Referer field in HTTP header (strong) include session nonce with every request –c–csrf_meta_tags in layouts/application.html.haml –p–protect_from_forgery in A pplicationController –R–Rails form helpers automatically include nonce in forms

30. 30 END

31. (i) & (ii) only (ii) & (iii) only (i), (ii) & (iii) (i) only ☐ ☐ ☐ ☐ 31 If a site has a valid SSL certificate from a trusted CA, which of the following is true: i) The site is probably not “masquerading” as an impostor of a real site ii) CSRF + SQL injection are harder to mount against it iii) Your data is secure once it reaches the site

32. 32 END

33. Plan-And-Document Perspective on Performance, Releases, Reliability and Security (Engineering Software as a Service §12.10) 33 © 2013 Armando Fox & David Patterson, all rights reserved

34. P&D on the 4 Issues? Does Plan-and-Document address performance issues? Anything special about Plan-and-Document releases? P&D Standards for Quality? Are the reliability and security challenges similar in Plan-and-Document? Can unreliability lower security? 34

35. P&D and Performance Like reliability and security, performance considered a non-functional requirement –Can be part of acceptance tests Plan-and-document lifecycles ignore performance because –Performance optimizations often excuse for bad SW engr practice –Covered in other books/courses 35

36. P&D and Release Management Special case of configuration management P&D releases include everything: code, configuration files, data & documentation P&D releases number scheme: e.g., Rails version 3.2.12 –.12 is minor release –.2 is major release –3 so large a release that it can break APIs, must re-port app 36

37. P&D and Reliability Dependability via redundancy –Guideline: no single point of failure How much redundancy can customer afford? Mean Time To Failure (MTTF) includes SW & operators as well as HW Unavailability ≈ Mean Time To Repair/MTTF –Improving MTTR may be easier than MTTF, but can try to improve both MTTR & MTTF 37

38. P&D and Processes to Improve SW P&D assumption is can improve SW development process of organization => More reliable SW product –Record all aspects of project to see what can improve Get ISO 9001 standard if a company has: 1. Process in place 2. Method to see if process is followed 3. Records results to improve process –Approval for process, not quality of resulting code 38

39. ISO 9001 39

40. P&D and Security Reliability relies on probabilities, but security must defend against intelligent opponents –Common Vulnerabilities and Exposures database list typical attacks: cvedetails.comcvedetails.com Some reliability improving techniques prevent attacks: –Buffer overflows, arithmetic overflows, data races Penetration tests via tiger team can test security 40

41. 3 Security Principles 1.Least privilege: a user or software component should be given no more privilege - that is, no further access information and resources - than what is necessary to perform its assigned task –“need-to-know” principle for classified information 41

42. 3 Security Principles 2.Fail-safe defaults: unless a user or software component is given explicit access to an object, it should be denied access to the object –Default should be denial of access 3. Psychological acceptability: protection mechanism should not make the app harder to use than if no protection –Needs to be easy to use so that the security mechanisms are routinely followed 42

43. 43 END

44. Not checking buffer limits could violate the security principle of least privilege Not removing data races could violate the security principle of psychological acceptability None are false; all are true Improper initialization of data could violate the security principle of fail-safe defaults 44 Which statement regarding reliability and security is most likely FALSE? 1. 2. 3. 4.

45. 45 END

46. Fallacies, Pitfalls & Concluding Remarks (ESaaS §12.9-12.11) © 2013 Armando Fox & David Patterson, all rights reserved

47. Optimizing Prematurely or Without Measurements Speed is a feature that users expect –99%ile (e.g.), not “average” Horizontal scaling >> per-machine performance, but lots of ways things can slow down Monitoring is your friend: measure twice, cut once See “Scaling Rails Screencasts” on Youtube 47

48. “Mine is a 3-Tier App on Cloud Computing, So It Will Scale” Database is particularly hard to scale –Even if you do, still want to get “expensive” operations out of the way of your SLO One help: cache at many levels –Whole page, fragment, query –Cache expiration is a crosscutting concern –Rails support for crosscutting concerns allows you to specify it declaratively Use PaaS for as long as you can 48

49. “My Small Site Isn’t a Target” Hackers may be after your users, not your data Like performance, security is a crosscutting concern - hard to add after the fact Stay current with best practices and tools – you’re unlikely to do better by rolling your own Prepare for catastrophe: keep regular backups of site and database

50. 50 END

51. Some queries are unusually slow because you’re sharing DB with other apps Some views take unusually long to render in certain browsers (eg, due to JavaScript) It could be any of these/Not enough information Not enough Heroku “dynos”, so requests occasionally get “backed up” ☐ ☐ ☐ ☐ 51 Your users are sporadically complaining that your site is slow, yet New Relic reports low traffic levels and low CPU utilization. What is the likely cause?

52. 52 END