【问题标题】:Hight traffic with several bad hostings有几个糟糕的主机的高流量
【发布时间】:2014-06-11 11:01:29
【问题描述】:

这里的情况很复杂!

现在的情况: 我们有一个主服务器只做他的事情。 数据每秒钟都在变化。 我们需要一个网络小部件(html 数据)来与其他网站共享。 该小部件必须每分钟刷新一次。 小部件数据将每秒更改一次。 所有其他网站的访问者都必须看到该信息。 我们无法处理如此高的流量。服务器需要 24/7 在线,他们不会每分钟连接一次。 我说的是每月一百万次展示。

我们正在研究的解决方案: 获取多个托管计划。 所有主机都将存储将显示给访问者的 HTML 数据。 每个托管帐户都会每隔一分钟对我们的主服务器执行一次 cronjob。 获取 html 并将其存储到下一个 cronjob。 这就是我们将流量从主服务器转移到其他地方的方式。 现在是网站访问者连接到存储在我们主机中的 html 的部分。 下面的代码正在连接第一个托管服务器,如果他在一段时间内没有回答,它将连接到第二个。并循环直到其中一些返回 HTML 数据。 当然,如果他们 100% 加载,我们将获得另一个新主机。

<script>
server_1 = 'http://hostingserver_one.com/';
server_2 = 'http://hostingserver_two.com/';

wait_for_response = 5000;
one_minute = 60 * 1000;
half_minute = 30 * 1000;
right_away = 1;

current_refresh_minute = one_minute;
current_refresh_server = server_1;

function ajaxRequestInfo() {
    $.ajax({
        type: 'GET',
        url: current_refresh_server,
        timeout: wait_for_response,
        data: {},
        success: function(data) {
            $(".data_for_refresh").html(data);
        },
        complete: function(data) {
            window.setTimeout(ajaxRequestInfo, one_minute);
        },
        error: function() {
            changeRefreshServer();
            window.setTimeout(ajaxRequestInfo, right_away);
        },
        async: true
    });
}

function changeRefreshServer() {
    if (current_refresh_server == server_1) {
        current_refresh_server = server_2;
    } else if (current_refresh_server == server_2) {
        current_refresh_server = server_3;
    } else if (current_refresh_server == server_3) {
        current_refresh_server = server_1;
    }
}

$(document).ready(function() {
    ajaxRequestInfo();
});

问题是: 这是最好的方法吗?! 如果不是什么更好。 我相信你们中的许多人已经通过了这种情况,但这是我的第一次:)

【问题讨论】:

  • 有人吗?!请在这里给出一些解决方案。在时间表中完成这个对我来说很重要:)
  • 为什么不简单地将 CDN 与 Amazon AWS 或 Azure 结合使用?

标签: jquery web-services network-traffic high-traffic


【解决方案1】:

用 html 文件谈论 100 万个我觉得很奇怪, 你可以更精确地处理它。

你需要关注的两件事是

负载平衡消耗的内存超过一台网络服务器所能提供的

如果您的帐户是高负载的,我的意思是负载过多,那么应该转到另一台服务器,而不是承受单个服务器的缓慢。 另一方面,如果您想在单个服务器上托管许多应用程序,则需要服务器可以提供更多内存

基本上,我在服务器上安装了标准的 wordpress 制作 ProxyPass。然后我配置了站点并安装了 扩展和模板。我在这台服务器上配置了一个 SQL DB,在我们的 如果它也是代理,但最好将其隔离在其上 服务器或外部数据库服务,如 Xeround。在我的 WordPress、apache、mysql 和 memcached 配置,我总是 指定内部专用网络 IP,因为我在 iWeb 上的所有服务器 是智能服务器。这消除了公共网络上的流量。它 使设置更加安全。

我在这里读到你可以找到更多的想法Here

ultraking 是您需要关注的软件

