От: | xednay89 | ||
Дата: | 16.07.16 23:37 | ||
Оценка: | 10 (2) |
Шпаргалка | |
1. Do Nothing (why? mathwise perfect: min possible latency, cpu, mem & infinitely scalable) 2. Do Very Little (why? broadstrokes is the next most perfect & efficient thing after Do Nothing) 3. Static Not Dynamic 4. Cached 5. Distributed 6. Parallelized 7. Asynchronous 8. Incremental 9. Step Minimization 10. Paginated Results 11. Complexity (in Time or Space) Cost Optimal Algorithms (eg. O(1) over O(n) over O(n^2)) 12. Event-Driven Not Polled 13. Non-Blocking IO 14. Web Page Component Request Minimization 15. Network Locality (eg. CDN’s) 16. Machine Task-to-Data Locality (eg. Hadoop) 17. Precompute Predicted Requests 18. Eager Init vs Lazy Init 19. Higher CPU Clock Speed 20. Higher CPU Core Count 21. CPU Instructions Which Do More Work Per Cycle/Tock (eg. SIMD) 22. Higher Communication Bus Speed, Throughput 23. Do Tasks in Hardware Rather than Software 24. Leaner Languages & Runtimes 25. More Memory 26. Faster Memory 27. More Disk/Storage 28. Faster Disk/Storage (Seek, Read, Write) 29. Disk/Storage Defragmentation 30. Local Disk/Storage Rather Than Network Mounted 31. Higher Network Bandwidth 32. Compression of Large Transfer Payloads 33. Connection Pools 34. UDP not TCP 35. Minimize Chattiness of Comm Protocols 36. Pass Smaller Messages 37. Make Use of Otherwise Unused Local GPU For General/Parallel Compute Tasks 38. Make Use of Cloud Computing Services (eg. AWS) 39. Tuning OS Parameters 40. Custom OS Kernel Builds 41. Non-Virtual OS Instance 42. RTOS (if require a guarantee & hard upper bound on latency of action in response to event) 43. No OS (yes extreme but consider case of microcontroller where only 1 master program req) 44. Pass and Store Diffs Rather Than Complete Snapshots 45. Client-Server Architecture (eg. benefit: long startup init tasks done in server not clients) 46. Push Work To Client-Side Rather Than Server-Side (eg. rendering, initial input validation) 47. Local Function Calls Rather Than RPC or Web Service Requests 48. Function Memoization 49. Function Inlining 50. Loop Unrolling 51. Less Unnecessary Call Descent Depth (eg. Java/Enterprise Design Pattern Astronaut Arch) 52. Less Memory Churn and Background GC Inside Your Process 53. Object Pooling 54. Clusters 55. Queues with Worker Process/Thread Pools 56. Database Sharding 57. Database Indexing 58. Database Prepared Statements 59. Old Data Warehousing/Archiving 60. Old Metric/Event Rollups 61. Log Archiving 62. Timeout Guards 63. Buffer Size Tuning 64. Queue Size Tuning 65. Timeout Duration Tuning 66. Network Packet Size Tuning 67. Disk Page Size Tuning 68. Memory Page Size Tuning 69. Cache Size Tuning 70. Cache Eviction/Expiration Policy Tuning 71. Avoid Need To Mitigate Risk Of Hardware Failures Due To Vibration/Shock 72. Avoid Need To Mitigate Impact Of Environmental Radiation (eg. cosmic x-rays) 73. Reduce Physical Volume (eg. consider design impact on smartphones and data centers) 74. Reduce Physical Mass (eg. consider compute capabilities & cost impact on space payloads) 75. Reduce Power Consumption (eg. smartphones, laptop battery life, data centers) 76. Reduce Heat Emission (eg. impacts cooling reqs thus total cost/complexity of data centers) 77. Keep Hardware Cool, Especially Processors 78. Commodity Priced Hardware Rather Than Vendor Monopoly/Patented/Unique Hardware 79. Later/Recent Generation Hardware Models (in general: more optimized than earlier/older) 80. Decrease Max/Mean/Min Time Before Detection of Failure 81. Upstream DoS Throttling/Filtering 82. User Request Throttling 83. Automatic Load Balancing (esp smarter) 84. Off-Peak Scheduling of Tasks When Possible 85. Encourage/Require Users To Spread Access/Requests/Workloads More Evenly Over Time 86. No Encryption 87. Minimize Core/Thread Context Switching 88. Avoid Mem/Disk Paging/Swapping, Especially Thrashing 89. Higher OS Scheduling Priority For Processes Directly Responding To Live User Commands 90. Avoid Lock Contention 91. Textual UI’s and CLI’s Rather Than GUI’s 92. Text Rather Than Images and Static Images Rather Than Video, Audio or Animations 93. Vector Illus/Anims/UI’s Rather Than Bitmaps To Minimize Disk/Net/Mem Footprint 94. JSON/CSV/etc Rather Than XML (whose impls often cause higher latency or mem use) 95. Prefer Precise, Reactive, Resource Sipping Tools (eg. latency/mem/cpu of vim over Eclipse) 96. Automated Rather Than Manual (eg. no staff approval queue for content, just filter and flag) 97. Make Light Speed in Vacuum Your Only Remaining Latency Bottleneck Where Possible | |