In ZenAndTheArtOfScaling-akoandepigramapproach, RussellSullivan proposed an interesting idea: there are 20 classic bottlenecks. It sounds as skeptical as there are only 20 basic plots (20 basicstoryplots. But based on different people
In The article Zen And The Art Of Scaling-A Koan And Epigram Approach, Russell Sullivan proposed an interesting idea: there are 20 classic bottlenecks. It sounds as skeptical as there are only 20 basic plots (20 basic story plots. However, this statement may be correct based on different classification methods. However, in reality, we all know that bottlenecks are endless and involve all aspects.
One day, Aurelien Broszniowski from Terracotta emailed me a list of bottlenecks in his mind. at the same time, we copied our email to Russell, and he also gave his list. I also have my own ideas. So below is a pot of stone soup made from these bowls of water (http://en.wikipedia.org/wiki/Stone_soup, stone soup Story)
Russell said it would be nice to know this when I was young, and it could provide more ideas for me. The more experience you have, the more content you can add to this list if you have processed different types of projects. Therefore, when you are reading this list or sorting out your own list, every story is worth summing up with years of experience and some small setbacks.
Database
- Working data size exceeds available memory RAM
- Long-short query hybrid
- Write-write conflict
- Large federated queries occupy light memory
Virtualization
- Shared HDD storage, disk track pending
- Network I/O fluctuations in the cloud platform
Programming
- Threads: deadlocks, too heavyweight compared with event drivers, debugging, and non-linear performance-to-number of threads
- Event-driven programming: the complexity of callback and how to save the status in function calls (how-to-store-state-in-function-CILS)
- Profile tools, trace tools, and log tools are missing
- Single point of failure (SPOF) and non-Scalability
- Stateful applications
- Rub design: one machine can run, and several users can also run. a few months later, a few years later, Nima found that the entire architecture had to be rewritten.
- Algorithm complexity
- Relying on external components such as DNS lookup
- Stack space
Disk
- Local disk access
- Random disk read/write-> disk seek
- Disk fragmentation
- Writing data that exceeds the SSD capacity causes SSD hard drive performance to decrease
Operating system
- The kernel buffer is flushed into the disk to fill the linux buffer cache.
- The TCP buffer is too small.
- File descriptor restrictions
- Power distribution
Cache
- Do not use memcached
- HTTP, header, etags, not compressed (headers, etags, not gzipping)
- The browser cache function is not fully used.
- Bytecode cache (such as PHP)
- L1/L2 cache, which is a major bottleneck. Keep frequently used data in L1/L2. There are many design aspects: compression of network data before sending, and calculation without pressure in DB based on column compression. There are TLB-friendly algorithms. The most important thing is to master the following basic knowledge: Multi-core CPU, L1/L2, shared L3, NUMA memory, data transmission bandwidth latency between CPU and memory, disk page cache, dirty pages, the process of TCP from CPU to DRAM to Nic.
CPU
- CPU overload
- Context switching-> a kernel runs too many threads, linux scheduling is unfriendly to applications, too many system calls, and so on...
- IO wait-> all CPUs are suspended, and the wait time is slow.
- CPU cache: cache data is a process that is carefully designed to balance different values of different instances with heavy synchronization cache data.
- Backplane throughput
Network
- The maximum output bandwidth of the network adapter. when IRQ reaches saturation, the software interrupt occupies 100% of the CPU.
- DNS lookup
- Packet loss
- Network routing command
- Network disk access
- Shared SAN (Storage Area Network)
- Server failed-> server does not respond
Process
- Test time: Testing time
- Development time
- Team size
- Budget
- Code defect Code debt
Memory
- Memory overflow-> killing processes and entering swap, getting slower and slower
- Memory overflow causes frequent disk read/write (swap-related)
- Memory Library overhead
- Memory Fragmentation
- Java requires garbage collection, causing program suspension
- Malloc in C language cannot be allocated
If you have more bottleneck insights and experiences, please leave a comment below.
