A simple. Net log Writing Method-Possible improvements

A friend asked me the following when commenting yesterday:CodeWhat are the problems in Web development?

 
Public VoidLog (StringMSG) {system. Io. file. appendalltext (server. mappath ("~ /Log.txt"), MSG );}
 

There are too many points to say here... so I have to open a new one.ArticleAnd only focus on

 

Function

1. Thread Security

Asp.net is a native multi-threaded framework, so the log class must be safe with multiple threads. This class library uses the file class to append logs, and this part is not thread-safe, here is a bug (Windows resource. for example, multi-thread synchronization is required for network files in Asp.net)

Improvement Solution: the simplest method is to add lock (Other improvement solutions will be provided later)

2. The method is not input.

All public input parameters must be checked for input values. If they are null or empty, do not call the file class to write logs, this will improve the performance and robustness (the most common problem is that the object is not referenced to the instance of the Set object)

Solution: Check the input value

3. IIS default account for server. mappath ("~ /Log.txt ") This path has no write/modify permissions (You may find this problem in the production environment)

Solution: Configure IIS account permissions or configure a directory with permissions (recommended by the latter)

4. Try catch is not implemented (whether try catch is required, the actual situation should be considered)

In general, the log writing method will not throw an exception. If no catch (internal or external catch is allowed, I personally recommend external catch) will causeProgram/Logical abort

Avoid suspending the business logic due to non-core logic such as logs.

Security

1. Writing logs to the root directory of the website is a high-risk action. First, additional permissions are required, and second, program files may be written (for example, some people write logs to the aspx file)

Solution: configure a log directory outside the root directory of the website

Performance

1. Use asynchronous writing to improve performance

That is, write the queue and regularly refresh the queue to the data file. Due to the write bottleneck, the performance will be much better. Of course, if a sudden power failure occurs, there is a possibility of data loss (small probability events, we consider performance more than this small flaw)

This is also my favorite method, but it requires developers to have a high level, and the solution is complex and has a long development time... the only benefit is high performance .... short log writing Response Time

2. Use other log writing methods

For example, CLFs windows2008 began to support common log file system,

If you do not open a filestream in Windows 2008 and save it in a local variable, do not open or close the file every time you write a log.

3. Replace the instance method with the static method (or at least call instead of callvirt) [Use specific analysis]

Scalability and maintainability

1. The log path should not be the server. mappath ("~ /Log.txt ") This log can only be used by web programs, but not by Windows form, server applications, and other applications.

2. Log paths should not be written to death, but should be configurable. At least there should be an independent member storage (there must be a lot of reloads to write logs as expected)

3. The basic class libraries such as log classes generally use static methods, so do not use a new one each time. [use specific analysis]

4. If possible, a third-party class library, such as log4net, is a good solution.

5. If the code is in the production environment, this name and comments are completely unqualified ..

6. It is not recommended to use a full namespace (too many texts... haha)

 

When designing a log writing method, we always need to consider: (the priority is related to the project type)

1. Can the team have enough capabilities to complete?

2. Development Time

3. complexity (resulting in increased maintenance costs)

4. Program Stability

5. Performance

6. Existing technical systems and class libraries (reusability or something ...)

7. Other factors that cannot be thought of at the moment (for example, the big boss says you want to do this... Okay, you're the boss, you have the right say, haha just kidding)

 

It may not be comprehensive enough. After all, the time is limited... too busy recently.

Please help me with any omissions

 

The specific code is not provided. Generally, the logs we make are company-level logs, and all servers will be transmitted to the log cluster server over the network. This is totally different from the simple file log system.

Simple file logs will also be written in a simple way... (in some projects, the simplest is the most suitable ,)

The project type and development time are required. We will use a third-party logstore such as log4net to make it a little complicated.

The simplest log may have been written in a few minutes. The most complex log has been written for several months .......