- Highest-priority scenarios - could be response times to user input, or server throughput, or other. I'm thinking data response times too.
- Articulate Bad, Good and Excellent performance - e.g., on startup 10 sec is bad, 3 sec is good, <>
- Do coarse estimation if "good performance" is in jeopardy - if uncertain, prototype and measure more; if bad, redesign.
Design design design design. "If you have a performance catastrophe - 10x, 100x from acceptable - then you either have some serious bugs or the flaw is in design. If it's in the design, then you're screwed. You cannot fix this late in the product cycle. You have to start over and redesign the app from scratch for version 2." You don't say. J.f.C.
Measure. Use real numbers. Measure early. Don't skimp on this. Performance is not free.
You cannot commit to features or designs until you know how much they cost, and to know that, you need real facts and real numbers. Use references (consults?), past experience, and experiments/prototyping to determine what things cost. You can only make rational decisions about how to build things if you know this. (I am sure this must apply to aspects of decision-making beyond just performance.)
Multi-threading. Ugh.
A symptom of blocking - you have a ton of stuff going on/waiting, but the machine's CPU is not fully utilized. This means something's hanging on some thread while the machine has idle threads to spare. Points of communication between threads will then be the bottlenecks. It's fine to share RO data between threads because each thread can keep its own hot copy.
Disk is 10,000x slower than RAM.
"The problem with caches is they only work the second time." D'oh.
("Argaments"?)
Memory is not a primary metric - time is. It only matters inasmuch as it affects time.
Takeaways:
1. Care.
2. Plan.
3. Measure.
4. Design.
5. Measure some more.
No comments:
Post a Comment