Geek Answers Handbook

Is connecting to a database even more expensive?

I am relatively new to ASP.NET and just building a second application for real-time web applications.

When I studied ASP.NET a year ago, I was told "This is a more expensive connection and data capture from the database, so the maximum possible connection and reuse of the received data." The reasons given are:

  • First you need to connect to the database server.
  • Parallel connections on the BB server will be less compared to IIS.
  • Use a disabled architecture so that the connection can be closed in the near future (of course, there are other flexibilites), etc. etc.

And when my research expanded, I found out other measures for storing data after receiving it from the database, through postback. But now Iā€™m studying one after another that they are more expensive than connecting to a database. as...

  • Session variables: memory bubbles with number of users
  • View State: The encryption and movement process makes it more expensive.
  • Application variables: not very useful in any circumstances.
  • Cache: (I know them, but have not used them so far).

Also Oflate, Iā€™m repeatedly recommended not to save the extracted tables in the session, view the state, etc., but connect to the database and capture it again with each postback.

And looking at it in the light of SQL Server-based session management, where the platform itself used the database to store the session. I feel I have to wean my initial learning and perception about connecting to a database.

What do you say ???

Any other suggestions / tips are also welcome.

thanks

+4
source share
6 answers

As a rule, you say that this is true, but the connection pool takes up a lot of connection overhead.

When using the connection pool, you have a collection of connections that are used when queries arrive in the database. These compounds are then recycled for later use. I explain this very poorly, but, as always, wikipedia has some good information to get you started.

http://en.wikipedia.org/wiki/Connection_pool

If you are looking for a silver bullet, for example, always use xxx, unfortunately, it is not. You will need to evaluate each scenario and make a determination there.

For example, if you have a slow connection to the database server, you probably want to cache the received data in order to minimize the number of calls you make in the database.

On the other hand, if you have a system with limited resources, calling the database can often be a valid option.

You will need to evaluate these situations for each system that you are developing in order to maximize the capabilities of your software, but with the right architecture, it is usually quite easy to adapt the system to any constraints that you encounter.

+11
source

A connection pool can significantly reduce the cost of connecting to a database. The connection pool is ADO.NET technology (I think), which essentially will restore the connection to the database as long as the connection string is the same. I would also be careful in caching data if you do not know that your cached data is pretty static.

So, in general, I would say that you should not worry about the cost of establishing connections with the database. Most N-Tier, disconnected applications make frequent database connections. I do not think you need to worry about this.

Randy

+2
source

Pooling is currently reducing overhead.

What I found are round trips that kill performance, usually due to ORM :-)

+2
source

Communication with the database will usually be slow compared to anything in the local RAM. Yes, storing things in RAM leads to the fact that the use of memory becomes a balloon, as the number of simultaneous users increases ... right? This is what scales for multiple machines. All this is a compromise. You need to see what you are trying to accomplish and choose what to trade.

+1
source

Using a connection pool is a good idea. When you need to get data from a database, JSON is a good approach. we should try to avoid the state of the session and presentation, since this leads to a decrease in application performance many times.

0
source

I agree with many comments already made. A connection pool means that a new connection to the database does not need to be opened if it is in the pool and available.

Having said that, be careful when accessing the database again, especially for data such as the main list that can be cached. Object-oriented code for accessing the database is known for having too much database activity, most of which can be prevented with little planning. Use the ASP.NET cache application to store static data that does not change often (and when this happens, clear and reload the cache).

I am not a fan of session variables, as they are akin to global variables and make sloppy coding. They also do not fit into the stateless programming model adopted by REST, Azure, etc. Only my 2 cents.

Be careful with overloading Viewstate, but if you keep it small I don't see a problem with it.

-Krip

0
source

More articles:


All Articles