This will not make a difference as session write locking happens no matter
which method you use for session management, I wrote a blog article about
this a while back as we were having issues with asynchronous ajax requests
being processed synchronously instead.:

http://garethmccumskey.blogspot.com/2009/10/php-session-write-locking-and-how-to.html

On Tue, Nov 9, 2010 at 6:42 AM, stephenrs <[email protected]> wrote:

> I finally tracked this down. The delay (at least in my situation) is
> happening when sfSessionStorage.class.php tries to start the PHP
> session (simply by calling session_start()), and is caused by a file
> locking condition on the session file itself (CentOS 5.3). There is
> some info in the comments of the PHP manual page for session_start(),
> as well as around the net.
>
> In my situation this appears to have been caused several of my
> components being executed/rendered on certain requests, which were all
> competing for access to session info.
>
> I haven't implemented a solution yet, but I'll probably end up either
> moving to database-based session storage, or some other type of file
> based storage using session_set_save_handler().
>
> Hope this helps.
>
> SS
>
> On Oct 28, 10:12 am, Lesly <[email protected]> wrote:
> > Any news about the problem?
> >
> > On Oct 22, 4:05 pm, Thomas Rabaix <[email protected]> wrote:
> >
> > > Are you storing doctrine object into session ?
> >
> > > On Thu, Oct 21, 2010 at 11:45 PM, Thomas Ohms <
> [email protected]>wrote:
> >
> > > > Are you using cache? Do you maybe have different caching compared to
> your
> > > > dev an prod server?
> >
> > > > 2010/10/21 stephenrs <[email protected]>
> >
> > > > I'm preparing a site for launch - moving it out of my local dev
> > > >> environment to a remote VPS host, and I've discovered that sometimes
> > > >> pages take up to 60+ seconds to load on the VPS. Using the symfony
> > > >> debug toolbar, I've further discovered that the delay is happening
> > > >> during the loading of my factories. Going even further, I patched
> some
> > > >> symfony files (temporarily) according to a tip here:
> >
> > > >>
> http://groups.google.com/group/symfony-users/browse_thread/thread/99e...
> > > >> to get a better idea about what is going on.
> >
> > > >> Apparently the delay is happening during the loading of Factories :
> > > >> storage (which comprises 99% of the total request time), but that's
> > > >> about all I can tell at the moment. The delay doesn't happen on
> every
> > > >> request, and during these requests my server is essentially idle,
> with
> > > >> httpd threads occupying most memory (according to top).
> >
> > > >> Since I've never seen this problem happen on my local box, I'm
> > > >> guessing it's somehow related to the config of my remote server, but
> > > >> at this point I'm at a bit of a loss. Also, my session storage is
> the
> > > >> default PHP file-based storage. I've been considering upping the
> > > >> memory on my VPS plan (for several reasons), but I'm wondering if
> this
> > > >> would have any impact on factories loading, as I would guess that
> this
> > > >> is an I/O issue.
> >
> > > >> Has anyone seen anything like this? Any suggestions as to what might
> > > >> be causing it? Workarounds?
> >
> > > >> Any help would be appreciated.
> >
> > > >> SF 1.4.6, PHP 5.3.3, MySQL 5.1.5
> >
> > > >> Note: I've cross posted this to the main sf forums because it's not
> > > >> clear to me where folks are hanging out these days...
> >
> > > >> --
> > > >> If you want to report a vulnerability issue on symfony, please send
> it to
> > > >> security at symfony-project.com
> >
> > > >> You received this message because you are subscribed to the Google
> > > >> Groups "symfony users" group.
> > > >> To post to this group, send email to [email protected]
> > > >> To unsubscribe from this group, send email to
> > > >> [email protected]<symfony-users%[email protected]>
> <symfony-users%[email protected]<symfony-users%[email protected]>
> >
> > > >> For more options, visit this group at
> > > >>http://groups.google.com/group/symfony-users?hl=en
> >
> > > >  --
> > > > If you want to report a vulnerability issue on symfony, please send
> it to
> > > > security at symfony-project.com
> >
> > > > You received this message because you are subscribed to the Google
> > > > Groups "symfony users" group.
> > > > To post to this group, send email to [email protected]
> > > > To unsubscribe from this group, send email to
> > > > [email protected]<symfony-users%[email protected]>
> <symfony-users%[email protected]<symfony-users%[email protected]>
> >
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/symfony-users?hl=en
> >
> > > --
> > > Thomas Rabaixhttp://rabaix.net
>
> --
> If you want to report a vulnerability issue on symfony, please send it to
> security at symfony-project.com
>
> You received this message because you are subscribed to the Google
> Groups "symfony users" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]<symfony-users%[email protected]>
> For more options, visit this group at
> http://groups.google.com/group/symfony-users?hl=en
>



-- 
Gareth McCumskey
http://garethmccumskey.blogspot.com
twitter: @garethmcc

-- 
If you want to report a vulnerability issue on symfony, please send it to 
security at symfony-project.com

You received this message because you are subscribed to the Google
Groups "symfony users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-users?hl=en

Reply via email to