PHP session 性能 : array vs key into a database table?

Question

与之前的 question 类似，我希望在一个小型网络应用程序上实现用户偏好设置。

目前大约有 10 个字段可供用户自定义(这可能会在未来发生变化)。

对数据库进行初始查询并将这些首选项加载到 SESSION 数组中更有意义，还是仅获取每页所需的首选项？当前所有字段均不超过 12 个字符。

目前用户总数非常少(内部开发阶段)，但 future 可能有数百或数千个给定实例的用户。

我个人没有对这些问题中的任何一个进行基准测试，而且我还不能这样做(用户群太小)。

Answer 1

我喜欢的一种 session 管理是内置于 egroupware 中的。在这个系统中，每个偏好都可以定义为 3 个级别:

• 强制偏好( super 用户决定，用户实际上不会看到它)
• 默认偏好
• 用户定义的值

有了这样的东西获得一个对象或数组与用户偏好可能需要几个查询。它也可能受到长期 cookie 用户设置的影响。

然后有兴趣避免在每次请求时重做所有这些东西，并将最终结果存储在 session 文件中是个好主意。在安全性方面，我认为存储在 session 文件中的数据和存储在数据库中的数据之间没有太大区别，它们都是服务器端的，有一个好的管理员，你的 session 不会在所有应用程序的相同目录中，您将拥有您的应用程序目录，没问题。

更进一步。通过使用 session 存储的首选项定义，您失去了通过修改默认首选项或强制首选项来更改此 session 的可能性。首选项将在 session 期间可用。如果这在您的情况下是一个问题(好吧，大多数时候这不是问题)，解决方案是应用程序级缓存，在您将数据存储在缓存中的方式上具有良好的标记系统。然后您可以在需要时删除所有标记的数据。

应用程序级缓存，如 APC 缓存或 memcached 将为您提供一种快速有效的数据存储方式，使用它来保存您的用户首选项可能是一个好主意，至少可以在多个应用程序服务器之间共享此数据而无需使用NFS 共享 session 文件。但在如此大的解决方案中，真正的解决方案是使用这些缓存而不是文件来存储 session 。以同样的方式，您可以使用数据库来存储您的 session 。

关于最后一点，数据库 session 存储，您可以想象所有用于构建首选项的查询现在都包含在从数据库中检索 session 的唯一查询中(其中包含您的首选项，在第一个 http 查询之后用户 session )。但这是一个糟糕的解决方案，对于大多数数据库来说，因为 session 会收到很多写事件，而对于像 MySQL 这样的数据库，在表中有很多插入/更新查询会导致很大的性能问题(锁、查询缓存刷新等) ).所以文件系统和缓存在管理 session 方面更好。数据库很好地以安全的方式保存长期数据， session 存储不是同一个问题，你想要一些非常快的东西，你可以放心地松开它(因为它只会破坏用户 session )。

如您所见，当我想到 session 时，我想到的是比数据库更快的东西。如果您的系统没有提供比数据库更快的 session 方式，我个人认为这是系统故障，这将是系统管理员的工作。在应用程序方面，您应该考虑比数据库更快的 session 。