我正在開發一個Web應用程序，它必須支持大量的同時請求，並且我希望保持足夠快。我現在要實現一個日誌記錄策略，我要使用log4net，但是......我該如何登錄？我的意思是：日誌記錄策略與性能
在需求顯示，應用程序應該緩存每個請求的一些事情，我害怕性能的影響。
乾杯。
記錄/追蹤非常有價值 - 至少你應該記錄錯誤，否則你永遠不會知道它們。大多數日誌API允許你打開和關閉你需要記錄的詳細程度。
不要擔心性能，直到它成爲一個問題。這並不像你正在製造月球火箭，而是想通過測試來看看它能承載多少重量 - 它只是代碼，刪除日誌溢出你的日誌並重新編譯，如果它成爲一個問題。
我會說你在擔心性能早期在一塊，使用log4net的方式，很容易關閉以後或定製（例如：使用conf文件，定義日誌級別NONE，ERROR，WARN ，調試，信息，所有，VERBOSE等），
然而，你的兩個其他問題是有效的，對於問題2，我會去純文件，因爲他們可以很容易地讀取和訪問而不是數據庫。寫入文件結尾的性能也比數據庫好。
是的，因爲nos聲明log4net是線程安全的。
一個一般性的建議，如果你的項目很大，並且你希望有如上所述的可配置日誌級別的任何希望，那麼你真的需要就你的團隊中的編碼標準達成一致，登錄不同級別。
我完全同意hhafez和nos所說的。您將使用日誌記錄包而不是試圖推出自己的產品。這是更清潔，更容易得到正確的。記錄到文本文件比管理數據庫記錄更容易管理長期（典型的項目技能集），但如果您計劃對報告數據進行任何複雜的分析，有時只需將其存儲在數據庫中就更容易了。
如果調試是您實現日誌記錄解決方案的既定目標之一，那麼您必須事先標準化所有日誌級別並將其作爲代碼審查過程的一部分。在粒度上有足夠的差異，以便您可以通過進入下一級逐漸增加報告深度。對PROD問題進行故障排除非常令人沮喪，沒有足夠的日誌信息來查看問題，然後增加到下一級的日誌記錄，並且使日誌完全淹沒，以至於無法看到樹木的森林（和由於音量，您的日誌每5分鐘滾動一次）。我見過它發生。
在大多數文本文件記錄的情況下，性能不應該成爲問題。數據庫日誌記錄有點棘手。做一個插入只比附加到文本文件稍強一點，但是它是每單位時間的量，這使得它在規模上更加醜陋。另外，如果你打算做任何離線日誌分析，你應該選擇一個易於擴展的日誌文件格式，如果你需要在日誌中添加內容，不需要對分析代碼進行巨大的修改。遠離嵌套的多部分消息結構。解析這些會變得很痛苦。
祝你好運！