现在,如果您有多个 html 文件,这些文件将逐个服务器查找用户的特定文件。 但这不是在全服务器中找到的好主意。 而是制作一个 json 对象 将有关于哪个服务器包含哪些信息的信息 所以现在 情况是 用户 > 访问您的网站(包含有关每个服务器的信息对象)>> 用户对文件的请求 > 文件过滤器 json 对象 > 命中您的唯一对象

这将进一步减少您服务器的流量。谢谢

[编辑]

这完全取决于您为处理用户而制定的计划策略。 如果您的策略和正确选择的工具未基于基准,您将无法处理单个用户。

【讨论】:

    【解决方案2】:

    您的架构对我来说看起来很奇怪:它不应该让客户端(您的网站访问者)在服务器之间进行“负载平衡”。这不是他们关心的问题,最糟糕的是,这不会使您的服务器端的事情变得更好,因为他们无论如何都会尝试创建连接并因此产生一些负载。

    您应该在一组为您的 (HTML) 内容提供服务的 Web 服务器之前放置某种形式的负载平衡。

    还应使用一些共享缓存将网络服务器与您的“数据/主”服务器隔离,以避免加载后者。例如,参见 Memcached。

    在 Stackoverflow 答案中很难详细说明。此外,您引用的数字在我看来并没有那么高,我有一种感觉(并且只是感觉),正确启用缓存的最小数量的合理大小的服务器应该可以轻松应对这些值。

    【讨论】:

    • 问题是客户没有太多资金来完成这项工作。我们正在考虑购买新服务器,但一旦他提高了盈利能力。目前最便宜的变体是获得本地托管计划(以获得更快的连接)并使用它们直到我们获得新的服务器。是的,在用户上进行负载平衡是愚蠢的,但我们没有硬件和不同的连接。它跳过用户茶点没什么大不了的。我们的想法是暂时以任何方式工作。
    • 我不确定我是否遵循这里的金钱论点。在 OVH 上花几块钱买一个域名,你就可以得到免费的 DNS Round-Robin,例如免费负载均衡。此外,事实上,您所做的将不会在负载下工作:所有请求都转到 server1,很快就会超载,超时,然后只转到 server2。如果超时设置得太低,请求将永远无法完成,如果设置得太高,您将在客户端超过一分钟。
    【解决方案3】:

    每月一百万还不错。即使客户端直接连接到您以获取数据,您也可以处理它。只需在外部托管大部分小部件,并让它使用 javascript xmlHttpRequest 从您的主服务器下载一个小文本文件,然后将其咀嚼成用户友好的设计。 只是为了比较,我的服务器每月获得 600 万次 GET 点击。每个文件的平均大小为 15 kB。这比您需要的要多得多。令人惊讶的是:这个服务器的“野兽”是我桌子下的 SOHO DD-WRT 路由器。 :)

    编辑:您仍然可以通过启用动态 gzip 来管理它。对于我建议你做的低于 100 字节的输出,这并没有什么意义。

    【讨论】:

      【解决方案4】:

      100 万次展示听起来可能会产生大量流量,但实际上大多数网络服务器在正常 情况下都可以处理这样的负载。如果您在共享服务器或 VPS 上,我可以理解 100 万可能负载太大,如果这是您的情况,您应该考虑专用托管或增加您的 VPS 规格。您的代码/数据库等也可能会出现扩展问题,这会减慢速度。

      虽然您的方法没有任何问题,但可以通过更好的设置更好地解决此问题,但如果您想走两条服务器路线,您应该研究负载平衡并使用 Moo 推荐的 AWS 或 Azure 等弹性资源在云上托管例如,而不是依赖客户端 Javascript 代码将流量发送到正确的服务器。

      【讨论】:

        猜你喜欢
        • 2014-09-07
        • 2016-11-02
        • 1970-01-01
        • 2010-09-10
        • 1970-01-01
        • 1970-01-01
        • 2022-07-13
        • 2010-11-24
        • 1970-01-01
        相关资源
        最近更新 更多