Retry bốn dòng của Spring cho cùng kết quả nhưng chậm gấp 1000 lần — vì luồng ngồi chờ, không làm gì
Spring AMQP cho bật retry bằng vài dòng cấu hình. Phép đo cho thấy nó chặn luồng consumer, và toàn bộ thời gian thêm vào là thời gian ngồi chờ.
#hieu-nang
370 bài viết
Luồng ảo nhanh gấp 2,2 lần — nhưng chỉ khi pool luồng đang là nút thắt, và nút thắt chỉ dịch chỗ
Luồng nền như trạm thu phí có số làn cố định; luồng ảo gỡ bỏ trạm đó — nhưng xe lại dồn ở cây cầu hẹp phía sau (pool kết nối). Đo thật hai cấu hình, và ba chỗ luồng ảo không giúp gì.
pprof chỉ thẳng hàm cấp phát 16,55 GB — và vì sao 'đo trước khi tối ưu' là luật, không phải lời khuyên
Như gắn đồng hồ đo vào từng ổ cắm thay vì đoán thiết bị nào ngốn điện. Viết benchmark chuẩn, đọc cột allocs/op, và để pprof chỉ thẳng ra hàm tạo rác thật — thay vì tối ưu nhầm chỗ cả tuần.
Tăng consumer từ 1 lên 8 làm chậm gấp 4,4 lần — hay nhanh gấp 8, tuỳ listener có việc thật hay không
Mặc định của @RabbitListener đo bằng reflection, khác biệt thật giữa Simple và Direct container, và vì sao tăng số consumer có thể làm chậm bốn lần.
Tôi dựng bốn cái bẫy microbenchmark kinh điển — ba cái không hề xảy ra, và cái tệ nhất không có trong sách
Dựng microbenchmark sai rồi đối chiếu với JMH: loại bỏ mã chết, gấp hằng số, thiếu làm nóng, nhiễm bẩn giữa các phép đo. Ba cái không xảy ra như sách vở nói — còn cái cắn thật lại là chuyện đo đúng con số rồi kể sai câu chuyện.
Bật hồ sơ suốt ngày chỉ tốn 3,6% — để 3 giờ sáng có sẵn dữ liệu thay vì phải chờ sự cố xảy ra lần nữa
Đo chi phí thật của JDK Flight Recorder, hồ sơ cấp phát chỉ ra 303MB Integer từ một phép đóng hộp giấu trong dấu ngoặc, và vì sao async-profiler thấy được cả GC lẫn JIT mà JFR không thấy.