ee-1.14ee-1.14.1.0memcachedredissession
We are using Magento EE 1.14.1.0 and are seeing very long times for Mage_Core_Model_Session_Abstract_Varien::start method. We tried using Memcached and Redis for session storage both with the same result.
Is this normal? Is this a New Relic problem? Any ideas how to fix it?
Screenshots below:
I will be very grateful for any suggestion.
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.
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.
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::start for ~30 seconds (my session lock wait timeout I think).
This report on New Relic has multiple downsides as I see it
I've seen a few common causes for this, not a definitive list by any means
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.
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.
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.
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_BlackHoleSession module 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.
During the conference Fabrizio Branca said he was able to disable session locking completely without any ill effects, test at your own risk.
Best Answer
There is multiple issues for this case.
First Magento recommend Memcache for M2, I suppose the same for M1 : http://devdocs.magento.com/guides/v2.0/config-guide/memcache/memcache.html We had experiment this issue with Redis and we change
session_savetodb.The second, is located here :
Mage_Core_Model_Resource_Session::gc. Randomly Magento clean session. This clean cause a lock. A solution is to disable this random clean and use a cron to do the job (overload this class and change$_automaticCleaningFactorvalue to 0). This works great for us (with db).Hope this help,