![无数据库交互的高性能 Web 服务器](https://linux22.com/image/484257/%E6%97%A0%E6%95%B0%E6%8D%AE%E5%BA%93%E4%BA%A4%E4%BA%92%E7%9A%84%E9%AB%98%E6%80%A7%E8%83%BD%20Web%20%E6%9C%8D%E5%8A%A1%E5%99%A8.png)
我正准备设置一台服务器,负责跟踪来自高流量源的统计数据。它将平均每小时处理约 6-7 百万个请求,所有请求都是小型 GET。我需要的只是一个简单的服务器设置,它可以处理 GET 请求的参数并将其写入 CSV 文件。
我的第一个想法是使用 lighttpd+fastcgi+php,因为这是我已经熟悉的配置。但是,考虑到我并不是每天都要做出这种性能决策,我想探索一些其他选项,看看是否有更好的选择。
答案1
您希望每秒对 CSV 文件执行 600-700 万次写入操作小时?
说真的,数据库是个更好的主意。数据库旨在处理并发写入,并且可以垂直扩展(更大的机器,更快的磁盘)或水平扩展(负载分散到多个服务器上)。写入单个 CSV 文件(或任何文件)需要某种形式的锁定来处理并发问题,并且随着 IO 负载和并发性的增加,扩展性很差。
为了解决这个问题,您可能最终会实现自己的缓存和缓冲层,然后开始在多个文件之间拆分负载等等。从一开始就使用某种类型的数据库,可以省去很多麻烦。
答案2
假设你打算每秒处理 2000 个请求,或者说每个请求 500µs平均的(意味着更高的峰值),由于并发写入时条目被破坏,CSV 可能无法使用,因为没有什么可以保证文件中的原子写入。
一个想法是每个进程/每个写入器的文件,稍后再收集,另一个想法是使用针对大量写入进行大量调整的数据库。您还可以查看消息队列或组通信协议(例如传播),但我不知道他们是否能承受这么大的音量。
无论你做什么,提出一些快速的想法并对其进行基准测试。当前的硬件可以对性能产生奇迹,只在需要时进行优化。至于 PHP - 确保安装了 Opcode Cache(例如亚太经合组织),否则您将在脚本的不必要重新编译上浪费大量时间。
还要记住服务的增长情况,寻求一个几个月后就会不堪重负的解决方案几乎没有任何意义。
答案3
通过 GET 请求传递了哪些类型的参数?是否需要实时以 CSV/数据库格式保存?或者您是否认为您可以创建一个虚拟 HTML 文件(或 PHP),然后仅使用 Web 日志进行解析,然后将其作为批处理作业转储到 CSV 中?(好吧……这听起来很复杂……但很容易处理)……
答案4
我会查看服务器 2008 网络版并使用 ADO.net 写入 CSV 文件。您不应该有吞吐量问题,因为 ado.net 将缓冲写入。