Slow site - help needed.

[SpeakerRepair.com]

We are trying to figure out why some parts of our site are so slow. Such as some categories take a long time to load, while other don't.

For example, this one takes about 9 seconds to start loading the page:

http://www.speakerrepair.com/page/ca...crophones.html

This one takes about 3 seconds to start loading the page:

http://www.speakerrepair.com/page/ca...ic-access.html

These two categories have almost the same amount of products in them, and use the same page template. 3 seconds is tolerable, but 9 seconds seems way too long. Does anyone have any idea what would be causing this type of behavior? I've deleted baskets, packed data, etc. and it doesn't seem to help at all.

Thanks,
Eric

[ILoveHostasaurus]

Re: Slow site - help needed.

It's going to look pretty intimidating but the advanced diagnostics should tell you exactly what is occurring:

http://extranet.mivamerchant.com/for...ript-debug-log

A step by step version of that long thread is:

1) Make sure engine version is 5.19
2) Get yourself on the page on your site that you want to debug. If it involves submitting data, that's fine.
3) Add the following three directives to your site's Miva engine config file, which is typically mivavm.conf in your cgi-bin directory:

logfile=debug.txt
loglevel=144
logcookie=yourCookieValue

Adjust the file name and cookie value to suit your preference, or just use what I put there..

3) Grab the diagtool.mvc file (https://support.mivamerchant.com/sup...ic-application) to set a specific cookie in your browser. To do this, upload it to your site, hit it from a browser in a new window or tab from the one that has the slow page of your site. Use the cookie setting feature to set the cookie.

4) Hit shift-reload on the page you're wanting to debug, and let your browser re-post the data if necessary. Do not hit reload on your site any more until after the next step.
5) Remove those logging directives from the mivavm.conf file. Now you can use your site again.
6) Delete the diagtool.mvc file from your site.
7) Download the resulting log file from your mivadata directory and run the mvprof command (downloadable from that other thread) against it.

mvprof will you a very detailed report on every .mvc file that played a role in the serving of the page in question, as well as the number of function calls that were made, how long they took, and their names. You'll find it typically reveals very obvious causes of problems on slow loading pages; such as a module that loops through one million of the same function call, or just runs for a very long time for some reason, which you can then troubleshoot once you know where to look. The bad ones should jump out to the top of the list of time consumers. This whole process will sound like a ton of work but if you're comfortable uploading/downloading, editing text files and running a command line tool on your computer, you can probably complete it in 15 minutes or less.

Our professional services group can also perform this debugging for you as part of a site audit.

[SpeakerRepair.com]

Re: Slow site - help needed.

Thanks, David! I'll give this a go. I really appreciate your help. :)

[SpeakerRepair.com]

Re: Slow site - help needed.

I've looked everywhere and can't find the mivavm.conf file. It's not in cgi-bin, or any other folder that I can see. I'm also showing hidden files. Could the file have a different name?

[ILoveHostasaurus]

Re: Slow site - help needed.

If your host is using the config file style of configuring the engine for your site, typically the engine will be in your cgi-bin folder and have a name like mivavm but it could be named anything they chose. The config file will have an identical name with .conf on the end. If you see neither, or you see a mivavm or similarly named binary file but not matching .conf file, they are probably not using config file style configuration. The second way to configure the Miva Empresa engine is by adding environment variable directives to the web server's own config file. Unfortunately those will only be adjustable by your host, so they'd need to add the environment variable equivalents of what I listed and then restart the web server software (apache) to have them take effect. Then you do the one page reload. Make sure you end up with a debug.txt in your mivadata directory, then have them remove the directives and restart the server once more so every request you make is not generating debugging information.

The directives:

MvCONFIG_LOG_FILE debug.txt
MvCONFIG_LOG_LEVEL 144
MvCONFIG_LOG_COOKIE yourCookieValue

If they can't do either the addition or removal immediately, no big deal, just put the request in and keep using your site like normal. Once they've added them, you'll find the debug.txt shows up in the mivadata folder. Just delete it after setting your cookie but before loading the test page. Load test page, it will come back and contain only data for that one page load. Download it. Then put the request in for removal and keep using your site like normal. Once they confirm removal, delete the new debug.txt that will be sitting there.

[SpeakerRepair.com]

Re: Slow site - help needed.

Thanks, David. Our host is Hosting4Less and I've sent them an email.

[Canexan]

Re: Slow site - help needed.

Perfect timing for this thread. We're having similar issues. Even Miva Admin is running incredibly slowly.

[Canexan]

Re: Slow site - help needed.

Where do I get mvprof?

[ILoveHostasaurus]

Re: Slow site - help needed.

Sorry about that, mvprof is part of the Miva Script Compiler. You can download it for unix or windows at http://www.mivamerchant.com/support/downloads You can run the mvprof windows executable against a log file generated on a unix server.

[Canexan]

Re: Slow site - help needed.

I fixed my problem. I was using an outdated version of CurrencyMagic that had some kind of leak. I should have updated it months ago when Kent published the bug.

[SpeakerRepair.com]

Re: Slow site - help needed.

We got the debug file and the problem was with Sebenza's "Ultimate Reviews and Ratings" module. We are running version 5.15 of that module, and they are up to 5.22, so hopefully updating it will fix the slowness (fingers crossed).

Thank you to Eric at Hosting4Less (our host) for all your help in getting this debugging done and figuring out what was causing the slowness (not the host!).

Thanks again, David, for your help as well.

[Bruce - PhosphorMedia]

Re: Slow site - help needed.

Yes, another lesson on keeping everything up to date. Hopefully in the future, ALL third party modules will be able to report update status through a central view port. Meanwhile, put at least a monthly reminder on your calendar to at least check those modules (like ours :) ) that have a version check. (Ours also emails you when an update is ready.)

Another hair saving tip. Create a folder in your Email manager to "FLAG" and perhaps move emails to a specific folder when they are from Miva and their vendors. This will help you stay on top of updates and other important notices.

We are always surprised when folks tell us they never saw the 'update' notice. Remember, this is your business. Its almost as detrimental as ignoring mails from the IRS.

[SpeakerRepair.com]

Re: Slow site - help needed.

Bruce, your modules are always up to date because you send notices with links to the updates. I wish everyone would do this! :)

Eric

[Bruce - PhosphorMedia]

Re: Slow site - help needed.

Oh, I know I was preaching to the choir...in the hopes that the rest of the congregation overhears it. About 20% of our notification emails get bounced or come back with something "in order to protect ourselves..." (which you'd probably heard me rant about before).

[SpeakerRepair.com]

Re: Slow site - help needed.

Updating the Sebenza Ultimate Reviews & Ratings module helped, but it's still not great. Is Sebenza still actually in business? I've had a couple support tickets in to them but never got a response.

My host was wondering what MySQL queries the module is making? They said it might be missing an index on their column so the MySQL query might not be optimized.

Thanks,
Eric