In this example, we will see how we can test the different versions from a web application.

It is a simple page that calls consecutively the different versions, repeatedly (100), and returns the number of milliseconds involved in the whole process.

To increase the impedance of the evaluation, the option is given in a check box, to perform the same query, 100 times, but for all countries.

In any case, the responses will be in approximately the same proportion.

Performance

As you can see, from the point of view of the client application, the final result is faster with EF than with simple code, exactly the opposite of the performance in the first test.

It should be noted, however, that in that first test, the process requested was not the same at all, since data from different tables were required, while, in this case, the data came from only one.

In any case, the comparison could be established with the second publication of this series, which obtains the same data as the latter.

In any case, this last test has some advantage on the part of EF, compared to the rest.

In other words, let us point out conclusions:

• The result is not always as expected. You must try. ALWAYS.

• There is no single way to do things. We must investigate to improve the quality of the applications we generate.

• An unit test of the final set of the application can lead to false conclusions, since other factors, such as communication, data transformation, etc., also influence performance. That is, unit tests are highly valid for testing functionality, but they are not always valid for evaluating performance.

• In fact, most likely, in a real-world application environment, performance results can also change.

Therefore, it is important to monitor the application deployed in production, include counters, logs etc. to have permanent information and be able to periodically evaluate it, to anticipate possible problems.

We’ll see more of this in other posts.

Puedes encontrar la solución completa en este repositorio