0

我正在寻找存储和读取与 HTTP 会话 cookie 关联的数据的最快方法。

现在，我们有一个充满文件的目录，文件名是会话 cookie（随机约 150 个字符），内容是二进制 blob，通常只有几个字节 - 有时多达 1 或 2 KB。我们还使用 atime（上次读取时间戳）来查找和删除旧会话数据。

目录中的文件数量可能会飙升至数百万，并且服务器会不断检查文件是否存在，时间是什么，读取/写入它们，当然还有删除/创建它们。我怀疑 ext3 不是这种使用模式的理想方法？

存储此类数据的最佳方式是什么？我们测试了 MySQL，但它比 ext3 慢几个数量级（我假设我们没有做错什么？）。即使只是建立一个连接也比执行典型的文件系统存在/atime/fread 周期要长。

任何有经验的人将不胜感激。管理由不相关的小型数据组成的庞大数据库的最快方法是什么？

我们在高端服务器硬件上使用 PHP 和 CentOS（几乎可以买到最好的钱）。不需要集群/负载平衡，我们正在尝试减少中低流量网站的每个请求延迟。我们没有使用 PHP 的内置会话 API，因为它在我们的情况下不起作用。

4

2 回答 2

2

假设您的 PHP 是一流的并且经过优化，我会尝试将文件系统更改为 ext4（或者我应该说，为会话数据创建一个 ext4 挂载）。相比之下，ext3 非常慢，因此这可能是您的瓶颈。

如果您不能支持 ext4，则 ext2 也是一种选择（尽管 ext4 现在已经发布了足够长的时间，所以您应该可以接受）。但是，如果您使用 ext2，请确保您有一个单独的挂载仅用于会话数据，因为它不可靠并且没有日志记录。

ext4 的读取性能比 ext2 好，但是 ext2 的写入性能更好 ext4 （很可能是因为它缺少日志，这会产生“一些”开销，但这是我的理由，我可能错了）。

编辑：我还认为值得一提的是，较小的目录比一个大目录要好。但是，除非您使用自定义编译的内核，将每个目录的 32000 个文件限制增加为 ext3 的默认值，否则您可能会这样做。但保持 inode（目录中所有文件的索引）较小会提高性能。像根据文件的前 x 个字符将文件分类到目录这样简单的事情可以实现这一点，而不会增加太多的处理开销，即在能够选择会话文件之前找到正确的目录。

于 2012-09-07T14:41:21.067 回答
2

你看过内存数据库吗？它们速度很快，因为它们不需要在每次操作时都接触磁盘，并且有些可以选择偶尔将数据写入磁盘以使其持久化。

如果您的数据很简单，则键值存储应该更快，因为它更轻量级，例如Redis或具有持久化磁盘选项的缓存解决方案（不知道 PHP，但一个示例是Java的EHcache）。

于 2012-09-07T16:46:56.777 回答