Cùng một phép cộng ma trận, đổi thứ tự hai vòng lồng là chênh 16,9 lần vì cache. Tôi tưởng compiler chịu thua chuyện này. Đo ra -O3 tự đảo thứ tự cứu số nguyên (về 1,0×), nhưng với float thì bó tay — vì đảo thứ tự cộng làm đổi kết quả làm tròn. Ranh giới nằm ở một chỗ rất tinh vi.
Ghép hai vòng thành một để bớt overhead thì luôn nhanh hơn? Tôi đo và bất ngờ: ghép hai vòng cùng đọc một mảng nhanh 1,8 lần, nhưng ghép hai vòng mỗi vòng ghi một mảng lại chậm 2,75 lần. Thứ quyết định không phải số vòng, mà là số luồng bộ nhớ đan xen trong thân — một bài toán locality.
200.000 dòng log 30,75 MB vào Loki còn 5,40 MB trên đĩa (nén 5,69 lần), chỉ mục vỏn vẹn 0,42%. Đó là toàn bộ triết lý Loki gói trong một con số: trả tiền chỉ mục cho 15 luồng, không cho 30 MB văn bản. Nhưng thư mục WAL 32 MB suýt làm tôi kết luận Loki phình 1,22 lần thay vì nén 5,69 lần.
SQL không phải nơi duy nhất trộn dữ liệu vào mã. Tôi dựng lại cùng lỗ hổng trên lệnh hệ thống (bộ lọc quên ký tự xuống dòng để lọt) và LDAP (mật khẩu '*' thành admin không cần biết mật khẩu). Cùng một lỗ mặc ba bộ quần áo, cùng một cách chặn: tách dữ liệu khỏi mã.
Span db.query nói một con số, pg_stat_statements nói một con số khác cho đúng truy vấn đó, và chúng lệch nhau gần chục lần. Không cái nào sai — chúng đo hai thứ khác nhau, và cái hiệu của chúng mới là con số quyết định việc tối ưu SQL của bạn có ích hay hoàn toàn vô nghĩa.
Một vòng lặp curl chạy chậm vẫn thử được 2.600 mật khẩu trong 70 giây khi route đăng nhập không chặn gì. Bốn chiến lược giới hạn kéo nó xuống 10, rồi 5 — nhưng mỗi cái mở ra một điểm mù riêng, trong đó có một khe hở biến chính lớp phòng thủ thành công cụ DoS.