$_SESSION 中保存大量信息可以吗?

发布于 2024-11-04 16:42:34 字数 233 浏览 0 评论 0 原文

我需要在 $_SESSION 中存储许多数组,以防止从 MySQL 检索信息。可以吗? $_SESSION 中有多少信息“太多”,或者没有“太多”信息?谢谢。

PS 或者最好使用 http://php.net/manual/en/book.memcache.php ?

I need to store many arrays in $_SESSION to prevent retrieving information from MySQL. Is it okay? How much is "too much" information in $_SESSION or there isn't any "too much"? Thanks.

P.S. Or it's better to use http://php.net/manual/en/book.memcache.php ?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

掐死时间 2024-11-11 16:42:34

会话中可以存储的数据限制受到会话存储层的限制。默认会话存储是文件系统,一个会话存储在一个文件中。会话变量/数组键的名称及其数据以 序列化形式存储。管道符号将变量名称和值彼此分开。

如果您存储带有字符串的数组,那么该文件将比字符串的长度加上键的长度以及元数据的一点开销以及变量名称的大小大。

文件的大小受文件系统的限制。例如,在 EXT3 中,每个文件为 16 GB。所以这是一个“太多”了。您不能在会话中存储比存储层允许的更多的数据。

我能想到的下一个极限就是你的记忆。由于PHP需要在请求结束时将数据从文件加载到内存中并从内存存储到文件中。因此,如果您有 PHP 内存限制 那么这实际上也会限制您的会话大小。例如,PHP 5.2 中的标准内存限制为 16MB,但这可能会因您的安装而异。

顺便说一句,仅将整个内存用于会话并没有多大意义。

除了这些硬限制之外,可能还存在与并发请求数量、硬盘速度等相关的性能限制。

由于您的问题很短,我认为到目前为止您没有遇到任何具体问题,所以我认为这将超出范围。例如,如果您并不真正需要,则使用 memcached 只是开销。以及讨论设计决策(不要在会话中缓存),这些决策根本无法一般回答。

每个会话 100 或 200 KB(找到系统上的会话目录并实际查看文件的大小)不应破坏您的程序。正如建议的那样,您应该注意不再需要的旧会话文件会在一段时间后自动删除。

要了解有关 PHP 中会话配置的更多信息,请参阅 PHP 手册中的会话运行时配置< /a>.

The limit of data you can store inside a session is limited by the session storage layer. The default sessions store is the file-system and one session is stored into one file. The name of the session variable/array-key is stored as well as it's data in a serialized form. A pipe symbol separates variable names and values from each other.

If you're storing arrays with strings, then the file will be similar large than the length of the strings plus the length of the keys and a little overhead for meta data as well as the size of the variable names.

The size of a file is limited by the file-system. For example, in EXT3 this are 16 Gigabyte per file. So this is one "too much". You can not store more data into a session than the storage layer allows you to.

The next limit I can think of is the one of your memory. As PHP needs to load the data from the file into the memory and stores it from memory to the file at the end of the request. So if you've got a memory limit in PHP then this will actually limit as well the size of your session. For example, there is a standard memory limit of 16MB in PHP 5.2, but this may vary with your installation.

Using the whole memory for the session only does not make much sense by the way.

Next to these hard limits there might be performance limits which are related to the number of congurent requests, how fast your harddisk is etc.

As your question is pretty short I assume you didn't run into any concrete problems so far, so I think it would be out of scope. E.g. using memcached if you don't really need is would be only overhead. As well as discussing design decisions (never cache in sessions) which can not be answered in general at all.

The 100 or 200 Kilobyte per session (locate the session directory on your system and take an actual look how large the files are becomming) should not break your program. As suggested you should take care that old session files that aren't needed any longer get removed after a certain period of time automatically.

To learn more about your session configuration in PHP please see Session Runtime Configuration in the PHP Manual.

春庭雪 2024-11-11 16:42:34

您所要求的很多内容取决于您期望的用户数量以及您使用的硬件类型。假设您的 PHP 配置使用文件存储来存储会话信息(默认),并且您有足够的 tmp 空间,则可以在会话中存储相当大的数据块。

就我个人而言,我在会话中存储了十几个左右的数据对象(通常是与用户相关的数据库结果)。该站点位于公司内部网上,每小时处理大约一万个请求。它速度快,负载低。如果我不得不猜测每个会话接近 100KB。

我不建议在一个会话中存储超过一兆字节或两兆字节。您还需要确保 PHP 和 Apache(IIS,无论什么)也能自行清理。如果您存储大量会话数据,临时空间将很快填满。

如果你真的想让这样的东西快如闪电,并且有足够的现金,那就选择 SSD 磁盘驱动器。这将使检索速度更快。

希望这有帮助。

A lot of what you are asking depends on how many users you are expecting and the type of hardware you use. Assuming your PHP configuration is using file storage for session information (the default), and you have plenty of tmp space, fairly large chunks of data can be stored in the session.

Personally I have stored a dozen or so data objects (typically database results pertaining to the user) in sessions. The site was on a company Intranet serving about ten thousand requests an hour. It was fast and the load was low. If I had to guess each session was near 100KB.

I would not recommend storing much more than a megabyte or two in a session. You will also need to make sure PHP and Apache (IIS, whatever) are cleaning up after themselves too. If you store a lot of session data temp space will fill quickly.

If you really want to make something like this blazing fast, and have the cash, go for a SSD disk drive. That would make retrieval even faster.

Hope this helps.

沧桑㈠ 2024-11-11 16:42:34

$_SESSION 用于缓存。

如果您需要缓存内容,请使用 APCMemcached 甚至 Redis

$_SESSION is not for caching.

If you need to cache stuff, then use APC , or Memcached or even Redis.

断桥再见 2024-11-11 16:42:34

会话中的数据量会对性能产生影响。如果您打算使用文件进行会话,请注意 php 可能会遇到磁盘瓶颈。读取、写入和序列化该数据可能会导致大量磁盘 I/O,这很糟糕。

就硬上限而言,我怀疑这些限制与您的文件系统的相同。例如,如果您将大量数据保存到会话中,并且填满了磁盘,则您将无法写入其他会话。

使用 memcached 将缓解磁盘 I/O 性能问题,因为从 memcached 写入和读取速度要快得多。根据 memcached 规范,每个会话的限制为 1MB。您的会话总空间将是您启动的 memcache 实例的大小(由启动 memcache 实例时的 -m 标志决定)。

The amount of data in your session will have an effect on performance. If you intend to use files for session, note that php might hit a bottleneck at the disk. Reading, writing and serializing that data might incur heavy disk i/o, which is bad.

As far as a hard upper limit, I suspect those limits are the same as your filesystem's. For example, if you save massive amounts of data to session, and you fill up your disk, you'll not be able to write additional sessions.

Using memcached will alleviate the disk i/o performance issues, as writing and reading from memcached is much faster. Your limits there will be 1MB per session, as per the memcached spec. Your total space for sessions will be the size of the memcache instance you start (dictated by the -m flag when starting the memcache instance).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文