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.
Bài viết mới nhất
Tổng 1741 bài
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ẻ.
Benchmark đầu tiên báo 72 triệu lệnh/giây trên Redis đơn luồng — con số bất khả thi cứu cả bài
Vert.x Redis client trên Redis 7.4 thật: gom lệnh thành lô nhanh gấp 73 lần gửi từng cái, maxPoolWaiting mặc định 24, và cách một benchmark im lặng đo nhầm thất bại.