Performance issues with 2.2.1 advanced install w/session-less contexts

I just upgraded a 2.2.0-pl2 advanced install (core below webroot) to 2.2.1, mostly to try out Jason's post about session-less contexts: http://develop.modx.com/blog/2012/04/05/new-for-2.2.1-session-less-contexts/. However, I'm not really seeing any sort of speed boost; in fact, it's slower, and I've got a new bug.

Basically, my web context is generating a JSON feed using getResources. The rendered page is small (4.6K), and under 2.2.0, Pingdom Tools (and a few others) were loading it in about 225ms. Under 2.2.1, the exact same page is loading in around 600ms, and that's with sessions disabled. Enabling sessions does practically nothing -- it's not any slower, but it's not any faster, either.

In terms of bugs, my console systemwide seems to be a bit flakier. It's not returning anything in the error logs, but certain actions, like clearing the cache, seem to cause it to hang more often than it used to.

Any suggestions?

P.S. I'm also having a problem with Big Brother if anyone is interested, but since that's not a core discussion, I'll start a separate thread.

Two other details that might be helpful:

• This is a multi-context site. I'm switching contexts via a hacked-in switch statement in index.php
• I'm running getResources through getCache first in my resource call.

Would either of these two things have an effect, or require me to use sessions? It seems to still work; it's just not faster. Also, I am seeing now that with sessions on, Pingdom is coming in around 900ms a lot of the time. So, it may be working, but is still slower than 2.2.1.

As long as you are properly caching things, you should see a significant boost when disabling sessions. If you are not, check your Templates and anything else included in the Resource you are testing. Make sure everything is cacheable. If you still do not see any improvement, we can explore if the issue may be related to Permission checks on Categories and/or Resource Groups. You can disable these checks in your front-end Contexts as well, using the access_category_enabled and access_resource_group_enabled Settings.

Here's my setup, if this helps.

• My API is a resource, and "Cacheable" is checked
• That resource has a blank template, other than [ [*content] ]
• The only thing in the resource's content is a getCache call, which I'm calling uncached per getCache's documentation.
• getCache is then accessing a wrapper snippet I wrote for getResources. It does nothing except take parameters from the query string and built &tvFilter and &where params for getResources.

That's pretty much it. No other moving parts I can think of. Anything obvious here?

You should definitely see a difference on the same exact request URI (including the query string) once cached, unless you are changing the key getCache uses by default to cache each unique request, assuming everything else is cacheable.

I assume when you say "switch" you mean "initialize" in regards to the hacked index.php, e.g. $modx->initialize() vs. $modx->switchContext() ?

Hmm...very weird then. Yes, I'm using the exact same URI and haven't even passed anything into the query string for these performance tests. I also haven't explicitly changed any keys in getCache. And by "switch," yes, I meant initialize. It looks like this:



It's a little hacky, but I'd rather tweak the index file than have to load a plugin for something so base-level.

Anyway, does that seem problematic? If you think this is a more systemic problem and want to see my setup, I'd be glad to give you a temp login so you can see for yourself.