我需要什么样的服务器才能每天处理 1000 万个请求和 mySQL 查询?

Cal*_*vin 24 mysql php web-hosting web-server

我是服务器管理的新手,我正在寻找强大的托管服务来托管我的新网站。这个网站基本上是一个手机网络游戏的后端,它将:

  • 每天处理多达 1000 万个 HTTPS 请求和 mySQL 查询
  • 在硬盘上存储多达 2000 GB 的文件
  • 每月可能传入和传出 5000 GB 数据
  • 它在 PHP 和 mySQL 上运行
  • mySQL 数据库中有 1000 万条记录,每条记录有 5-10 个字段,每个字段大约 100 个字节

我真的不知道我需要什么样的服务器来处理这些需求,我的问题是:

  1. 专用服务器或 VPS 需要什么 CPU/RAM?
  2. 哪些托管公司能够提供这种专用服务器或 VPS?
  3. 云计算呢?我研究了 Amazon EC2,但对我来说似乎很复杂。我已经联系了 Rackspace,但奇怪的是他们说 Cloudsites 不适合我的要求。我想知道是否有其他云托管公司。
  4. 还有其他替代方法吗?

Tom*_*Tom 33

便宜的台式机?

让我们进入数学。

  • 1000 万个请求。
  • 这分解为每小时 416667 个请求。
  • 这分解为每分钟 6944 个请求。
  • 这分解为每秒 116 个请求。

如果查询足够简单,并且您并没有真正说出它们有多复杂,那么将其加倍(峰值负载),我们谈论的是廉价四核台式机可以处理的负载。

  • 每月 5000 GB 是微不足道的 - 说真的,同样的数学适用。
  • 分解为 208GB/天
  • 分解为 8GB/小时
  • 分解为 148MB/分钟
  • 分解为 2.5MB/秒,25Mbit。双峰 - 50Mbit,对于任何托管中心来说都是微不足道的。不过会花钱。

  • 在硬盘上存储 2000 GB。那是 RAID 中的 2x2000 GB 硬盘?除非:它用于数据库,有很多复杂的 IO,然后它是在 RAID 10(大约 60 个磁盘)中的几十个磁盘和大量 73GB 15.000RPM SAS 磁盘之间的任何东西来获得所需的 I/O - 这如果没有关于数据访问模式的更多信息,问题是无法回答的。

  • 运行 PHP 和 MySQL - 我的手机可以做到这一点;) 问题是应用程序的复杂程度。MySQL 在这里可能或可能不是可接受的解决方案,顺便说一句。- 这将需要更多的测试。有些人仍然使用其他更大的商业数据库是有原因的。

  • 专用服务器或 VPS 需要什么 CPU/内存?

有人会说这取决于逻辑(PHP 部分的计算量,聪明或缺乏程序员以及许多其他问题。

说真的,这是一个不平凡的设置。请一些专家研究一下。

基本上你需要静下心来完成你的家庭作业。许多问题无法以这种形式回答。特别是因为你似乎并不关心你的数据......

  • 备份?
  • 没有应急计划?我的意思是,服务器死了 - 所以你可以接受网站在配置更换时关闭数天吗?

  • 忘记四核。您的笔记本电脑在 IO 中很糟糕 - 而 IO 是数据库受到限制的地方。您有一个硬盘,即 SLOW 和 ROBUST(笔记本电脑)。服务器使用快速(但不健壮)的多个硬盘。我使用 MS 的四核 SQL Server,可以在简单的选择(一个批次是一个选择)上每秒处理超过 500 个批次,而不会使 CPU 最大化 - 但我确实在磁盘子系统上获得了很多磁盘活动,这可能是比你的快 30 倍以上(这还不令人印象深刻)。光盘是极限。加上适当的编程。 (2认同)

ues*_*esp 9

添加一些我的经验,这可能会有所帮助:

  • 正如 TomTom 所提到的,很难/不可能给出确切的规格,因为它在很大程度上取决于您的应用程序的设计和实现。给我或其他人 X 请求/秒的硬件可能不适合您。
  • 我有一个低端专用 MySQL 服务器(Intel Core2 Duo E4600 2.40 GHz,4 GB RAM),平均每秒处理 100 个请求(接近 1000 万次/天),CPU 空闲率为 90%。除了对配置的一些基本调整之外,由于读取量大(+95% 读取),并且活动记录集很容易包含在内存中,因此它运行良好。在选择服务器 RAM 量时,请考虑活动集的大小,因为它可以产生很大的不同。确保您了解数据库大小和活动记录集大小之间的区别。例如,我的数据库总共约 7GB,但活动集可能只有几个 100MB。
  • 同样,我有一个类似规格的 Apache 服务器,每天处理约 100 万个请求,平均 CPU 空闲率约为 95%。请求是非常简单的地图数据 AJAX 查询和更复杂的 MediaWiki 页面的混合。
  • 对您的特定应用程序进行基准测试是尝试确定您需要什么的良好开端。您不想低估,但由于潜在的金钱和精力浪费,高估可能同样糟糕。
  • 不仅要考虑平均请求率,还要考虑峰值率。您不希望服务器几乎无法处理平均速率,因为请求速率在一天、一周和一个月内可能会发生显着变化。例如,我可以在周末的高峰时段获得 3-4 倍的流量,就像我在一周中的最短时段一样。它的变化程度取决于您的应用程序和用户群。
  • 您可以缓存任何数据库/HTTP 请求吗?这可以通过更便宜/更少的硬件大大提高您的请求率,具体取决于您可以缓存的数量。
  • 现在而不是以后考虑您未来增长的扩展选项。一个不错的选择可能是使用水平扩展,它可以让您从最少的硬件开始,并根据需要轻松扩展。
  • 应用程序层的正确设计可以对其最终性能产生巨大影响。对没有索引的表执行错误的 SQL 查询可能比正确设计的查询慢几个数量级。同样,配置不当的 Apache/MySQL 服务器可能比正确设置时慢很多倍。