0

我目前完成了一个 Web 服务器的构建，它的主要职责是简单地将每个 http post 请求中的正文数据的内容写入日志文件。发布数据的内容在收到时会被混淆。所以我不混淆发布数据并将其写入服务器上的日志文件。混淆后的内容是一系列随机键值对，每个请求之间都不同。它不是固定数据。

该服务器正在运行具有 2.6+ 内核的 Linux。服务器配置为处理大量流量（打开文件限制为 32k 等）。该应用程序是使用 web.py 框架用 Python 编写的。http 服务器是 Nginx 后面的 Gunicorn。

在使用 Apache Benchmark 进行一些负载测试后，我注意到它每秒可以处理大约 600-700 个请求，而不会出现任何日志写入问题。Linux 本身在缓冲方面做得很好。当每秒尝试写入同一文件的请求数超过此数量时，就会出现问题。数据不会被写入，信息会丢失。我知道“直接写入文件”设计可能从一开始就不是正确的解决方案。

所以我想知道是否有人可以提出一个我可以快速实施的解决方案，而无需更改太多可以克服这个问题的基础设施和代码？

我已经阅读过 Redis 等内存存储，但我意识到如果在服务器故障期间数据位于内存中，那么该数据就会丢失。我在文档中读到 redis 可以配置为持久存储，只需要服务器上有足够的内存供 Redis 执行。这个解决方案意味着我必须编写一个脚本，以一定的时间间隔将数据从 Redis（内存）转储到日志文件。

我想知道是否有更快的解决方案？任何帮助将不胜感激！

4

1 回答 1

1

我能想到的一种可能的选择是单独的日志记录过程。这样您的 web.py 就可以屏蔽性能问题。这是处理日志模块的经典方式。您可以使用 IPC 或任何其他总线通信基础设施。有了这个，您将能够解决两个问题 -

  1. 记录不会成为高容量呼叫流的巨大瓶颈。
  2. 一个单独的模块可以确保/提供开关关闭/打开设施。
  3. 因此，不会有任何巨大/显着的进程内存使用。

但是，您应该记住以下几点 -

  1. 您需要确保日志记录仅限于日志记录。它不能是用于业务处理的数据存储。否则，您的业务逻辑中可能存在许多同步问题。
  2. 日志记录过程（这里我指的是实际的 Unix 过程）将变得至关重要并且稍微复杂（即您可能必须处理某种形式的 IPC）。

！

于 2013-03-08T10:21:05.313 回答