Do cheaters prosper? Understanding the rules of application development
•
1 j'aime•1,297 vues
From an early age, we are told that cheating is bad. There are rules we’re supposed to follow, and breaking these rules – we’re told – is a big no-no. No ice-cream before dinner, no peeking at your classmate’s test, no cutting in line for lunch… or else. But is cheating always a bad thing? Bad cheating breaks the law, puts people at risk or has severe negative consequences. If you’re making a program to run a nuclear reactor: don’t cheat. If something goes wrong then there will be very bad consequences. Good cheating is like a magic trick: it’s a method to achieve a desired effect. Just don’t get caught. Getting caught ruins the magic and gets you in trouble. Do things “wrong”, get dirty, use hacks, and optimize for very specific cases. Do all this in order to deliver the desired effect. Applications capture, retrieve and display resources. These resources have costs, such as the cost of transmission, processing and storage. Different resources have varying probabilities of being required; some may be requested and others not, some may be requested frequently and others rarely. These are all things to consider when deciding what processes can and need to be optimized, which will in turn help you choose from your magic bag of tricks. Here’s a quick barometer for deciding when to cheat: - Requests that are free or cheap to deliver and are rare are not worth optimizing since these are essentially effortless already - Requests that are expensive but rare aren’t a priority, feel free to procrastinate on these - Requests that are free or cheap and happen frequently are the fun ones to optimize - Requests that are frequent and expensive are your big wins… if you can figure out how to optimize them.
Recommandé
Recommandé
Contenu connexe
Dernier
Dernier (20)
En vedette
En vedette (20)
Do cheaters prosper? Understanding the rules of application development
- 1. Do Cheaters Prosper? UNDERSTANDING THE RULES OF APPLICATION DEVELOPMENT Scott Tadman (Chief of Research) / Dom Bortolussi (CEO), TWG @tadmanter @dombort @twg
- 2. “The Rules” • These are taught to you in school. • Based on conventions, shaped by tradition. • Supposed to steer you towards best practices. • Usually distorted by superstition and paranoia.
- 3. “The Rules” • These arbitrary rules put you in a box. • They limit your thinking.
- 4. “The Box”
- 5. “Cheating” • Defies convention. • Thinks “outside the box”. • Breaks “rules”. • Yields an “unfair” advantage.
- 6. Cheating? • Isn’t cheating bad?
- 7. Bad Cheating • Breaks laws. • Puts people at risk. • Has severe negative consequences.
- 8. Good Cheating • Often called “hacks” or “tricks” • Circumvents ritual or tradition. • Cutting corners.
- 10. Good Cheating
- 11. Bad Cheating
- 12. Bad Cheating • We usually call it “illegal”. • Like get you into jail illegal.
- 13. So what are the rules?
- 14. The Application’s Rules • Don’t crash on me. • Don’t waste my time. • Don’t lie to me. • Don’t forget my things. • Don’t cost me money/bandwidth.
- 15. Important Rule • Don’t kill me.
- 16. Asimov’s Law • “A robot may not harm a human being.”
- 17. Developer’s Law? • “An application may not harm a human being.”
- 18. “Fatal Error?”
- 19. Nuclear Reactor
- 20. Nuclear Reactor
- 21. Nuclear Reactor
- 23. Consequences?
- 24. We all die.
- 26. X-Ray Machine
- 27. X-Ray Machine
- 28. X-Ray Machine
- 30. Consequences?
- 31. Someone dies.
- 35. Consequences?
- 36. Nobody dies.
- 38. Most Applications • Won’t kill people. • Won’t misplace lots of money. • Won’t destroy the universe. • Have a lot of opportunities to “cheat”.
- 39. “Cheating”
- 40. It’s like a magic trick.
- 42. It ruins it.
- 43. Successful Cheating • Don’t let me catch you crashing on me. • Don’t let me catch you wasting my time. • Don’t let me catch you lying to me. • Don’t let me catch you forgetting my things. • Don’t let me catch you costing me money/ bandwidth.
- 44. Successful Cheating • It’s all about not getting caught.
- 45. A Magic Trick • Rough definition: • A method to achieve the desired effect.
- 46. An Application • Rough definition: • A programmed method to achieve desired effects.
- 48. Performance Cheats • Doing the “wrong” thing. • Getting “dirty”, introducing “hacks”. • Optimized for very specific cases. • Are focused on delivering the desired effects. • It’s always about perception.
- 49. Applications Deconstructed • Capture, retrieve and display resources. • Resources have varying costs including: • Cost of transmission. • Cost of processing. • Cost of storage.
- 50. Application Fundamentals • Resources may or may not be requested. • Resources have varying probabilities of being required. • Some requests are frequent. • Some requests are rare.
- 51. Cost to Deliver Probability of Request Low High Optimization Regions The Box Expensive Rare Free Frequent Generalized solutions to generalized problems.
- 52. Cost to Deliver Probability of Request Low High Optimization Regions Effortless Expensive Rare Free Frequent These don’t require optimization.
- 53. Cost to Deliver Probability of Request Low High Optimization Regions Effortless Procrastinate Expensive Rare Free Frequent These aren’t a priority.
- 54. Cost to Deliver Probability of Request ExpensiveLow Rare High Optimization Regions Pleasure Effortless Procrastinate Free Frequent These are the ones we love to fix.
- 55. Cost to Deliver Probability of Request Low High Optimization Regions PainPleasure Effortless Procrastinate Expensive Rare Free Frequent Big wins...if you can figure out how.
- 56. Bandwidth System Power Low High Resources Marginal None Unlimited Unlimited Personal Computer Mobile Single Server Server Cluster
- 58. Perception Matters • Performance is all about perception. • People are oblivious to your best. • People will remember your worst. • Outliers are what people perceive the most. • Remember: If the application “feels” fast, it is fast.
- 60. Goals of “Cheating” Cost to Deliver Probability of Request Low High Expensive Rare Free Frequent Identified Problem Expensive and frequent.
- 61. Cheating Goals Cost to Deliver Probability of Request Low High Expensive Rare Free Frequent Optimization A Method to reduce cost of delivery.
- 62. Cheating Goals Cost to Deliver Probability of Request Low High Expensive Rare Free Frequent Optimization B Method to reduce frequency of requests.
- 63. Cheating Goals Cost to Deliver Probability of Request Low High Expensive Rare Free Frequent Optimization A + B Combination reduces cost and frequency.
- 65. Cost to Deliver Probability of Request Low High Weather Widget Expensive Rare Free Frequent Implemented Fetch from API on demand and reformat into widget.
- 66. Cost to Deliver Probability of Request Low High Weather Widget Expensive Rare Free Frequent Implemented Fetch from API on demand and reformat into widget. Popularity Widget used by large percentage of users.
- 67. Cost to Deliver Probability of Request Low High Weather Widget Expensive Rare Free Frequent Implemented Fetch from API on demand and reformat into widget. Cached Widget data cached and re-used for different users. Popularity Widget used by large percentage of users.
- 68. Cost to Deliver Probability of Request Low High Financial Blog Expensive Rare Free Frequent Stock Solution Images are loaded on demand without any processing.
- 69. Cost to Deliver Probability of Request Low High Financial Blog Expensive Rare Free Frequent Stock Solution Images are loaded on demand without any processing. Popularity Blog becomes very popular due to publicity.
- 70. Cost to Deliver Probability of Request Low High Financial Blog Expensive Rare Free Frequent Stock Solution Images are loaded on demand without any processing. Popularity Blog becomes very popular due to publicity. Content Shift Large, detailed charts now a common feature on blog.
- 71. Cost to Deliver Probability of Request Low High Financial Blog Expensive Rare Free Frequent Stock Solution Images are loaded on demand without any processing. Popularity Blog becomes very popular due to publicity. Content Shift Large, detailed charts now a common feature on blog. Solution 1 Lazy-load images further down page.
- 72. Cost to Deliver Probability of Request Low High Financial Blog Expensive Rare Free Frequent Stock Solution Images are loaded on demand without any processing. Popularity Blog becomes very popular due to publicity. Content Shift Large, detailed charts now a common feature on blog. Solution 2 Host images on cloud. Solution 1 Lazy-load images further down page.
- 73. Cost to Deliver Probability of Request Low High Financial Blog Expensive Rare Free Frequent Stock Solution Images are loaded on demand without any processing. Popularity Blog becomes very popular due to publicity. Content Shift Large, detailed charts now a common feature on blog. Solution 1 Lazy-load images further down page. Solution 2 Host images on cloud. Solution 3 Create smaller inline images.
- 75. Wait Less • Work to minimize perceived wait. • Make things appear instantly. • Don’t block, lock up, or stall. • Flip client state immediately, handle in background.
- 76. Cost to Deliver Probability of Request Low High Wait Less Expensive Rare Free Frequent Target Zone “Add User Comment” Frequent operation but requires some heavy processing to apply correctly, complicated by convoluted business logic.
- 77. Cost to Deliver Probability of Request Low High Wait Less Expensive Rare Free Frequent Client State Directly Altered Show result of user action immediately, actually process in background.
- 78. Wait More • Make things appear important. • Keep user informed: spinners, progress bars. • Keep delay proportional to significance. • Can avoid really expensive requests by being annoying.
- 79. Cost to Deliver Probability of Request Low High Wait More Expensive Rare Free Frequent Target Zone “Preview My Book” Requesting too many previews can cause severe server load issues.
- 80. Cost to Deliver Probability of Request Low High Wait More Expensive Rare Free Frequent “Your Book is Queued” Delayed gratification. More Consideration People less likely to engage feature needlessly.
- 81. Cost to Deliver Probability of Request Low High Wait More Expensive Rare Free Frequent Target Zone “Find Best Flight” Might be trivial to calculate, but perceived value is very high.
- 82. Cost to Deliver Probability of Request Low High Wait More Expensive Rare Free Frequent “Calculating Results...” Artificial delay makes task seem significant, system more powerful.
- 83. Load Less • Fetching things on demand. • “Lazy loading” • Ideal for resources that might not be seen. • Refrigerator light principle: Always seems on.
- 84. Cost to Deliver Probability of Request Low High Load Less Expensive Rare Free Frequent Target Zone “Blog Page, Post N” Things that are requested but not always utilized.
- 85. Cost to Deliver Probability of Request Low High Load Less Expensive Rare Free Frequent Lazy Loading Puts of loading a resource until actually required.
- 86. Load More • Fetching resources ahead of time. • “Eager loading” • Ideal for resources that will probably be seen. • Boy-scout principle: Be prepared.
- 87. Cost to Deliver Probability of Request Low High Load More Expensive Rare Free Frequent Target Zone “Site Icons” Many, many requests for tiny, inexpensive resources can add up.
- 88. Cost to Deliver Probability of Request Low High Load More Expensive Rare Free Frequent Asset Bundling Create single asset that can be used to render all icons. High Aggregate Cost Requesting many tiny resources can be expensive. Site Icons Very large number of small files.
- 89. Saving Less • Trim, crop, shrink. • Strip out redundant or duplicated content. • Define and enforce limitations. • One size fits all instead of uncertainty. • Consider rendering on demand.
- 90. Cost to Deliver Probability of Request Low High Saving Less Expensive Rare Free Frequent Target Zone “Upload Photo” Users upload full-sized photos when only smaller versions are ever actually displayed.
- 91. Cost to Deliver Probability of Request Low High Saving Less Expensive Rare Free Frequent Reduce Size, Compress Shrinking to sizes required by actual use cases, compressed to an acceptable level of quality.
- 92. Saving More • Make copies of things in different formats. • A form of “caching”, “pre-rendering” • De-normalize your data. • Optimize structure around retrieval patterns. • Try and have everything important ready instantly.
- 93. Cost to Deliver Probability of Request Low High Saving More Expensive Rare Free Frequent Target Zone “Image Variants by Size” Images are used at various fixed sizes, each needing some processing to render.
- 94. Cost to Deliver Probability of Request Low High Saving More Expensive Rare Free Frequent Pre-Rendering Reduces frequency of requests requiring heavy processing.
- 95. Cache More • Fastest database call is the one never made. • Pre-cache when you have the data on hand. • Reuse and recycle expensive results. • Let your client cache images, scripts, pages. • Learn to love the “expires” feature.
- 96. Target Zone Cost to Deliver Probability of Request Low High Cache More Expensive Rare Free Frequent Target Zone High Frequency + Cost Cache anything you can. Target Zone High Frequency Cache if you can. High Cost Cache if likely to be used more than once.
- 97. Cost to Deliver Probability of Request Low High Cache More Expensive Rare Free Frequent “Friends of My Friends” Database Query Result unlikely to change except in specific circumstances. Tricky to compute, easy to cache.
- 98. Cost to Deliver Probability of Request Low High Cache More Expensive Rare Free Frequent “Video Effects Preview” Result of preview saved temporarily. First Request Second Request
- 99. Cache Less • Tuning your database can make caching redundant. • Caches can make updates take longer. • Cache invalidation can be really hard. • Cache mistakes can be really embarrassing. • Running without a cache leaves you with headroom.
- 100. Cost to Deliver Probability of Request Low High Cache Less Expensive Rare Free Frequent Target Zone “Premature Optimization” Hiding real costs, creating hidden liabilities.
- 101. Cost to Deliver Probability of Request Low High Cache Less Expensive Rare Free Frequent Original Implementation Expensive and slow. Caching Opportunity Potential performance gain. Cached Result Quick and easy fix. Refactoring Without Cache Solves actual performance problem.
- 102. Distribute More • Content distribution networks. • Clustered databases, data replication. • Client-side storage, content bundles. • Push data closer to users. • “Edge caching”
- 103. Cost to Deliver Probability of Request Low High Distribute More Expensive Rare Free Frequent Target Zone “Server-Side Content” User provided content is stored on your application servers, storage and retrieval is getting overwhelming.
- 104. Cost to Deliver Probability of Request Low High Distribute More Expensive Rare Free Frequent Server Hosted Resource Stored on server, transmission impedes other server operations. CDN Hosted Resource No effort required to retain and deliver to client.
- 105. Distribute Less • Keep data and content local. • Self-hosted databases instead of cloud- hosted. • “Dumb client, smart server” applications. • Way more control over structure, strategy, technology.
- 106. Cost to Deliver Probability of Request Low High Distribute Less Expensive Rare Free Frequent Target Zone “Cloud Hosted Metrics Database” Slow, unresponsive API, charged per query.
- 107. Cost to Deliver Probability of Request Low High Distribute Less Expensive Rare Free Frequent Remote Cloud Service Takes hundreds of API calls. Local Data Warehouse Takes a few SQL queries.
- 108. Purge More • Delete data no longer used. • Archive to cheaper storage systems. • Generate on demand. • Less data equals less overhead. • Minimalist principle.
- 109. Target Zone Cost to Deliver Probability of Request Low High Purge More Expensive Rare Free Frequent “Outdated, Detailed User Metrics Data” Expensive to retain, not likely to get used.
- 110. Cost to Deliver Probability of Request Low High Purge More Expensive Rare Free Frequent Deleted Nobody will miss it.
- 111. Purge Less • Dump it on the cloud, forget about it. • Keep things cached longer. • Pre-render instead of render on demand. • Long-tail: Sometimes unpopular things matter.
- 112. Cost to Deliver Probability of Request Low High Purge Less Expensive Rare Free Frequent Save Alternate Formats Also store as XML or JSON, exactly sent by API. High Aggregate Cost Requests for unrelated resources can add up. “Movie Actors” Extensive library of movies, but queries aren’t predictable.
- 113. Compress More • Lossless or lossy compression. • Use deflate (gzip) for transfers. • Aggressively minify scripts.
- 114. Target ZoneCost to Deliver Probability of Request Low Compress More Expensive Rare Free Almost Anything Most resources benefit from some form of compression. Frequent
- 115. Cost to Deliver Probability of Request Low Compress More Expensive Rare Free Frequent Text Resource Some things compress really well. JPEG Image Resource Some things can’t be compressed much more without damage.
- 116. Compress Less • Keep data in pure, raw form. • Databases can’t interact with compressed data. • Serialized or compressed data can’t be queried. • Some databases love JSON or key-value types.
- 117. Cost to Deliver Probability of Request Low High Compress Less Expensive Rare Free Frequent “User Profile Data” Hundreds of arbitrary fields, stored as JSON. Store as Raw JSON Slightly higher write and retrieval cost.Query JSON in DB Much lower query cost.
- 118. Index More • Every query has a cost. • Examine access patterns, index accordingly. • A query without an index: painful. • A query with a tuned index: bliss. • Indexes massively reduce retrieval time.
- 119. Cost to Deliver Probability of Request Low Index More Expensive Rare Free Frequent “Message Board Table” Queried very frequently, indexing is vital. Aggressive Indexing Use index to reduce read cost.
- 120. Index Less • Every index makes writes more expensive. • Indexes don’t always get used. • Some indexes you might want but not need. • Awkward but fast can be better than easy but slow.
- 121. Cost to Deliver Probability of Request Low Index Less Expensive Rare Free Frequent Aggressive Indexing Writes are significantly more expensive. “User Activity Table” More writes than reads.
- 122. Multitask More • Do things in parallel. • Break down dependencies, avoid contention. • Distribute work across many systems. • Map-reduce doesn’t have to be hard.
- 123. Cost to Deliver Probability of Request Low High Multitask More Expensive Rare Free Frequent“Render Page” Smaller scale task is easy to delegate to many workers. “Render Album Preview” Each page is an independent, but the final book needs to be one file. Perceived Result Processing time massively reduced.
- 124. Multitask Less • Stream things in sequentially. • Keep load on server light. • Keeps more network resources available. • Buffer requests and process casually.
- 125. Cost to Deliver Probability of Request Low High Multitask Less Expensive Rare Free Frequent “Sync Calendar Entries” Operation that’s expected to take considerable time can be delayed. Background Tasks Create a simple work queue to minimize number of parallel operations.
- 126. Provision More • Server hardware can be scaled up. • Desktop/mobile apps can leverage server hardware. • On-demand cloud services can be awesome. • No inherent limit on server capability. • If you can throw hardware at it, maybe do that.
- 127. Cost to Deliver Probability of Request Low High Provision More Expensive Rare Free Frequent Relatively Expensive Uses high percentage of CPU. Relatively Inexpensive Same operation on distributed server cluster is no big deal.
- 128. Provision Less • Keep your application footprint lean. • Don’t burn through CPU and battery. • Don’t use tons of memory. • Smaller apps load faster, don’t get kicked out as often. • Smaller server clusters easier to tune and manage.
- 129. Cost to Deliver Probability of Request Low High Provision Less Expensive Rare Free Frequent “Upload All Photos on Phone” Interrupts application flow, stalls, heavy CPU usage. Batched Operations Split up task into smaller, low-impact tasks.
- 130. Breaking Rules
- 131. “Cheating”
- 133. Figure the rest out.
- 134. Scott Tadman twg.ca @ceben @twg THANK YOU Scott Tadman / Dom Bortolussi twg.ca @tadmanter @dombort @twg github.com/tadman twg.ca hello@twg.ca