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ờ.
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ờ.
Vì sao hai ngoại lệ trong cùng một @RabbitListener lại có số phận ngược nhau, và phép đo cho thấy RepublishMessageRecoverer đính 1.688 byte header lên một thân 8 byte.
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ì.
Ảnh golang đầy đủ là đóng cả lò nướng và bột sống vào thùng chỉ để giao một chiếc bánh. Ba cách đóng gói đo bằng số, vì sao scratch chạy được, và bốn thứ phải tự bỏ vào cái hộp rỗng.
Đo chi phí thật của bốn cách gọi log (nhanh chậm 20 lần), so log văn bản với JSON, và ba lăng kính quan sát — log, chỉ số, truy vết — mà thiếu một cái là mù một nửa khi hệ thống hỏng.
Sự kiện ứng dụng nghe như hô một thông báo rồi đi, nhưng thật ra là bạn đi từng bàn vỗ vai từng người, đứng chờ, và ai làm rơi thì bạn dừng cả errand. Chạy đồng bộ, @TransactionalEventListener, và khi nào cần hàng đợi thật.