CODEWITHSUNDEEP
phpperformancesymfonysessionio
jotadepicas
jotadepicas

Reputation: 2493

Why PHP Symfony sfSessionStorage::initialize sometimes takes a really (really) long time?

We have different PHP Apps, both in symfony 1.4 and symfony 2, and all of them, at some point, have requests where sfSessionStorage::initialize takes a very very long time.

I'm talking about several minutes to load. Take this newrelic trace for example:

enter image description here

Here you can see sfSessionStorage::initialize took 185 seconds. We've been debugging this for several days now, with no success so far. We've looked into GC settings, event tried mounting where the sessions are stored in the filesystem into a RamDisk, with no effect.

What could be the cause of this? Have you ever encontered the same problem? Any help is greatly appreciated, thanks!

Upvotes: 5

Views: 581

Answers (3)

jotadepicas
jotadepicas

Reputation: 2493

Thanks to the comment of @SomeHelpingDude pointing to this thread: https://forums.powweb.com/showthread.php?t=77977, there was mentioned the possibility of implementing your own session handler (http://www.php.net/manual/en/function.session-set-save-handler.php).

We did that, and implemented a session handler that uses memcached. Now the problem is gone.

I'm assuming the native way of session handling (filesystem) ends up suffering from deadlocks and other performance issues that can only be avoided by not using the filesystem at all.

I'm still puzzled about why a ramdisk didn't fixed this in the first place, so if someone can explain this I will change the accepted answer. Thanks!

Upvotes: 1

Alex Blex
Alex Blex

Reputation: 37048

strace may shed some light on what's going on.

Assuming you cannot reproduce the problem with cli, I would recommend to limit number of processes to 1 (MaxRequestWorkers for mod_php and max_children for php_fpm), attach strace to the process and check where it hangs.

For example in php_fpm case:

  • open /etc/php5/fpm/pool.d/www.conf and ensure settings 

    pm = static  
pm.max_children = 1

  • restart php_fpm and nginx

  • grep aux | php to find out the process id
  • sudo strace -p followed by the process id
  • try to reproduce the problem

If it sticks for minutes with a single system call, you will clearly see the blocker right in the stdout of strace. If there is no single blocker, but rather a long loop of repeated system calls, you will probably need to log it to a file and analyse it later. E.g. sudo strace -p {pid} | tee /tmp/strace.log.

If problem is not reproducible with single worker, try to increase number of workers, and capture strace for all processes.

Upvotes: 3

Somnath Muluk
Somnath Muluk

Reputation: 57786

Not sure this will help, but check.

If you handling session manually then you should make Sessions Turning Off, in frontend/config/factories.yml

all:
  storage:
    class: sfSessionStorage
    param:
      auto_start: false

You should see Deactivating the Unused Features for increasing performance.

Just another guess :

Sessions are dependent on files. So check your system is capable of making that many files open required for sessions. Or is there any issue for creating files.

Upvotes: 2

Related Questions