Handler Kafka làm việc nặng ngay trên event loop: HTTP tụt 375 lần, không một dòng lỗi
Vert.x Kafka client trên broker 3.9 thật: gửi bất đồng bộ nhanh hơn chờ từng bản tin 129 lần, và handler chạy ngay trên event loop là chỗ hỏng lớn nhất.
#java
184 bài viết
Nới pool từ 20 lên 200: p50 đẹp gấp đôi, p99 sụp gấp 4,7 lần — và biểu đồ của bạn chỉ khoe nửa đẹp
Đo tác động của kích thước pool lên độ trễ đuôi trên PostgreSQL thật, cách withTransaction lùi lại, cursor bắt buộc nằm trong giao dịch, và cache prepared statement không cho khác biệt nào.
Reactive vs JDBC hoà nhau từng req/s — vì cả hai nghẽn ở cùng chỗ, và reactive mua thứ không nằm trong bảng
Nối PostgreSQL 16 thật bằng Vert.x PG Client và JDBC ở cùng mức đồng thời. Thông lượng ngang nhau, khác biệt nằm ở số luồng và bộ nhớ. Luồng ảo chậm nhất.
Service proxy làm lời gọi trông như hàm thường — nhưng nó vẫn là một chặng event bus, đắt gấp 20 lần
Service Proxy của Vert.x sinh mã từ interface. Đo chi phí thật so với gửi event bus bằng tay, kèm cái bẫy hâm nóng JIT đã làm phép đo đầu tiên sai hoàn toàn.
runOnContext trông như đã quay về đúng chỗ — nhưng bạn về 'một' context, không phải 'cái' context
Đo xem context local của Vert.x còn sót lại ở chặng bất đồng bộ nào, bốn chỗ nó rơi mất, cách vá từng chỗ, và chi phí thật của việc mang ngữ cảnh đi khắp nơi.
Một hạ nguồn chậm bóp chết đường nhanh chẳng liên quan — thông lượng rớt 11 nghìn lần, log 0 lỗi
Đo hiện tượng cạn pool khi hai phụ thuộc dùng chung một WebClient, rồi vá bằng hai kiểu vách ngăn. Kèm cùng cái bẫy đó trên pool luồng chặn của Vert.x.