确定应用程序硬件要求的最佳方法是什么

发布于 2024-07-11 08:09:21 字数 112 浏览 6 评论 0原文

您使用什么方法来确定服务器需要哪种硬件?

我经常发现很难预测带有数据库的基于 Web 的应用程序需要哪种硬件。

对于如何最好地选择要使用的硬件,您有什么好的方法或建议吗?

What methods do you use to determine what kind of hardware you need for a server?

I often find it very hard to predict what kind of hardware you will need for a web based application with a database.

Do you have any good methods or recommendations on how to best pick hardware to use?

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

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

发布评论

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

评论(4

粉红×色少女 2024-07-18 08:09:21

这是容量规划的基本问题。 首先定义一个工作负载模型,它描述了您期望获得的流量。 这可以像“我预计每分钟最多点击 20 个页面”一样简单。

然后你需要考虑突发负载。 如果没有任何其他数据,您可以假设到达间隔时间呈指数分布,这意味着如果您在时间t0有页面请求,则很可能下一次到达t下一个是在t0很长一段时间之后的很短的时间。 (这过于简单化了,但对于一页的答案来说已经足够了。)

所以我们假设平均到达间隔时间是 λ。 因为时间分布是指数分布,所以我们知道可以用正态来近似到达间隔时间分布,其中一个标准差 (1σ) 等于 √λ。 所以,我们知道

  • 大约 32% 的情况下,两个
    请求的页数将少于
    λ- √λ 秒
    分开。
  • 大约 5% 的时间里,两个
    请求的页数将少于
    λ- 2√λ 秒
    分开。
  • 不到 1% 的时间,两个
    请求的页数将少于
    λ- 3√λ 秒
    分开。

决定您愿意接受的内容,并进行测试以确保您的网络系统能够维持该速度。

This is sort of the basic question of capacity planning. You start by defining a workload model, which describes what you expect to get in terms of traffic. This can be as simple as "I expect 20 page hits a minute maximum."

Then you need to think about burst loads. Failing any other data, you can assume that interarrival times are exponentially distributed, which means that if you have a page request at time t0, you're as likely to have the next arrival tnext a very short time after t0 as a long time. (That's a gross oversimplification, but will do for a one-page answer.)

So let's say the average interarrival time is λ. because the time distribution is exponential, we know that we can approximate the interarrival time distribution with a normal, with one standard deviation (1σ) equal to √λ. So, we know that

  • about 32 percent of the time, two
    pages will be requested less that
    λ- √λ seconds
    apart.
  • about 5 percent of the time, two
    pages will be requested less that
    λ- 2√λ seconds
    apart.
  • less than 1 percent of the time, two
    pages will be requested less that
    λ- 3√λ seconds
    apart.

Decide what you're willing to accept, and test to make sure your web system can sustain that rate.

随梦而飞# 2024-07-18 08:09:21

补充一下查理所说的,一旦您有了工作负载模型,您就可以将其输入系统模拟中,以确定满足该负载所需的马力。 有一些工具可以进行此类模拟:

这东西并不容易,商业工具会花费你。

您还可以尝试寻找接近您预期负载的基准,并查看哪些系统可以为您提供所需的性能。 TPC 基准测试将是一个很好的起点。

To add to what Charlie says, once you have a workload model you can feed this into a simulation of your system to determine the horsepower you need to satisfy that load. There are some tools that can do this sort of simulation:

This stuff isn't easy, and the commercial tools will cost ya.

You could also try looking for a benchmark that's close to your expected load and see what systems give you the performance you're looking for. The TPC benchmarks would be a good place to start.

乖乖公主 2024-07-18 08:09:21

我想您的网络应用程序并不是像您所说的“服务器”和“数据库”那样的关键业务应用程序,否则您也许应该寻找一些冗余方法?

在工作中,我们有一些有关硬件的指南,最新的建议是服务器应该是 64 位,因为 SharePoint 14 看起来像是纯 64 位版本。

如果你能负担得起,我建议 SQL 服务器应该是 64 位的,因为大多数人都认为添加更多 RAM(4 GB 以上)确实有回报。

I guess that your web app is not a critical business application as you said "a server" and "a database" otherwise you should perhaps look for some means of redundancy ?

At work we have some guidelines about the hardware, and the latest suggestion is that the server should be 64 bits as SharePoint 14 looks like a 64 bits only version.

If you can afford it I would recommend that the SQL server should be 64 bits as most people agree that adding more RAM (above 4 Gb) really pays off.

我的痛♀有谁懂 2024-07-18 08:09:21

这实际上取决于您的 Web 应用程序需求和流量预期。

很少有网站在最初几个月内需要多个合理的专用服务器。如果您这样做,那么您可能有能力购买更多硬件;)

It really depends on your web application demands and traffic expectations.

Very few websites will need more than one reasonable dedicated server within the first months. And if you do, then you can probably afford to buy more hardware ;)

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