Bảng độ trễ đứng yên 13,9 ms trong khi khách chờ 600 ms — chỉ số mặc định nói dối rất thuyết phục
Bật Micrometer cho Vert.x: 23 họ chỉ số có sẵn, một điểm mù lớn không ai nói tới, và sáu chỉ số đáng đặt cảnh báo cho ứng dụng event loop.
Vert.x
Theo dõi riêng chuyên mục này 50 bài viết
getLock chạy ngon trên máy bạn, ném lỗi ngay khi lên cụm — cái khoá hỏng đúng lúc cần nó nhất
Đo ba kiểu chia sẻ dữ liệu của Vert.x trong và ngoài cụm: LocalMap 26 ns, AsyncMap cụm 49,5 µs, và LocalMap sao chép lúc get chứ không phải lúc put.
Cụm Vert.x mặc định gửi lưu lượng cho node chết suốt 60 giây — và hai API 'toàn cụm' ném lỗi lúc chạy
Dựng cụm Vert.x ba node bằng Hazelcast 5.5: thời gian gia nhập, chia tải event bus, dữ liệu chung sống sót qua mất node, và hai API trong lõi Vert.x không chạy được.
Cãi nhau xem lớp bọc reactive nào nhanh hơn — trong khi nó chỉ chiếm 0,15% thời gian một request
Viết cùng một luồng gọi ba dịch vụ bằng bốn phong cách rồi đo cả bốn. Thông lượng như nhau, chi phí lớp bọc chỉ vài chục nano giây, khác biệt thật nằm ở chỗ khác.
Đọc theo luồng còn tốn RAM hơn nạp hết vào bộ nhớ — cho tới khi tôi thêm bảy dòng
Nối RowStream PostgreSQL vào HTTP response với 20 client đọc chậm. Ba cách viết, ba kết cục: nạp hết OOM 5 lần, streaming trần OOM 8 lần, streaming có áp lực ngược 0 lần và tốn ít hơn 18 lần.
find() đọc hết vào RAM chạy ngon suốt — tới ngày bảng đủ lớn thì OOM hạ cả tiến trình
Vert.x Mongo client trên MongoDB 7 thật: truy vấn thiếu chỉ mục chậm 116 lần, bulkWrite nhanh 23 lần, và find() chết OOM ở đúng chỗ findBatch sống khoẻ.