1

Yes, I've read session_start seems to be very slow (but only sometimes), but my problem is slightly different.

We have a PHP application that stores very simple sessions in memcached (elasticache to be specific), and have been monitoring our slowest-performing pageloads. Almost all of the slow ones spend a majority of their time in Zend_Session::Start, and we can't figure out why. It's a very AJAX-y front end, moving more and more toward a single-page app, making a number of simultaneous requests to the backend per pageload, and some of the requests take up to three to four times as long as they should based solely on this.

It's not every request, obviously, but enough of them that we're concerned. Has anyone else seen this behavior? We were under the impression that memcache is not blocking (how could it be?), so the very worst would be a user has a bum session, but multiple-second wait times in session_start seems inexplicable.

Community
  • 1
  • 1
lazyreader
  • 48
  • 8
  • Could your use of memcached exceed the amount of physical memory and dip into swap space? – Jason Sperske Apr 03 '14 at 03:50
  • I've got phpmemcacheadmin running and keeping an eye on the cluster, and it doesn't seem like it -- we're not filling the allocated memory, and tests with a larger elasticache cluster have been inconclusive. – lazyreader Apr 04 '14 at 03:12
  • Related http://stackoverflow.com/q/13772074/168034 – phunehehe Sep 22 '14 at 09:22

1 Answers1

0

Take a look at your session garbage collection mechanism (play with probability and divisor).

If gc is slowing down the app, consider cleaning the old sessions manually (e.g. setting gc probability to 1 and running gc script via cron).

Another possibilities:

  • session mechanism is locked (so the app waits to unlock, then write)
  • too much data saved
takeshin
  • 49,108
  • 32
  • 120
  • 164
  • We already set `gc_probability` => 1, so that seems unlikely. What do you mean by "session mechanism is locked"? – lazyreader Apr 03 '14 at 16:04
  • Wait, you probably actually meant setting `gc_probability` to 0. Either way, We just did some experimenting with that in a staging environment, and the same three-second-plus traces appear. – lazyreader Apr 03 '14 at 17:50
  • I'm accepting this as the 'right' answer even though it wasn't much help in our case, since it's the right place to start looking. – lazyreader Apr 07 '15 at 15:34