20 Common bottlenecks for programmers
In the Art of Extensibility book, Russell gives 20 interesting estimates: There are about 20 classic bottlenecks.
Russell said that if he was young, he knew how good these bottlenecks should be! These assertions include:
* Database (DB)
1. Data size exceeds maximum memory limit
2. Large queries and small queries
3. Write-Write conflicts
4. Large table join over-occupied memory
* Virtualization (Virtualization)
1. Share the disk, grab the track, head all kinds of shaking
2. Network IO fluctuations
* Programming (programming)
1. Threads: Deadlock, relative to event-driven, too heavyweight, debug, number of threads and performance-specific nonlinearity
2. Event-driven programming: complexity of callbacks, how to save states in function calls (How-to-store-state-in-function-calls)
3. Missing profile tool, missing Trace tool, missing log tool
4. Single point of failure, horizontal non-expandable
5. Stateful applications
6. Rub design: A machine can run, a few users can run, a few months later, a few years later, and found that can't carry, the entire architecture needs to be rewritten.
7. Complexity of the algorithm
8. Dependent on external components such as DNS lookups (dependentservices like DNS lookups and whatever else, or block on.)
9. Stack space
* Disk (Diskette)
1. Local Disk access
2. Random Disk IO
3. Disk Fragmentation
4. SSD performance degrades when the data block written is larger than the SSD block size
* OS (operating system)
1. Fsync flushing,linux buffer exhausted (Linux buffer cache filling up)
2. The TCP buffer is too small
3. Limitation of file descriptors
4 Power Management (Power budget)
* Caching (Cache)
1. Do not use memcached
2. HTTP, header,etags, uncompressed (headers, etags, not gzipping)
3. The browser caching feature is not fully used
4. Byte-code caching (e.g. PHP)
5. L1/L2 Cache. This is a big bottleneck. Keep the frequently used data in l1/l2. Design to a lot of aspects: Network data compression and then send, based on the column compression in the DB in the direct calculation of the decompression and so on. There are TLB-friendly algorithms. The most important is to firmly grasp the following fundamentals: multicore CPUs, L1/L2, shared L3,numa memory, data transmission bandwidth latency between CPUs, memory, disk page cache, dirty pages, TCP from CPU to DRAM to NIC.
* CPU
1. CPU Load
2. Context switch. A kernel has too many threads, the Linux scheduler is unfriendly to the application, and the system calls too many
3. Io Wait, all CPUs are waiting
4. CPU Cache. (Caching data is a fine grained process (in Java thinkvolatile for instance), in order to find the right balance between H Avingmultiple instances with different values for data and heavy synchronization tokeep the cached data consistent.)
5. Throughput capability of Backplane bus
* Network (Internet)
1. The maximum output bandwidth of the NIC, the IRQ is saturated, and the software interrupt consumes 100% of the CPU
2. DNS Lookups
3. Packet loss
4. Network Routing Backseat
5. Network disk access
6. Shared San (Storagearea Network)
Server not responding with 7 server failures
* Process (Procedure)
1. Test time
2. Development time
3. Team Size
4. Budget
5. Code debt (maintenance cost due to bad code)
* Memory (RAM)
1. Memory exhaustion, kill process, swap
2. Disk jitter due to insufficient memory
3. The cost of the memory library
4. Memory fragmentation (requires GC pauses in Java, no solution in C)
Java Programmer Growth Course (ii)