高流量连接的最佳数据库连接字符串?

发布于 2024-10-22 08:45:50 字数 126 浏览 2 评论 0原文

我只是想知道,连接字符串中应该采用哪些参数或属性才能处理高流量的企业应用程序? 像一般情况一样,我们使用服务器、初始目录、用户 ID、密码。有时我们会添加超时,在某些场景池等中。但我不知道除了上述之外,我应该采用哪些属性作为我的常见做法。

I just want to know, What parameters or attributes should be taken in connection string so as to handle high traffic enterprise applications?
Like in general we use server, initial catalog, userid, passwd. Some times we add timeout , and in some scenario pool etc. But i don't know what attributes should i take in as my common practice apart from above.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

长不大的小祸害 2024-10-29 08:45:50

无论如何,请确保在整个应用程序中重复使用相同的连接字符串,以便启用连接池。

In any event make sure you reuse the same connection string throughout the app so as to enable connection pooling.

别挽留 2024-10-29 08:45:50

你肯定不想保持连接。可能希望转向客户端数据集加载,以便用户承担数据负载,但您可能想再次通过虚拟化检查数据库场配置。

如果您正在谈论超过 100 万次点击,那么创建带有负载均衡器的数据库场将是您的最佳配置。另一种途径是将数据库请求与应用程序分离,并通过 Web 服务类型接口来管理连接。

如果点击量少于 100 万次,那么最好通过应用程序管理资源,但最好有一些优秀的 dba 在必要时管理管道和节流。

you definitely dont want to persist the connection. probably want to move towards a client dataset loading so the users carry the load of data but then again you may want to review your Database farm configuration with virtualizing.

if you are talking about well over 1 million hits, creating a DB farm with a load balancer would be your best configuration. Another path is to seperate your DB request from the application and through a Web Service type interface to manage the connections.

if less than 1 Million hits, then its best to manage the resources through the application but better have some good dba's to manage the pipes and throttle when necessary.

じее 2024-10-29 08:45:50

如果大量数据是只读且可重复的,那么缓存可能是您最好的朋友。

If a lot of the data is read-only and repeatable, caching can be your best friend.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文