如何处理一次多个数据连接 [英] How to handle multiple data connections at once
问题描述
我有一个ASP.NET MVC应用程序，它从多个数据库中收集数据。
I have an ASP.NET MVC application which gathers data from multiple Databases.
该数据库保存了各种网站信息，并为每一个新网站，我们有一个新的数据库。每个站点的数据库连接在两个点，从网站，然后从总部。
The databases hold information for various sites and for every new site we have a new Database. The database for each site is connected at two points, from the site and then from HQ.
一个Web应用程序更新从该网站每分钟的数据数据供应到HQ（通过其他Web应用程序）的每一分钟。有时，应用程序的响应很慢，从我的调查，可能是因为连接池启动迅速填满。
A web application updated data every minute from the site and the data is is served to the HQ (via another web application) every minute. Sometimes the application response is very slow and from what I have investigated, it may be because the connection pool starts filling up swiftly.
我要问的是这样的应用程序，在那里我可以把它弄出来的最佳性能的最佳方法。任何指导是值得欢迎的。
I want to ask what is the best approach to such application, where I can get the best performance out of it. Any guidance is welcome.
推荐答案
如何提高对数据库的Web应用程序的性能，实际上取决于你的体系结构。但也有一些通用的规则，你应该始终遵循：
How to improve your web application performance regarding to database, really depends on your architecture. But there are some general rules which you should always follow:
-
查看线程饥饿：在Web服务器上，.NET框架
维护线程池被用来服务ASP.NET
要求。当一个请求到达时，从池中的线程是
出动来处理该请求。如果该请求被处理
同步，处理请求的线程被阻塞
同时请求被处理，该线程不能服务
另一个请求。
Check about thread starvation:On the Web server, the .NET Framework maintains a pool of threads that are used to service ASP.NET requests. When a request arrives, a thread from the pool is dispatched to process that request. If the request is processed synchronously, the thread that processes the request is blocked while the request is being processed, and that thread cannot service another request.
这可能不是一个问题，因为该线程
池可以大到足以容纳许多阻塞的线程。
然而，线程在线程池的数量是有限的。在
该处理多个同时长期运行大型应用程序
请求所有可用线程可能被阻止。这种情况是
被称为线程匮乏。当达到该条件时，Web
服务器排队的请求。如果请求队列已满时，Web
服务器的HTTP 503状态拒绝请求（服务器太忙）。
This might not be a problem, because the thread pool can be made large enough to accommodate many blocked threads. However, the number of threads in the thread pool is limited. In large applications that process multiple simultaneous long-running requests, all available threads might be blocked. This condition is known as thread starvation. When this condition is reached, the Web server queues requests. If the request queue becomes full, the Web server rejects requests with an HTTP 503 status (Server Too Busy).
有关线程饥饿的最佳方法是使用异步
方法是指这里了解更多信息。
for "thread starvation" the best approach is using "Asynchronous Methods". refer here for more information.
请尝试使用块为您的DataContext，处置他们与他们完成后立即使用。
Try to use using block for your datacontext, to dispose them immediately after finishing with them.
在庞大的交易数据量：你应该检查你的code。
可能是你使用太多数据而不需要他们。对于
例如，你转让所有对象，你可能只需要一个
对象的属性。在这种情况下使用投影（请参阅here对于
一个例子）。
Huge data amount in transaction: you should check your code. May be you using too much data without need to all of them. For example you transfer all object which you may need just one properties of object. In this case use "projection"(refer here for an example).
您也可以使用延迟加载或你预先加载基地
场景。但请注意的是，这些都不是法宝
每一个场景。在某些情况下，懒加载提高性能和
别人预先加载使事情更快。这取决于你
深刻理解这两个词，也是您的问题的情况下
您code和您的设计。
Also you may use "lazy loading" or "eager loading" base on you scenarios. But please be noted that none of these are magic tool for every scenario. In some cases "lazy loading" improve performance and on others "eager loading" makes things faster. It depends to your deep understanding of these two terms and also your case of issue, your code and your design.
检查您的架构，看看你有什么瓶颈。一个
控制器，其被调用太多，处理大量的一个方法
具有大量数据的对象，一个表，其中接收数据库
请求不断，所有的都是瓶颈人选。
Check your architecture to see do you have any bottleneck. A controller which gets called too much, a methods which handles lots of objects with lots of data, a table in database which receives requests continuously, all are candidates for bottle neck.
UES兑现数据时，适用于大多数请求的数据。但同样
明智地使用兑现，并根据您的情况。错兑现品牌
您的服务器很慢。
Ues cashing data when applicable for most requested data. But again use cashing wisely and based on your situation. Wrong cashing makes your server very slow.
如果你认为你的速度问题完全是你的数据库上，最好的办法是使用SQL分析工具来找出哪些点你有严峻局面。也许重新设计的您自己的表可能是一个答案。尝试尽可能多的独立阅读和写作表。分离可以通过创建相应的视图来完成。同时检查这清单监控数据库。
If you think your speed issue is completely on your database, the best approach is using sql profiling tools to find out which point you have critical situation. Maybe redesign of your own tables could be an answer. Try to separate reading and writing tables as much as possible. Separation could be done by creating appropriate views. Also check this checklist for monitoring your database.
这篇关于如何处理一次多个数据连接的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
