【问题标题】:PHP Sessions performance: array vs key into a database table?PHP Sessions 性能:数据库表中的数组与键?
【发布时间】:2011-05-30 04:43:57
【问题描述】:

与之前的 question 类似,我希望在一个小型 web 应用上实现用户偏好。

目前用户可以自定义大约 10 个字段(将来可能会改变)。

对数据库进行初始查询并将这些首选项加载到SESSION 数组中是否更有意义,或者只获取每页所需的首选项?目前没有一个字段超过 12 个字符。

目前用户总数非常少(内部开发阶段),但未来给定实例可能有成百上千的用户。

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

【问题讨论】:

  • 更多的是这些设置的使用频率问题。如果您正在阅读它们然后大量使用它们,那么在会话中加载它们可能更有意义。此外,如果您发现每个页面都在重复加载代码。也可能是本次会议的好候选人。
  • 如果你不知道 - 总是走正常的路。这意味着只有一个数据实例。因此,将其保存在数据库中。而且,让您知道,成千上万的用户算不了什么。
  • @Col。弹片 - 我知道成千上万的用户是“一无所有”..我更多地考虑成千上万的同时用户的顺序:)
  • 那么,除了这个,您还解决了哪些架构问题?软件,硬件?什么是瓶颈?这个特定的问题是否是瓶颈?除了打开和锁定会话之外,您的代码还执行哪些文件系统操作?
  • @Col。弹片 - 不确定其他瓶颈可能发生在哪里......正如我已经说过的:这在设计的早期阶段,我只是希望首先让一些更明显的事情“正确”:)

标签: php database session


【解决方案1】:

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

  • 强制偏好(超级用户决定,用户实际上不会看到)
  • 默认偏好
  • 用户定义值

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

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

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

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

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

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

【讨论】:

    【解决方案2】:

    无论哪种方式,您都会碰到磁盘。不过,提取会话数据的开销可能更少,因此只有一次 mysql 开销可能会更好。正如其他人所建议的那样,memcached 或其他一些堆表将是避免在后续页面加载时完全损坏磁盘的好方法,并且允许您的解决方案稍后扩展,默认会话处理程序不会跨服务器共享。

    顺便说一句,您可以使用 httperf 或 AB 或任何数量的其他解决方案自行对其进行基准测试,而无需等待用户群增长。

    【讨论】:

    • 无论如何,DB 也在磁盘上。正如您所说,httperf 或 AB 是理解它的最佳方式。实际上no1可以不用尝试就可以预测。因为有数百种条件会影响性能。
    【解决方案3】:

    我认为基于会话的方法会是更好的解决方案(只要其中没有敏感的用户名/密码等信息)。毕竟,磁盘空间比多次数据库查找要便宜很多。

    或者,如果性能成为问题,您可以考虑使用 memcached 之类的东西。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2010-09-16
      • 2013-05-12
      • 2012-03-29
      • 1970-01-01
      • 1970-01-01
      • 2010-09-18
      • 2012-03-13
      • 1970-01-01
      相关资源
      最近更新 更多