Tom Asked: 2009-06-04 17:12:09 +0800 CST2009-06-04 17:12:09 +0800 CST 2009-06-04 17:12:09 +0800 CST 无数据库交互的高性能 Web 服务器 772 我正在准备设置一个服务器，该服务器将负责跟踪来自大量流量源的统计数据。它将平均以大约 6-7 百万/小时的速度处理请求，所有这些都是小型 GET。我所需要的只是一个简单的服务器设置，它可以处理 get 请求的参数并将它们写入 CSV 文件。 我的第一个想法是使用 lighttpd+fastcgi+php，因为这是我已经熟悉的配置。但是，鉴于我不会每天都做出这些性能决定，我想探索一些其他选择，看看是否有更好的方法来实现这一目的。 performance optimization lighttpd scalability 7 个回答 Voted Best Answer John Dalton 2009-06-04T18:04:47+08:002009-06-04T18:04:47+08:00 您想每小时对 CSV 文件执行 6-7 百万次写入操作吗？ 说真的，数据库是一个更好的主意。数据库旨在处理并发写入，并且可以垂直扩展（更大的机器、更快的磁盘）或水平扩展（负载分布在多个服务器上）。写入单个 CSV 文件（或任何文件）需要某种形式的锁定来处理并发问题，并且随着 IO 负载和并发性的增加而难以扩展。 要解决这个问题，您可能最终会实现自己的缓存和缓冲层，然后开始在多个文件等之间分割负载，等等。从一开始就使用某种类型的数据库，为自己省去很多麻烦。 Michael Renner 2009-06-04T18:23:41+08:002009-06-04T18:23:41+08:00 鉴于您将在AVERAGE上执行大约 2000 个请求/秒或 500µs/请求（意味着更高的峰值），由于并发写入的条目被破坏，CSV 可能是不可行的，因为没有任何东西可以保证文件中的原子写入。 一个想法是稍后收集每个进程/每个写入者的文件，另一个想法是使用为大量写入进行大量调整的数据库。您还可以查看消息队列或组通信协议（例如Spread），但我不知道它们是否适合该数量。 无论你做什么，提出一些快速的想法并对其进行基准测试。当前的硬件可以在性能方面创造奇迹，只有在需要时才进行优化。至于 PHP - 确保安装了 Opcode Cache（例如APC），否则您将在不必要的脚本重新编译中消耗许多周期。 还要记住服务的增长情况，以几个月后将不堪重负的解决方案为目标几乎没有任何意义。 Ram Prasad 2009-06-04T20:05:03+08:002009-06-04T20:05:03+08:00 通过 GET 请求传递什么样的参数？它是否需要实时保存在 CSV/数据库中？或者您认为您可以创建一个虚拟 HTML 文件（或 PHP），然后使用 Web 日志稍后作为批处理作业进行解析并转储到 CSV 中？（好吧..这听起来很复杂..但很容易处理）.. dmo 2009-06-04T18:08:22+08:002009-06-04T18:08:22+08:00 也许这超出了您的控制范围，但是 Web 服务器真的是解决此问题的正确工具吗？ Jim B 2009-06-04T20:10:06+08:002009-06-04T20:10:06+08:00 我会看一下 server 2008 web edition 并使用 ADO.net 写入 CSV 文件。你不应该有吞吐量问题，因为 ado.net 会缓冲写入。 Bernd Haug 2009-06-05T02:22:44+08:002009-06-05T02:22:44+08:00 我不知道如何（甚至半）可靠地使用单个（或多或少便宜的）服务器来做到这一点。如果您所做的只是解析 get 参数，那么您最好的选择可能是获得一个高性能的轻量级开源 HTTP 服务器，如gatling并将其破解以将请求记录到像rabbit这样的快速队列。 然后，您可以有一个写入器从该队列中读取并按顺序在紧密循环中写入文件。 这样，您可以确保写入是原子的，同时能够水平扩展可能昂贵的部分（解析和排队）。 这在“每个请求的 CPU 周期”方面肯定会比让一台服务器只写入文件要慢，但是当流量压倒一台机器时它会保持可靠，如果你的最终顺序写入器被淹没，你甚至不会丢失数据一阵子。 注意事项：（a）直觉上昂贵的东西不一定如此，探索性地编码和配置文件。(b) 你确定你不想问stackoverflow的优秀编程专家吗？我们在这里主要做系统。 Adrien Pestel 2009-06-05T18:16:33+08:002009-06-05T18:16:33+08:00 对于网络部分，我会使用 Nginx（lighttpd 越来越老了；） 对于数据： 这种工作的最好方法是寻找像 MapReduce 这样的东西。Hadoop 是 MapReduce 的免费实现。 只需将统计信息存储到简单文件中，然后在 HBase（Hadoop 的一部分）等键/值系统中对它们进行批处理。 然后，您就有了一个完全冗余（感谢 HDFS）和可扩展的解决方案，可以处理 PB 级的数据。
您想每小时对 CSV 文件执行 6-7 百万次写入操作吗？
说真的，数据库是一个更好的主意。数据库旨在处理并发写入，并且可以垂直扩展（更大的机器、更快的磁盘）或水平扩展（负载分布在多个服务器上）。写入单个 CSV 文件（或任何文件）需要某种形式的锁定来处理并发问题，并且随着 IO 负载和并发性的增加而难以扩展。
要解决这个问题，您可能最终会实现自己的缓存和缓冲层，然后开始在多个文件等之间分割负载，等等。从一开始就使用某种类型的数据库，为自己省去很多麻烦。
鉴于您将在AVERAGE上执行大约 2000 个请求/秒或 500µs/请求（意味着更高的峰值），由于并发写入的条目被破坏，CSV 可能是不可行的，因为没有任何东西可以保证文件中的原子写入。
一个想法是稍后收集每个进程/每个写入者的文件，另一个想法是使用为大量写入进行大量调整的数据库。您还可以查看消息队列或组通信协议（例如Spread），但我不知道它们是否适合该数量。
无论你做什么，提出一些快速的想法并对其进行基准测试。当前的硬件可以在性能方面创造奇迹，只有在需要时才进行优化。至于 PHP - 确保安装了 Opcode Cache（例如APC），否则您将在不必要的脚本重新编译中消耗许多周期。
还要记住服务的增长情况，以几个月后将不堪重负的解决方案为目标几乎没有任何意义。
通过 GET 请求传递什么样的参数？它是否需要实时保存在 CSV/数据库中？或者您认为您可以创建一个虚拟 HTML 文件（或 PHP），然后使用 Web 日志稍后作为批处理作业进行解析并转储到 CSV 中？（好吧..这听起来很复杂..但很容易处理）..
也许这超出了您的控制范围，但是 Web 服务器真的是解决此问题的正确工具吗？
我会看一下 server 2008 web edition 并使用 ADO.net 写入 CSV 文件。你不应该有吞吐量问题，因为 ado.net 会缓冲写入。
我不知道如何（甚至半）可靠地使用单个（或多或少便宜的）服务器来做到这一点。如果您所做的只是解析 get 参数，那么您最好的选择可能是获得一个高性能的轻量级开源 HTTP 服务器，如gatling并将其破解以将请求记录到像rabbit这样的快速队列。
然后，您可以有一个写入器从该队列中读取并按顺序在紧密循环中写入文件。
这样，您可以确保写入是原子的，同时能够水平扩展可能昂贵的部分（解析和排队）。
这在“每个请求的 CPU 周期”方面肯定会比让一台服务器只写入文件要慢，但是当流量压倒一台机器时它会保持可靠，如果你的最终顺序写入器被淹没，你甚至不会丢失数据一阵子。
注意事项：（a）直觉上昂贵的东西不一定如此，探索性地编码和配置文件。(b) 你确定你不想问stackoverflow的优秀编程专家吗？我们在这里主要做系统。
对于网络部分，我会使用 Nginx（lighttpd 越来越老了；）
对于数据：
这种工作的最好方法是寻找像 MapReduce 这样的东西。Hadoop 是 MapReduce 的免费实现。
只需将统计信息存储到简单文件中，然后在 HBase（Hadoop 的一部分）等键/值系统中对它们进行批处理。
然后，您就有了一个完全冗余（感谢 HDFS）和可扩展的解决方案，可以处理 PB 级的数据。