Multithreading is complex :
“Moving away from ‘fork, run, die’, model brings higher capacity but only by introducing a new risk to stability” - compare how this is not the case when using JVM and multithreading is only one way of achieving better utilization. With any interpreted language and current cloud tech, multithreading is no longer the necessary evil. You can choose to go with multithreading technologies or use technology that scales differently. You can stay away from complexities of multithreading.
Be wary of third party code:
Yes trust and test, But keep your code as independent as you can. So that you can indeed plug and play.
Does not make sense as written in this book - due to autoscaling and DR options on the Cloud
Purge stale data like logs, cache, other activity: Use papertrail, logDNA, splunk instead. You will never need to roll logs after and the default logging mechanism will be sufficient.
Wasted Space in HTML
Techniques available to do this:
- gzip - https://stackoverflow.com/questions/11641923/transfer-encoding-gzip-vs-content-encoding-gzip
https://en.wikipedia.org/wiki/HTTP_compression - ref : Problems preventing HTTP compression
In our experience, best is under one minute, worst (assuming on-demand and not spot) is around six minutes, and average is around four minutes. We launch mainly instance-store-backed instances.
- warm up your elb