Symphony.

Time to first byte is the Symphony building time. 4s does seem quite high, but thankfully not as high as 15s! You should debug this time more with the ?profile on the end of the URL and see which rows are high in the profiler output.

The speed test you’re using may be flawed. Your browser downloads assets in parallel (sometimes two, sometimes four, or more if you’ve changed your configuration) whereas this tester downloads all assets in series — it waits for one to finish before starting the next.

Check in Firebug and you’ll see assets downloading at the same time. So webpagetest.org’s times are always going to be much higher than a real user. If your browser can download three assets at once but webpagetest.org only one at a time, then webpagetest.org’s time will be 3x the “real” time.

Thanks Nick for pointing that out to me re the parallel downloading of resources. We will get this sorted by splitting them across other domains. I have delved further into the symphony backend profiler and realized two bottlenecks. This is what is causing randomly long TTFB. The issues are:

1) The previous issue mentioned on the 1st page i.e. Blockquote

Blockquote> 0.22441101074219 SELECT session_data FROM sym_sessions WHERE session = ‘r4rfuk2096h5hf3v8bb4d20iq7’ LIMIT 1

1.8615469932556 DELETE FROM sym_sessions WHERE session_expires <= ‘1292318483’ OR session_data REGEXP ‘^([^}]+|a:0:{})+$’Blockquote

Blockquote

Both queries (especially the 2nd) now and again hit very high values sometimes even 3-4 seconds. The first query is quite straightforward so not too sure whats goin on there. Re the 2nd query, anyone used regex expressions in mysql queries?seems to be impacting performance greatly.

2) Xslt generation. I noticed that this happens only once in a while (had to keep refreshing to determine this). But sometimes it hit values as high as 10-12 seconds on certain pages! Is there a way to debug this further?

I also noticed how Engine Initialization sometimes hits over 1.6 seconds however I read somewhere that it shouldn’t take any longer than .03seconds. However, why does engine initialization randomly change values? Sometimes .05, other times .56 other times 1.6 when refreshing the page?

I hope I’m not out of scope here, just want to understand fully whats going on and pinpoint the places where optimization is needed.

Thanks as always

Thanks

Any help please guys?

Such random load times are probably caused by an external load on the server.

Are you on a shared host? In that case it could be that another user is causing a very high load, which makes your site slow.

Yeah it seems so…I have had the website installed locally and it seems much faster now. link text shows different scenarios on page refresh. Do the numbers look ok to you? Still I see discrepancies in the Engine Initialisation, however I guess this is due to the slow query sometimes being initiated.Has anyone else had issues with the — DELETE FROM symsessions WHERE sessionexpires <= ‘1292318483’ OR session_data REGEXP ‘^([^}]+|a:0:{})+$’ —

I found that Like can be 10x faster than using Regex link text Has anyone ammended the class.session.php and replaced the regex expression with LIKE? I see reluctant in changing this due to the fact no one else has complained here!

thanks once again

The performance variations with Symphony initialization could perhaps be due to the fact that PHP is an interpreted language, which means that compilation is done “just-in-time”. So when the value is low, it might be that the PHP code have been compiled recently and is being loaded from within the PHP core compiler cache.

Although, as you pointed out, it is very possible that the database is a bottleneck.

Yes…it seems the database sessions table is the bottleneck…It seems to do with the 2 week retention policy that exists…Think I might change this. However, Im still wondering how no one else has complained about the REGEX expression applied to the rows. Has anyone added an index to session_data?

Guys…I have set the session policy to 6hours instead of 2 weeks.This has cleaned up the sessions table and the performance has incredibly increased! Interesting if anyone else has any thoughts on this… Anyways thanks to all for your input!

Hello guys, I was also experiencing performance issues caused by the session tables, it's a complex website with symphony-magento integration on a dedicated server.

The problem was that MYSQL was eating up 96% CPU on page loads, causing about 10sec. page build times. By analysing the queries I noticed that this garbage collection query:

DELETE FROM ita_sessions WHERE session_expires <= '...' OR session_data REGEXP '^([^}]+\|a:0:{})+$'

was called about 50% of the times and hit up to 10s execution times. This websites has about 1k visits a day, so my session table, with default two weeks lifespan was about 150k rows. I simply reduced the session lifespan to two hours and now my table has about 1k rows: execution time dropped to 0.1s and MySQL cpu load to 17% :)

my questions are:

1. Is there a particular need to have such a long session lifespan?
2. if so, how can I make the query more efficient? looks like the regexp on such big table is very slow
3. why is that query executed so often?

thanks a lot!

Isn't the session-table for manager logins only? I also noticed on some previous site with S2.1.2-installations this table becoming exceedingly large. I remembered there was a bug in S2.0.7 which caused the session-table to not cleanup properly. Could this be happening again this time?

I have done significant work to sessions class that is on the integration branch. These include removing the regex completely, the query is now a simple is null, reducing garbage collection from a 33% to 10% chance and there's also no query to check for the existence of the session table anymore as its created during installation.

@brendo, is it going to be in 2.2.1 or 2.2.2? I can't remember seeing it on the list...

If it's already in the integration branch, I would expect to see it in the next release. Besides other cool stuff, BTW.

It'll be in 2.2.1 which is tentatively due as a beta at the end of the month.

It wasn't on the issue tracker (well not in recent times), but was brought up internally by the WG's/discovered while documenting the codebase in 2.2.