并行数据库访问
我创建包含要在 SQL Server 中处理的对象的表 数据库
位于 dbserver 中。
然后，在我的应用程序（c#）中，我使用 SqlDataReader 来迭代所有对象，并在时间 T 内完成。我在我的应用程序中使用多线程和互斥体，它使用相同的 < code>SqlDataReader 对于所有线程。我在serverp1上运行。
然后，为了加快速度，我用一列将对象分为 2 个行或组。
然后，我在 serverp01 中运行 myapp 以获取Rank1 中的对象（SqlDataReader，并使用 select whererank = 1），然后在 serverp02 中为Rank2 中的对象运行 myapp (<代码>SqlDataReader，并选择其中rank = 2）。
我的问题是两个配置花费相同的时间 T 。可能我错了，但应该需要 T/2 时间或接近它。
有人知道发生了什么吗？
I create table with objects to process in SQL Server
The database is in dbserver.
Then, with a my app(c#), I use a SqlDataReader to iterate over all the object, and it makes it in time T. I use multithreading and mutex in my app and it use the same SqlDataReader for all the threads. I run in the serverp1.
Then to make it faster, I separate the object in 2 ranks or groups by a column.
Then I run the myapp in serverp01 for the objects in rank1 (SqlDataReader with a select where rank = 1) and then run the myapp in serverp02 for the object in rank2 (SqlDataReader with a select where rank = 2).
My issue is that it takes the same time T for both configs. May be I'm wrong but it should take T/2 time or close to it.
Somebody has an idea what its happening?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
听起来你受到 IO 速度的限制。当你在 serverp1 上运行这个东西时，CPU 是否已达到极限？如果不是，那么网络或数据库磁盘可能是瓶颈。您可以检查数据库服务器上的磁盘和网络吞吐量，看看它们是否达到特定限制。
如果磁盘是瓶颈，他们会尝试使表行变窄，表中的每一行应该尽可能少的字节。确保您正在查询的表仅包含您实际需要的几列，并且它们尽可能压缩（即使用整数键而不是 varchar 值、不可为 null 等进行高度规范化）。
请记住，即使您只要求几列，也需要将整个页面从磁盘读入内存。页面上可以容纳的行越多，服务器需要读取的页面就越少。
如果网络是瓶颈，那么只需选择您需要的列并将它们设置为窄（int 键而不是 varchar 值）就足够了。
问候 GJ
Sounds like you're being bound by IO speed. When you run the thing on serverp1, are the CPU's maxed out? If not, then probably the network or the DB disks are the bottleneck. You can check the disk and network throughput on the DB server to see if they hit certain limit.
If the disk is the bottleneck, them try to make your table rows narrower, each row in your table should be as few bytes a possible. Make sure that the table you're querying only holds the few columns you actually need and that they're as compressed as possible (i.e. highly normalized with integer keys instead of varchar values, non nullable etc).
Remember that even when you only ask for a few columns, the whole page needs to be read from disk into memory. The more rows you can fit onto a page, the less pages the server needs to read.
If the network is the bottleneck, then only selecting the columns you need and making them as narrow (int key instead of varchar value) should be enough.
Regards GJ