Some errors that should be discovered before the program is released

Writing code that affects performance or has bugs during software development is an unavoidable problem.
However, if you can find out these problems before the program is released (in the self-testing or testing phase), I think they are acceptable.

Today, we will introduce a method that can be used to identify problems that are easily overlooked during website development.
The method to be introduced requires the use of a tool such as Fiddler,
I will demonstrate how to use Fiddler to discover 404 errors and large response output problems.
I think these two problems are too low-level, so I designed this method and wrote this blog. I hope you will like it.

I found that many people do not care about these two types of problems (404 errors and large response outputs), as if they would not have any impact on a website.
Is that true?
I think: If your website program has a small user access volume, you may indeed ignore them.
Otherwise, I suggest you correct them. I will explain the harm to them below.

Error 404

I always think that 404 is not just a number, but too many 404 will also affect the performance of the program.

By analyzing 404 errors, I found that most 404 errors are related to the reference of some resource files,
For example, if the code references a CSS or JS file that does not exist, the normal display of the page may not be affected when these 404 errors occur,
Therefore, such errors won't attract the attention of some developers.
In addition, many people prefer to copy and paste, resulting in more and more such errors.

Why do I say [too many 404 errors will affect performance?
When a 404 error occurs, IIS does not return such a number, but a complete HTTP response. The response content is a normal webpage.
The 404 error page length varies with IIS versions. The default 404 error page length of IIS6 exceeds 2 K, and the default error page of IIS7.5 exceeds 8 K.
Although this response does not seem big, but because the request is unsuccessful, each time you open these pages, the request will be re-initiated, and the number will increase.
In turn, we can think about: If the resource files to be referenced exist, these files only need to be requested once, And the browser will cache them,
You do not need to initiate a request every time.
In this way, the client reduces the number of requests, the server reduces the connection pressure, and the network traffic wasted by meaningless 404 responses also disappears.
Therefore, an excessive number of 404 requests is a vicious circle,
It prolongs the page display time (front-end), puts pressure on the server, and wastes network resources.

Large response output

It should be easy to understand the large response output, that is, the results returned by the server are too large.
What does [large response output] mean.
1. Is it slow to display a large web page in a browser?
2. Does [A large web page] take a long time for network transmission?
3. Does it take a long time for the server to generate a large web page?
4. If the results of this [large web page] come from the database query results, will it put a lot of pressure on the database?

In this case, a typical scenario may be caused by an SQL query: select * from XXX where name = @ name
In the early stages, there may be very few records in the XXX table. Maybe at the design stage, I did not expect that the name would have a lot of data to be copied,
Alternatively, when testing in a local environment, the network speed is not a problem at all, and the browser's rendering speed delay is not noticed.
We can imagine: What will happen if such a program is deployed on the Internet?

There are two possible scenarios for [large response outputs:
1. Add a large object to ViewState.
2. display a tree structure or a query without the where condition (all of which are non-Paging)

When these three situations occur, do you think the performance is acceptable? Will the user be satisfied?

Use Fiddler to discover these problems

I have explained in detail the dangers of second-class low-level errors. I will discuss how to discover them as soon as possible.
I think many people should have used Fiddler, which can easily let us know the Request/Response of each Request initiated by the browser,
It is usually used to debug programs.

In Fiddler, 404 error requests are highlighted in red letters, and the response length of each request is displayed separately,
It seems that directly using Fiddler can also easily detect 404 errors and large response output problems.
However, when too many pages are accessed, Fiddler displays a large number of request records,
Therefore, it may take some time to discover low-level problems.

To solve this problem, I have defined two rules for Fiddler:

As long as you open them, the second-level low-level problems mentioned above can be easily discovered:

Note: Only requests that meet the rules are displayed here (requests with low-level issues ).

What should I do?ReasonablyHow can I use this method?
1. If you are a developer, open Fiddler during self-testing and select the two rules I have defined,
2. If you are a tester, open Fiddler during the test and select the two rules I have defined,
3.Then, do what you should do at ordinary times,......
4. After the test is complete, check the Fiddler window and see if there are any records. If yes, you will find low-level problems.

Therefore, I don't think this method will put too much burden on developers and testers,
After all, this method will not add any burden to their tests,
You only need to open Fiddler and take a look at it after the test is completed. That's all.

Some people may think that the IIS logs on the server can also find these two types of problems.
Yes, I know that these problems can also be found by analyzing IIS logs,
However, is it too late to analyze IIS logs?
Have you ever wondered: has this problem affected users?
On the contrary, is it better not to allow users to [experience] these problems?
In other words: Do you want to release a defective program?

How to customize Fiddler filter rules

If you want to customize the Fiddler rules, we recommend that you install the Fiddler plug-in: Syntax-Highlighting.

Then, open the custom rule window:

The Fiddler rule code is displayed for you to modify:

In this window, the right side shows some object types that can be used in custom rules,
And their fields (green), attributes (blue), and methods (black ).
We can refer to this information when writing rules.

Note: This rule file is saved in: x: \ My Documents \ Fiddler2 \ Scripts \ CustomRules. js

Remember that I added two custom Rules under the Rules menu of Fiddler?
The code for defining the rule menu is in the front (find Chinese characters and find the last 4 lines of code ).

After defining the menu, you also need to add some processing code in the OnBeforeResponse method:

Finally, let me say:
If you do not want to release defective programs and do not want to rework later,Try the method described in this article.

Click here to download my CustomRules. js (Fiddler version 2.4.1.1)

If you believe that reading this blog has some benefits, click 【Recommendation] Button.
If you want to discover my new blog more easily, click 【Follow Fish Li].
Because my enthusiasm for writing is inseparable from your support.

Thank you for reading this article. If you are interested in the content of my blog, please continue to follow up on my blog. I am Fish Li.