I need to put a customized logging system of sorts in place for an ASP.NET application. Among other things, it has to log some data per request. I've thought of two approaches:

Approach #1: **Commit each entry per request.** For example: A log entry is created and committed to the database on every request (using a transient `DbContext`). I'm concerned that this commit puts an overhead on the serving of the request that would not scale well.

Approach #2: **Buffer entries, commit periodically.** For example: A log entry is created and added to a concurrent buffer on every request (using a shared lock). When a limit in that buffer is exceeded, an exclusive lock is acquired, the buffered entries are committed to the database in one go (using another, also transient `DbContext`, created and destroyed only for each commit) and the buffer is emptied. I'm aware that this would make the "committing" request slow, but it's acceptable. I'm also aware that closing/restarting the application could result in loss of uncommitted log entries because the AppDomain will change in that case, but this is also acceptable.

I've implemented both approaches within my requirements, I've tested them and I've strained them as much as I could in a local environment. I haven't deployed yet and thus I cannot test them in real conditions. Both seem to work equally well, but I can't draw any conclusions like this.

**Which of these two approaches is the best?** I'm concerned about performance during peaks of a couple thousand users. Are there any pitfalls I'm not aware of?