Quote from: Jess at Nov 28, 2010, 02:14 PM
I use Media Temple as a host since their service is great I don’t usually question it but I will look.
There’s been lots of anecdotal evidence that MT Grid Server accounts have serious issues, sporadically.
Hello Everyone,
I’ve been a fan of MODx for a long time. I recently upgraded to Revolution 2.2.2-pl and it’s very, very slow for me. Not only the Manager but front-end pages take longer to load than before I installed MODx...up to a few seconds - and these are very content light pages with no Javascript.
Is there any way to beef up performance or do some performance testing? I’ve read that the EXTjs stuff makes the manager slow, which I can understand although it’s still a little painful but could this effect the performance of the front-end site so much?
Thanks,
- Jess
[^qt^], [^q^]
MODX Staff
Not at the moment. Since MODx uses xPDO and xPDO uses PDOStatements directly in many cases, there is no way to trap all of the database calls currently, as that would require not allowing direct use of PDOStatements. IOW, we would have to wrap the PDOStatement objects with code to track the timing. We will be working towards a solution, but it’s an architectural conundrum currently. For now, I would suggest adding some timing code to snippets you want to check timing of directly, or using something like the Executioner snippet I posted on my blog.
Slightly off topic, these two:are always 0, even when retrieving from the database. Those values would be interesting to have, is there another way to them?[^qt^], [^q^]
MODX Staff
If you are referring the the Grid, this is because it uses remote MySQL hosts, and obviously the latency of the TCP/IP connections required to communicate with the database when it’s not on the local web server is going to be much higher. If you turn on cache_database on the Grid, you will notice a huge difference in performance in between cache clearing as this caches the result sets from the database queries, even if your Snippets are non-cacheable.
This is a (mt) issue! I ditched them for site5 and my sites benchmark PHP/MySQL up to 79% faster.
Quote from: nsfdev at Dec 31, 2010, 05:33 PMNot at the moment. Since MODx uses xPDO and xPDO uses PDOStatements directly in many cases, there is no way to trap all of the database calls currently, as that would require not allowing direct use of PDOStatements. IOW, we would have to wrap the PDOStatement objects with code to track the timing. We will be working towards a solution, but it’s an architectural conundrum currently. For now, I would suggest adding some timing code to snippets you want to check timing of directly, or using something like the Executioner snippet I posted on my blog.
Slightly off topic, these two:are always 0, even when retrieving from the database. Those values would be interesting to have, is there another way to them?[^qt^], [^q^]
MODX Staff
No, I believe they are logged when
Thanks. I’m guessing there are similar restrictions on logging the raw queries that end up getting executed when using methods like getObjectGraph?
$modx->setDebug(true);