magento-1.9memcachememcachedsession
I am using memcache for session storage and on category pages I have noticed in new relic transactions where varien session start can take over 30 seconds.
It can possibly be something to do with session locking, but I thought this wasn't really an issue when using memcache.
Anybody ever faced this or have ideas what could be causing this.
Pankaj,
Contrary to popular belief, neither using APC or Memcache as cache/session backends will make a noticeable difference to single-user page load time - unless you had a disk I/O bottleneck to begin with (meaning that the memory backed cache will outperform the slow disk based cache).
If you don't have I/O issues, then enabling them won't make a difference to the actual page load time.
Where they'll come into play is in high concurrency situations, synthetic benchmarks like Siege/AB will demonstrate this very clearly, with an almost 50% increase in request/s. How this translates to real-world performance however, isn't so dramatic.
You'll know if it is working if the var/cache directory is empty, and if using Memcache for sessions, if the var/session directory is empty.
If you use file-backed slow_backend, then you'll still see cache tag data created in var/cache - but not the cache data itself.
Bottom line, if you are trying to improve page-load time performance, changing the cache store isn't going to make a noticeable difference unless your server's HDDs are so contrained that serving files from disk is a bottleneck.
This is most likely related to a phenomenon regarding filesystem sessions. Despite what you're reporting via using Mecached for sessions I have only ever seen this myself when in fact I was using filesystem.
This has been covered before over here:
https://magento.stackexchange.com/a/3721/336
In fact a screenshot of a cachegrind reveals the exact point at which the session startup is taking an inordinate amount of time is in Mage_Core_Model_Session_Abstract_Varien::start as you correctly pointed out:
In the referenced thread there was the suggestion that this effect may be lessened with an in-memory session storage - but no concrete data exists that I know of to support the theory. If you're in fact using memcached then it stands to reason that the PHP-level session lock would prevent future requests to the session storage from being granted until the lock is released.
In general this is usually seen only on requests requiring access to session information, so architecting your frontend theme will be beneficial to limit the amount of access needed to avoid potential locks when a user has another tab or another long-running request in progress when deciding to move away.
HTH, Cheers.
Best Answer
I've seen this quite a lot on New Relic as well.
From what I've seen there are a few different causes, I don't have a complete understanding of this issue but it is something I've been looking into recently. Here's my findings.
Sessions in Magento, Locking, and New Relic
Every controller action in Magento uses the session, whether it needs to or not. The session is eagerly instantiated in Mage_Core_Controller_Varien_Action::preDispatch
If you have session locking enabled, this means that for the duration of the request your session is locked down until the request completes. I haven't found the bit of code that releases the session lock yet, but I'm pretty sure it's in there somewhere.
Ultimately this means if you fire off multiple concurrent requests to Magento controller actions from the one location using the same session, you will have to wait for some of those requests to complete and unlock the session to proceed. I usually see this as a slow transaction on new relic stuck at
Mage_Core_Model_Session_Abstract_Varien::startfor ~30 seconds (my session lock wait timeout I think).This report on New Relic has multiple downsides as I see it
Causes
I've seen a few common causes for this, not a definitive list by any means
Bots
Crawlers like Baidu and Yandex being a being a bit rude and battering the website. They're being run from one location firing off numerous requests, using the same session, and tripping up the session locking mechanism, hence showing slow transactions in New Relic.
Ajax calls to Magento controller actions
With varnished websites customer specific data must be loaded with care, some websites manage this by using ajax calls to the Magento backend to get the required data. I have also seen some websites using ajax calls to the backend to get product specific information, such as the amount left in stock when an item is on sale.
If a single page triggers multiple ajax calls to the backend on page load, it can potentially trigger the session locking mechanism. The more ajax calls back to the Magento backend the more likely you are to experience locking.
Varnish ESI
The same as above really, except instead of using ajax calls it uses Edge Side Includes which seem to be new calls to the backend.
My plan
I have not actioned this yet so it's still purely theoretical, but it's something i'm looking into doing over the next few months.
I brought this problem up during the Mage Titans UK 2016 conference and Fabrizio Branca pointed me towards the following module: https://github.com/AOEpeople/Aoe_BlackHoleSession.
Based on a regular expression the module will prevent Bots from creating real sessions, this should have the benefit that no session lock will be hit, and that your session resources won't be battered by rude bots. Bots should no longer pollute your New Relic readings.
For ajax/ESI calls to get customer data there on cached pages there's nothing you can do that I can see. You need access to the session in order to retrieve customer specific data.
However, for ajax/ESI calls to get catalog specific data (such as limited stock) I don't see any need for a session to exist on that request at all. My plan for the future is to trial out an extension to the
Aoe_BlackHoleSessionmodule so that I can silo off requests to a specific URL as being sessionless.I'm less familiar with the internals of ESI, so sadly I don't have too much to comment there.
An alternative
During the conference Fabrizio Branca said he was able to disable session locking completely without any ill effects, test at your own risk.