session_start 似乎很慢(但只是有时) [英] session_start seems to be very slow (but only sometimes)

问题描述

出于某种奇怪的原因，就在今天，我们的服务器决定在会话开始期间非常慢.对于每个 session_start，服务器要么在 30 秒后超时，要么需要大约 20 秒才能启动会话.这很奇怪，因为它已经很长时间没有这样做了(我们的服务器上一次这样做是在大约 7 个月前).我尝试将会话更改为通过数据库运行，并且效果很好，但是，由于我们当前的网站已构建，因此需要几天时间才能浏览每个页面并更改会话加载以包含新会话处理程序.因此，我的问题仍然存在:

For some odd reason, just today our server decided to be very slow during the starting of sessions. For every session_start, the server either times out after 30 seconds, or it'll take about 20 seconds for it to start the session. This is very weird, seeing as it hasn't done this for a very long time (the last time our server did this was about 7 months ago). I've tried to change the session to run through a database instead, and that works fine, however, as our current website is built, it'd take days to go on every page and change the loading of sessions to include a new session handler. Therefore my question remains:

为什么这么慢，为什么只是有时?

Why is it so slow, and why only sometimes?

我们在一个专用的 hetzner 服务器上运行，它有 24GB 的内存，CPU 的速度足以运行一个简单的网络服务器(我相信是 Xeon，但我不确定).我们使用 apache+fastcgi+php5 设置在服务器上运行 debian.

We run on a dedicated hetzner server with 24GB's of ram, and a CPU fast enough to just run a simple webserver (a Xeon, I believe, but I'm not sure). We run debian on the server with an apache+fastcgi+php5 setup.

服务器不会报告太多负载，无论是通过 server-status 还是 top 命令.Vnstat 报告我们的网络链接没有任何问题(同样，这不会导致本地会话处理缓慢).IOtop 报告接管整个硬盘的进程没有问题.如果通过 vim 完成，写入会话文件所在的 tmp 文件夹的工作速度很快.

The server doesn't report much load, neither through server-status as well as the top command. Vnstat reports no problem whatsoever with our network link (again, that wouldn't result in a slow local session handling). IOtop reports no problem with processes taking over the entire harddrive. Writing to the tmp folder where the session files are located works fast if done through vim.

再次说明，我在这里主要关心的不是我们是否应该切换到会话的数据库或内存缓存版本，这只是问为什么会发生这种情况，因为我看的一切at 似乎工作正常，除了 PHP 本身.

Again, to make this clear, my main concern here isn't whether or not we should switch to a DB or a memory-cached version of the sessions, it's simply to ask why this happens, because everything I take a look at seems to be working fine, except for the PHP itself.

编辑:我们的 PHP tmp 目录中的最大文件是 2.9 MB，所以我相信不会产生任何影响.

EDIT: The maximum file in our PHP tmp directory is 2.9 MB, so nothing that should make an impact, I believe.

更新:我从来没有弄清楚出了什么问题和/或如何解决它，但在我们切换到 memcached/db 会话后问题就消失了.

UPDATE: I did never figure out what was wrong and/or how to fix it, but the problem disappeared after we switched over to memcached/db sessions.

推荐答案

你试过 session_write_close(); 吗?这将禁用会话变量中的可写性，但您仍然可以从中读取数据.稍后当您需要编写会话变量时，重新打开它.

Have you tried session_write_close(); ? This will disable write-ability in session variables but you can still read data from them. And later when you need to write a session variable, reopen it.

我也遇到过这个问题，但是这东西很有魅力.这就是我所做的:

I have also suffered from this problem but this thing worked like a charm. This is what i do:

session_start(); //starts the session
$_SESSION['user']="Me";
session_write_close();   // close write capability
echo $_SESSION['user']; // you can still access it

这篇关于session_start 似乎很慢(但只是有时)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！