Ngay cả với slf4j, bạn có nên bảo vệ quá trình ghi nhật ký không?

Question

Giúp tôi tham gia một cuộc tranh luận ở đây .. :)

Trang web slf4j ở đây http://www.slf4j.org/faq.html#logging_performance cho biết rằng do ghi nhật ký tham số, bảo vệ ghi nhật ký là không cần thiết. I E. thay vì viết:

if(logger.isDebugEnabled()) { 
    logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i])); 
} 

Bạn có thể nhận được ngay với:

Object entry = new SomeObject(); 
logger.debug("The entry is {}.", entry); 

Đây có phải là thực sự không sao, hay nó phải chịu sự (mặc dù thấp hơn) chi phí của việc tạo ra chuỗi tĩnh đã vượt qua phương pháp dấu vết ..?

Answer 1

tôi sẽ cố gắng đưa hai xu của tôi từ một góc độ

gì chính xác là vì lợi ích của khai thác gỗ parametrized?

Bạn chỉ cần hoãn toString() gọi và nối chuỗi cho đến khi thực sự cần thiết, đó là khi bạn thực sự cần phải đăng nhập vào tin nhắn. Điều này tối ưu hóa hiệu suất khi hoạt động ghi nhật ký cụ thể đó bị tắt. Kiểm tra source code for SLF4J nếu không chắc chắn.

Ghi nhật ký tham số có giúp bảo vệ vô dụng trong mọi trường hợp không?

số

Trong đó trường hợp sẽ bảo vệ khai thác gỗ được sử dụng?

Khi có các hoạt động đắt tiền tiềm năng khác.

Ví dụ (trong trường hợp hoạt động khai thác gỗ đặc biệt này bị vô hiệu hóa), nếu chúng ta có không bảo vệ khai thác gỗ

logger.debug("User: {}", getUserService().getCurrentUser()); 

1. Chúng tôi sẽ trả chi phí từ obj = getUserService().getCurrentUser()
2. Chúng tôi sẽ tiết kiệm chi phí từ "User name: " + obj.toString()

Nếu chúng tôi sử dụng khai thác gỗ gác:

if (logger.isDebugEnabled()) { 
    logger.debug("User: {}", getUserService().getCurrentUser()); 
} 

1. Chúng tôi sẽ trả chi phí logger.isDebugEnabled()
2. Chúng tôi sẽ lưu chi phí từ obj = getUserService().getCurrentUser()
3. Chúng tôi sẽ tiết kiệm chi phí từ "User name: " + obj.toString()

Trong c sau ase, chúng tôi sẽ tiết kiệm cả chi phí ở mức giá kiểm tra isDebugEnabled() hai lần khi hoạt động ghi nhật ký cụ thể này được bật.

LƯU Ý: Đây chỉ là một ví dụ, không cố gắng tranh luận các thực tiễn tốt/xấu ở đây.

Answer 2

Xin đừng sử dụng câu lệnh if, bởi vì mỗi khi tôi nhìn vào mã như thế này

if (logger.isDebug()) { 
    logger.debug("Of course it's debug {}", sadFace); 
} 

tôi khóc.

Tôi hy vọng rằng chi phí tạo chuỗi tĩnh quá thấp đến mức không đáng kể cho 99% người dùng.

Answer 3

Viết và đọc tất cả các số if(logger.isDebugEnabled()) {} có thể sẽ tốn nhiều thời gian khi chúng tiết kiệm cho bạn.

Tất nhiên, gọi phương thức nhật ký không miễn phí nhưng điều này cũng đúng cho việc gọi isDebugEnabled(). Vì vậy, bạn đang trả tiền nhiều hơn cho mỗi câu lệnh đăng nhập đang hoạt động nếu bạn sử dụng mẫu này (vì khung ghi nhật ký sẽ kiểm tra mức hai lần).

Nó cũng cắt mã.

Trong thực tế, tôi đã không tìm thấy hình phạt hiệu suất đủ lớn để làm phiền.

Nếu ghi nhật ký quá chậm đối với bạn, hãy viết ứng dụng không chặn để đẩy sự kiện nhật ký vào hàng đợi mà không chỉ một vài kiểm tra và sử dụng chuỗi nền để xử lý chúng.

Bối cảnh: Các ứng dụng chuẩn đều được đồng bộ hóa để đăng nhập vào ứng dụng đa luồng có thể gây ra rất nhiều tạm dừng nhỏ trong đó tất cả các chuỗi chờ thông điệp tường trình được ghi vào một tệp.

Answer 4

Vấn đề với một tuyên bố khai thác gỗ như thế này:

logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i])); 

là nó sẽ làm được rất nhiều việc phải nối giá trị vào một String, sau đó được không bao giờ sử dụng nếu debug logging tắt. Vì vậy, trong trường hợp đó, nó là có lợi để kiểm tra xem gỡ lỗi đăng nhập là trên trước khi thực hiện dòng này. Khi bạn chỉ chuyển các tham số:

logger.debug("The entry is {}.", entry); 

thì không cần thiết phải xây dựng String không bao giờ được sử dụng và séc là không cần thiết; chỉ cần chuyển các đối số cho một phương thức không có chi phí rất cao.

Lưu ý rằng nếu bạn có biểu thức tương đối đắt đối với các đối số trong câu lệnh ghi nhật ký, thì có thể vẫn có lợi khi kiểm tra mức ghi nhật ký trước.

Answer 5

Bộ bảo vệ không được sử dụng do tạo chuỗi.

Thay vào đó, nó thường được sử dụng để tránh một biểu thức đối số có khả năng tốn kém, chẳng hạn như entry[i].retrieveExtendedDebugInformation().formatNicely(). Đối với điều đó, logback đảm bảo đối số được đánh giá chỉ khi thông điệp tường trình được in thực sự, trong khi log4j luôn luôn đánh giá đối số trước khi gọi debug().

Ở đây, ứng cử viên duy nhất là String.valueOf(entry[i]), không đắt lắm, vì vậy bạn có thể đưa ra lý lẽ rằng bảo vệ này hoàn toàn không cần thiết.