Chờ broker xác nhận từng thông điệp một: chậm gấp 133 lần, mà chẳng an toàn hơn cách nhanh gấp 68
Bốn cách chờ broker xác nhận, đo cạnh nhau. Vì sao cách trực giác nhất là cách tệ nhất, và cơ chế nào làm cách bất đồng bộ nhanh.
#hieu-nang
422 bài viết
Tạm dừng dưới 1 mili giây đổi lấy 79% thông lượng — và vì sao Shenandoah mới là bất ngờ của phép đo
Đo độ trễ theo phân vị trên bốn bộ thu gom. Cái giá thật của tạm dừng dưới một mili giây không nằm ở chỗ bạn nghĩ, và cái tên thắng phần đuôi không phải cái tôi đoán lúc vào bài.
Cùng 400 MB cấp phát, thời gian dừng chênh nhau 10 lần — và vì sao MaxGCPauseMillis=10 làm mọi thứ tệ hơn
Giả thuyết thế hệ đo bằng số thật, bốn bộ thu gom trên cùng một tải với ZGC dừng 0,025ms, và vì sao đặt mục tiêu tạm dừng quá thấp lại phản tác dụng — chi phí GC tỷ lệ với thứ còn sống, không phải thứ đã chết.
'Luôn dùng channel' là hiểu sai châm ngôn nổi tiếng nhất của Go — và số đo cho thấy vì sao
Hỏi 'channel hay mutex nhanh hơn' giống hỏi 'email nhanh hơn hay họp phòng nhanh hơn' — vô nghĩa nếu không biết đang phối hợp việc gì. Đo channel, Mutex và atomic trên cùng khối lượng, và bộ tiêu chí chọn theo cấu trúc bài toán.
Cùng một hàm, chạy lần thứ 500 nhanh gấp 22 lần lần đầu — vì sao mọi phép đo Java một-lần đều vô nghĩa
C1 và C2, các tầng trong log PrintCompilation, ngưỡng 200 và 5000, nội tuyến hoá là vũ khí chính, và một lần khử tối ưu bắt tận tay — kèm chuyện phép đo không cho thấy nó tốn kém.
Đặt -Xmx512m, tiến trình Java chiếm 111 MB khi chưa làm gì — phần RAM còn lại nằm ở đâu
Native Memory Tracking chỉ ra từng vùng bộ nhớ JVM, vì sao 500 luồng đặt chỗ hơn 1GB mà chỉ dùng thật 37MB, năm kiểu hết bộ nhớ với năm thông báo khác nhau, và vì sao container Java chết với mã 137 mà log sạch trơn.