TOPIC: Site very slow after migration

I wanted to ask if CMigrator folks had any idea about the problem we've been facing.. After migrating a large site with about 4000 articles, our site is running extremely slow. We've tried installing memache and gzip, but still the site loads incredibly slow (20 seconds). However, we have a powerful server that should be able to handle a database of this size (200MB), CPU usage is very low, and only 10% RAM usage.

Someone mentioned that this might be because of the way that the tables were set up by the migration... any ideas? Could it simply be because all of the content was migrated into a single category? Something else?

the site:

216.14.126.36/

Hey Eric,
Are you using just com_content? Or do you use k2?
The default article manager(com_content) is not known to be very performant (or at least it wasn't in the past - I don't know if that has changed, but please check it with k2).

Also another thing that was troubling the joomla community is the #__asset table.
Read a little more here:
docs.joomla.org/Fixing_the_assets_table
And maybe try this script to determine if there are problems or not:
github.com/ikajaste/Joomla-2.5-Asset-Weaver#readme

I don't know which version of CMigrator you used to transfer the site, but in the past (like 4 months ago) we didn't handle the asset table properly. (in the current version this is fixed) So maybe it is worth a try.

Let me know how it goes! (I love performance problems )
Daniel

Also a good thing to do would be to enabled the debug mode and to look at how many queries are executed - how much ram was used to make the site, which part of the site creation took the most time etc
The debug is very powerful!
Daniel

okay, I've enabled debug mode, does it tell you anything? We're using com_content, unfortunately... I guess that was a mistake. There's no way to turn back from it 4000 articles later, is there?

Also, regarding the script, I'm not sure I understand correctly... I've copied this script to the Joomla folder, then I try to run it in putty with the command:

php assetweaver.php configuration.php

And it just displays a ton of PHP. Is there something I'm missing?

there was a response here from Peter, but it was deleted. Was that because the info in it was wrong?

On his suggestion, I've contacted the template maker and they can't see anything rong with the template. I also contacted our host and they can't find anything wrong on their end either. The only thing I can think of is there is something wrong with the database tables?

could someone answer the questions in my previous thread about how to test the asset table? I'm not understanding how to do that.

Hey Eric,

My post wasn't right actually. I thought those 40MB is a size of download for every user when someone opens your site, but it is actually size of RAM memory taken.
I also saw that your tweet module takes about 5s to load data, maybe you should check that also.
Daniel is way better on performance fixing.

I actually already tried disabling all the major extensions, which had almost 0 effect. Could I possibly give you guys server access to see if the problem is the asset table?

Email me at This email address is being protected from spambots. You need JavaScript enabled to view it. and I'll try to have a look (but you'll have to buy extensions for the next couple of years if I figure out what is wrong on your site )

Cheers,
Daniel

Hi Daniel,

I wanted to let you know that this weekend we discovered that our speed issues were in fact caused by the asset table. We installed a component called ACL Manager:

extensions.joomla.org/extensions/access-...c6InRhYmxlJ3MiO30%3D

This component was able to automatically detect and repair the problems with our asset table.

After repairing, the speed of our site increased by about 300%. The site had been constantly overflowing the memory with MySQL temporary files and then overflowing the write them to the harddrive. After repairing our asset table, everything was fixed.

I do believe that the version of CMigrator that we used was version 2.0, though it is possible that we simply ugraded to 2.0 from a previous version of CMigrator after we had migrated the articles (I don't remember).

But I wanted to let you know because there may still be an error in CMigrator, and this error ultimately caused our site to crash during our launch, and forced us to pay nearly $2000 for a dedicated server to be able to handle all of the speed problems that were being caused. Our project suffered a great deal, and I wanted to encourage you to investigate and ensure that there is not still an issue with CMigrator.

Hey Eric,
Thanks for letting me know about your progress. I'll get a copy of ACL manager and will look at what it says about the sites after a migration.

Regards,
Daniel