我应该如何估计 SQL Server 2005 数据库的硬件要求？
我们被要求为尚未构建的 ASP.NET Web 应用程序指定生产数据库硬件。
我们需要确定的规格是：
- 数据库 CPU
- 数据库 I/O
- 数据库 RAM
以下是我当前正在查看的指标：
- 预计未来点击次数 网站 - 基于当前 IIS 日志。
- 估计最坏情况峰值负载 网站。
- 估计每个数据库查询的数量 页，平均。
- 网络场中的服务器数量 将访问数据库。
- 缓存来自数据库的轮询流量 （使用 SqlCacheDependency）。
- 估计数据缓存未命中。
- 估计每日数据库事务数。
- 可接受的最大页面呈现时间。
我们还应该考虑其他指标吗？
此外，一旦我们掌握了所有这些指标，它们如何转化为硬件要求？
We're being asked to spec out production database hardware for an ASP.NET web application that hasn't been built yet.
The specs we need to determine are:
- Database CPU
- Database I/O
- Database RAM
Here are the metrics I'm currently looking at:
- Estimated number of future hits to
website - based on current IIS logs. - Estimated worst-case peak loads to
website. - Estimated number of DB queries per
page, on average. - Number of servers in web farm that
will be hitting database. - Cache polling traffic from database
(using SqlCacheDependency). - Estimated data cache misses.
- Estimated number of daily database transactions.
- Maximum acceptable page render time.
Any other metrics we should be taking into account?
Also, once we have all those metrics in place, how do they translate into hardware requirements?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我最近在服务器规划方面一直在使用惠普提供的一些免费工具，这些工具统称为“服务器大小调整器”。 这些都是很棒的工具，因为它们可以找出要使用的最佳 RAID 类型，以及处理负载的正确磁盘轴数量（在规划良好的数据库服务器时非常重要）和内存处理器等。我提供了下面的链接我希望这有帮助。
http://h71019。 www7.hp.com/ActiveAnswers/cache/70729-0-0-225-121.html?jumpid=reg_R1002_USEN
What I have been doing lately for server planning is using some free tools that HP provides, which are collectively referred to as the "server sizers". These are great tools because they figure out the optimal type of RAID to use, and the correct number of disk spindles to handle the load (very important when planning for a good DB server) and memory processor etc. I've provided the link below I hope this helps.
http://h71019.www7.hp.com/ActiveAnswers/cache/70729-0-0-225-121.html?jumpid=reg_R1002_USEN
我缺少的是衡量所需/要求/定义的可靠性水平的措施。
虽然您可能会指定一台大型机器来处理所有负载，但根据您的可靠性要求，您可能宁愿投资于更小但多台的机器，以及更安全的磁盘子系统 (RAID 5)。
马克
What I am missing is a measure for the needed / required / defined level of reliability.
While you could probably spec out a big honking machine to handle all the load, depending on your reliabiltiy requirements, you might rather want to invest in smaller, but multiple machines, and into safer disk subsystems (RAID 5).
Marc
在我看来，评估尚未构建和设计的应用程序的硬件更多的是一个政治问题，而不是一个科学问题。 当您完成项目时，当前的硬件能力及其价格、功能要求、预期并发用户数、外部系统和所有其他事物都会发生变化，并且这种变化超出您的控制范围。
然而，这个问题经常出现，因为您需要在提案中输入数字或向经理提供报告。 如果它是一个提案，那么您想要完成的就是提出一个可以支持提议的软件系统的规范。 唯一的技巧是提出一个系统，既不会增加您的竞争力成本，又不会让您面临系统性能低下的风险。
In my opinion, estimating hardware for an application that hasn't been built and designed yet is more of a political issue than a scientific issue. By the time you finish the project, current hardware capability and their price, functional requirements, expected number of concurrent users, external systems and all other things will change and this change is beyond your control.
However this question comes up very often since you need to put numbers in a proposal or provide a report to your manager. If it is a proposal, what you are trying to accomplish is to come up with a spec that can support the proposed sofware system. The only trick is to propose a system that will not increase your cost for competiteveness while not puting yourself at the risk of a low performance system.
如果您可以根据页面点击量来描述当前的工作负载，那么您可以：
1）计算将为每个页面执行的典型查询类型
2）使用上述两条信息，估计数据库服务器上的工作负载
您还需要确定您的性能要求 - 您希望网站的最大和平均响应时间是多少？
给定工作负载和性能要求，您就可以计算容量。 进行此估计的最佳方法是使用一些现有硬件，在该硬件上的数据库上运行模拟数据库工作负载，然后根据第一步中的数据推断您的硬件要求。
If you can characterize your current workload in terms of hits to pages, then you can then:
1) calculate the typical type of query that will be done for each page
2) using the above 2 pieces of information, estimate the workload on the database server
You also need to determine your performance requirements - what is the max and average response time you want for your website?
Given the workload, and performance requirements, you can then calculate capacity. The best way to make this estimate is to use some existing hardware, run a simulated database workload on a database on that hardware, and then extrapolate your hardware requirements based on your data from the first steps.