15

So I have been noticing in New Relic on a lot of our sites, a lot of our long page loads are happening due to Mage_Core_Model_Session_Abstract_Varien::start. I have done some research and haven't really seen anyone else talking about this.

We use Nginx, PHP FPM, Redis for Caching and Memcache for sessions. Some of my ideas are that maybe it is something else that is taking forever and it just appears that loading the session is the problem. Or somehow there is some custom code adding a lot of data to the session causing huge sessions.

I am not that knowledgeable in terms of sessions and how they are managed, however I found some articles talking about Session locking. However I don't think that people would be opening so many pages at the same time.

Some of these loads are like 20 - 30 seconds. I am just curious if anyone else has noticed this or had more knowledge on how to analyze these types of long requests due to sessions.

Improve this question
6
  • 1
    I have noticed the same behaviour with Redis used as session storage. No clues why it happens either.
    – user20317
    Commented Jan 14, 2015 at 16:09
  • 2
    Have you been able to track down the cause of this yet? I have a very similar setup (Redis for cache, memcached for sessions) and we recently started using New Relic to track performance. We're catching some 20+ second traces that seem to be caused by something in MCMSAV::start as you were seeing. Unfortunately I can't see deeper into it, a tooltip says "Deeper visibility is not available because these classes and methods are not instrumented with the PHP agent's current configuration". I have yet to investigate further. Any ideas?
    – Mageician
    Commented Oct 15, 2015 at 3:13
  • 1
    @BrianVPS I never found anything. It remains a mystery to me and never was given more time to track it down. I still see it in every project. Did you ever find anything?
    – dan.codes
    Commented Apr 28, 2016 at 15:39
  • 1
    I don't know if we found any causes, but I haven't seen this recently. We have made significant changes to the site and trimmed a lot of fat. I disabled some unused core modules, deleted a ton of unused attributes, categories, and products. Since then things are improved on all fronts. I don't know if any of it was related, but in general, getting rid of unnecessary stuff seems to help Magento significantly. It's a powerful, but bloated system with a lot of code that many sites don't need. Getting rid of the excess is very helpful.
    – Mageician
    Commented May 2, 2016 at 13:38
  • @BrianVPS I have exactly the same problem you had (20+ second traces that seem to be caused by something in MCMSAV::start). Did you find any solution?
    – Denis Spalenza
    Commented Nov 8, 2016 at 1:01

1 Answer 1

Reset to default
7

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:

enter image description here

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.