用于 Web 开发的根服务器 - 多少功率才足够?

发布于 2024-07-15 18:20:51 字数 241 浏览 2 评论 0原文

我认为这个问题与一般的编程无关,但其他 Web 开发人员可能会对答案感兴趣。

我只是想知道如何估计拥有一个快速网站的最低要求。 显然,必须考虑一些事实,例如预期的访问者数量、派生的每秒点击次数等等...还运行 Web 服务器(Apache/lighttpd)或邮件服务器(Exim、sendmail、. ..) 可能最终会产生不同的需求。

也许您知道一个好的网站,或者可以提供一些关于如何从此类信息估计所需服务器配置的解释?

I think this question has not to do with programming in general, but nevertheless the answers might be interesting to other web developers.

I just wondered how to estimate the minimum requirements to have a fast website. Obviously there are some facts that have to be considered like the expected number of visitors, the derived number of clicks per seconds and so on... Also running services like web servers (Apache/lighttpd) or mail servers (Exim, sendmail, ...) could end up in different needs.

Maybe you know a good website or can give some explanations on how to estimate the needed server configuration from such information?

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

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

发布评论

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

评论(2

我做我的改变 2024-07-22 18:20:51

可以说,这更像是艺术而不是科学。

您必须记住的是,就像编程和 IT 中的许多事情一样,您的网站将像链中最慢的链接一样慢,这意味着您将遇到一些瓶颈,例如带宽、Web 服务器、磁盘 I/O、内存、您的数据库、防火墙等会限制您网站的速度。

调整和发展您的网站将涉及在您发展过程中识别这些问题并解决它们。 有时您可能需要添加更多 RAM,有时您可能需要另一个 CPU 等等。 在其他时候,添加更多内存可能没有用,因为内存不是您的问题。

同样,某些资源的缺乏也可以被掩盖,就像系统不断交换(页面错误)时密集的磁盘 I/O 可以掩盖内存不足一样,但磁盘 I/O 不是问题。

所以你会怎么做?

首先,您需要确定(或做出合理的猜测)典型用户会做什么以及他们会做什么。 理想情况下,您将能够使用 JMeter 等软件对 100 或 1000 或任意数量的用户进行建模,然后了解您的网站如何扩展、需要多少带宽等等。 通过对 100、500、1000、2000 个用户进行建模,您将有望了解网站的线性扩展情况。

您可能会发现支持 1000 个用户需要 1 GB RAM,但 2000 个用户需要 4 GB:这是非线性可伸缩性的一个示例,它暴露了您在扩展网站时遇到的问题。 这就是性能测试要揭示的事情。

但老实说,现在的硬件非常便宜,除了最大和最受欢迎的网站之外,很少有问题(1 万美元可以购买 1 台甚至 2 台具有 16G RAM 和 4-8 个内核的服务器)。 共享和 VPS 托管则不同,因为您通常只想为所需的内存、带宽和磁盘空间付费。 幸运的是,这些类型的解决方案往往可以让您轻松升级(至少达到您最终不得不专用托管的程度)。

您可以在项目开始时通过进行所谓的“粗略估计”来进行一些粗略的估计。 运行关键查询 100 次,计算出它们需要多少 CPU 时间,点击模拟页面 100 次,计算出它生成多少带宽,等等。 这些粗略的估计与对用户将如何使用该网站的猜测相结合,将为您提供所需内容的大概范围(希望在 2-3 倍以内)。

This is arguably more art than science.

What you have to remember is that like many things in programming and IT, your website will be as slow as the slowest link in the chain, meaning you will have some bottleneck such as bandwidth, the Web servers, disk I/O, memory, your databases, your firewall, etc that will limit the speed of your Website.

Tuning and growing your Web site will involve identifying those issues as you grow and addressing them. At one point you may need to add more RAM, at another you may need another CPU and so on. At other times adding more memory might be useless because memory isn't your problem.

Likewise, lack of a certain resource can be masked, like lack of memory can be masked by intensive disk I/O as your system swaps (page faults) constantly but disk I/O isn't the problem.

So what do you do?

The first thing is you need to identify (or make a reasonable guess) as to what a typical user will do and how much they will do it. Ideally you will be able to model 100 or 1000 or however many users you need with software like JMeter to then get an idea of how your Website scales, how much bandwidth is going to be required and so on. By modelling 100, 500, 1000, 2000 users you will hopefully be able to see how linearly you Web site scales.

You may find that supporting 1000 users requires 1 gig of RAM but 2000 requires 4 gigs: that's an example of non-linear scalability that expoes a problem you will have scaling your Web site up. And that's the kind of thing to be revealed by performance testing.

Honestly though, hardware is so cheap these days that it's rarely a problem except for the biggest and most popular of sites ($10k can buy you 1 or even 2 servers with 16G of RAM and 4-8 cores each). Shared and VPS hosting are a different story because you'll typically only want to pay for however much memory, bandwidth and disk space you need. Luckily those kinds of solutions tend to alow you to upgrade pretty easily (at least to a point where you'll eventually have to go dedicating hosting).

You can make some dirty estimates at the beginning of a project by doing what they call "back of the envelope" estimation. Run key queries say 100 times and work out hwo much CPU time they require, hit a mocked up page 100 times and work out how much bandwidth it generates and so on. These rough estimates combined with guesses about how users will use the site will give you a ballpark (hopefully within a factor of 2-3) of what you'll need.

看轻我的陪伴 2024-07-22 18:20:51

您已经提到了用户数量、服务器数量等。这里还有一些需要考虑的内容。

  1. 如果流量较高,则使用集群服务器 服务器
  2. 的物理位置:找到您网站的受众目标,最好在该国家/地区拥有服务器。
  3. 灾难恢复计划。 拥有更快的网站固然很好,拥有更快的恢复过程也非常好。
  4. 选择最好的技术并实施 AJAX 等新技术,并尽可能减少服务器请求。

如果有什么事情的话会补充的。

You have already mentioned about number of users, Servers etc. Here are some more to consider.

  1. Clustered server if the traffic is high
  2. Physical location of the server : Find the the target of audience for your website and better have the server in that country.
  3. Disaster Recovery Plan. Having a faster website is good and having a faster recovery process is also very good.
  4. Choose the best technology and implement new technologies like AJAX and reduce server request where ever possible.

Will add more if something comes up.

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