Symfony 1.4 会话随机丢失 [英] Symfony 1.4 sessions randomly lost

查看:40
本文介绍了Symfony 1.4 会话随机丢失的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

这是我几个月前开始尝试的一个问题,从那以后我一直试图解决但没有成功.

This is an issue I've started to experiment a few months ago and I've been trying to fix without success since.

症状:symfony 会以随机的时间间隔丢失会话信息并注销用户.它似乎以某种方式与站点的负载有关.当负载更高时,用户似乎更频繁地注销,甚至可能快到 30 秒.

Symptoms: At random intervals of time symfony loses the session info and logs out the users. It seems somehow to be connected with the load of the site. When the load is higher it seems that the users are logged out more often, could happen even fast as 30 seconds.

环境:自开始以来,我更改了很多设置,包括 php 版本、Web 服务器、会话存储、symfony 版本.这是当前的设置:Ubuntu 10.04、php 5.4.0、symfony 1.4.17、nginx 1.0.15 和 FPM.以下是在 factory.yml 中配置会话存储的方式:

Environment: Since this started I've changed a lot of the setup, including the php version, web server, session storage, symfony version. Here is the current setup: Ubuntu 10.04, php 5.4.0, symfony 1.4.17, nginx 1.0.15 with FPM. Here is how the session storage is configured in factories.yml:

  user:
    class: myUser
    param:
      timeout:         86400
      use_flash:       true
  storage:
    class: sfCacheSessionStorage
    param:
      cache:
        class: sfMemcacheCache
        param:
          lifetime:  86400
          host:      192.168.1.3
          serializer:  IGBINARY
          mode:        compiled
          port:        11211

我不得不提一下,我也将 redis 用于会话存储,但仍然存在问题.我真的不知道接下来要尝试什么.有没有其他人经历过类似的事情?在此阶段,任何提示将不胜感激.

I got to mention that I've also used redis for session storage and still had the problem. I really have no idea what to try next. Anybody else experienced something similar? At this stage any hint would be much appreciated.

更新:经过数月的搜索和无数次的试验和错误,我认为这可能是一个并发问题.我们的站点对 AJAX 请求的处理非常繁重,我了解到它会导致会话出现问题,除非在会话处理程序中实现了适当的锁定机制.首先,我从等式中消除了 symfony,我已将其设置为使用 php 会话.使用默认文件会话存储,我永远不会丢失任何会话.然后我将 php 配置为使用 memcache 会话存储.当然,我们已经开始看到丢失的会话.我 100% 肯定 memcached 没有耗尽内存,我已经安装了一个管理工具,并且 memcached 服务器几乎没有使用分配给它的 8GB 的​​ 2%(没有浪费,内存是根据需要分配的).然后我添加了第二个 memcached 服务器并将会话处理程序配置为使用冗余.这有很大帮助,我很少丢失任何会话.目前,这是一个可以接受的折衷方案.

Update: Ater months of searches and countless trials and errors I think it could be a concurrency problem. Our site is quite heavy on AJAX requests and I have learned that it can lead to issues with the sessions unless proper locking mechanisms are implemented in the session handler. First I have eliminated symfony from the equation, I've set it to use php sessions. With the default file session storage I never lose any sessions. Then I have configured php to use the memcache session storage. Surely enough we have started to see lost sessions. I am 100% positive that memcached is not running out of memory, I have installed an admin tool and the memcached server is barely using 2% of the 8GB allocated to it (no waste, the memory is allocated as needed). Then I have added a second memcached server and configured the session handler to use redundancy. This helped a lot, I rarely have any lost sessions. For now this is an acceptable compromise.

推荐答案

实际上我们过去几个月一直在使用的设置是 symfony 配置为使用普通的 php 会话(不是任何缓存类),然后 php 是设置使用 memcache 扩展(还有另一个称为 memcached)将会话存储在 2 个冗余 memcache 服务器上.如果我取出其中一台内存缓存服务器,我们会立即看到丢失的会话.

Actually the setup we have been using for the last few months is symfony configured to use the normal php sessions (not any of the cache classes) and then php is setup to use the memcache extention (there is another one called memcached) to store the session on 2 redundant memcache servers. If I take out one of the memcache servers we immediately start to see lost sessions.

这是唯一真正完成工作的设置.

This was the only setup that really did the job.

这篇关于Symfony 1.4 会话随机丢失的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