Category section load slow after moving from shared to VPS?

So i have a customer who is currently on one of my shared servers, and i recommended that he upgrade to a VPS because he has almost 1 million inodes. Because of that i had to take him off daily backups.

Anyways, restored the cpanel account on his new VPS and whenever we load the admin>>catalog>>categories section it loads in like 30 seconds.

On the shared server it loaded almost instantly...i don't get it. The server is responding flawlessly, iowait nothing.

Anybody have any suggestions or had this same experience before? It's running on an OpenVZ container with 768mb dedicated 1024 burstable, on an i7 8 core server.

So as far as i can think it has to be some type of configuration with either openvz or somethin...i dunno i'm stumped now.

Anybody had this issue before?

on his new VPS and whenever we load the admin>>catalog>>categories section it loads in like 30 seconds.

On the shared server it loaded almost instantly
This all boils down to server configuration of the LAMP stack

There are forums dedicated to that subject
Only one might be
webhostingtalk.com

kobra:

This all boils down to server configuration of the LAMP stack

There are forums dedicated to that subject
Only one might be
webhostingtalk.com

Yeah i searched on there and couldn't find that much, i found a thread on here too about "optimizing" the page, but that didn't help much either.

Can you be anymore specific by what you mean when you say LAMP stack?

Can you be anymore specific by what you mean when you say LAMP stack?
Optimizing the elements
Linux
Apache
Mysql
Php

Ok i had my data center level 3 techs look into it and they said they tweaked a couple things but it's still taking about the same time.

Maybe so i can help them out a little bit, does the categories just load from a mysql database? Does zencart cache the category listings or does it load them each time?

Just trying to figure out a little bit more behind the category listing so hopefully we can try and figure out the problem

There is limited internal caching.

Instead, tweak your mysql (my.cnf) to maximize memory use to improve performance. Perhaps consider looking at your better-performing server's config and comparing that with your poorly-performing server's config.

Thanks for the reply, i already tweaked the my.cnf to higher settings than we have on the shared server...

The only solution i have found thus far is to disable the category counting and the page loads fine. But this is something that the client wants to have and says "well it worked fine on the shared server so i want it on my vps as well"

This just has us stumped, i've even had some of our best level 3 linux techs look at it and they don't know what could cause it.

That's why im just trying to get more information about how categories are loaded, where, when, how they are cached, and so forth so i can pass it along to them.

Thanks for everyone's help so far, still haven't figured out a solution yet though.

What are the page parse times?

kobra:

What are the page parse times?

https://www.zen-cart.com/tutorials/index.php?help=Rate+Article&article=105
:smartalec::smartalec::smartalec:

..grins, ducks, 'n' runs

Cheers
Rod

Hey thanks for the information guys, i tried enabling the parse times but i guess when iwebshop created the template they must have changed something because parse times do not show up.

I found this thread and i'm going to try and follow it to get the queries working:
http://www.zen-cart.com/forum/showthread.php?t=47527

All it shows me now is a PHP file error and parse times, but nothing about queries, maybe i just need to create the file first and set permissions to write to it:

Anyways, here's the problem site from the VPS when going to Catalog>>Categories:

Warning: error_log(/home/theuser/public_html/demo/cache/page_parse_time.log) [function.error-log]: failed to open stream: No such file or directory in /home/theuser/public_html/uksis/includes/classes/logger.php on line 60
Parse Time: 19.354s

And here's the same result from the shared server with even more categories and items:
Warning: error_log(/home/iwebshop/public_html/demo/cache/page_parse_time.log) [function.error-log]: failed to open stream: No such file or directory in /home/theexpat/public_html/uksis/includes/classes/logger.php on line 60
Parse Time: 3.392s

As you can see there is about a 16 second difference and that is on the good side...

Any ideas on the cause or how to get the queries to show?

Thanks for everyones help!

Based on the error message, it's telling you that you've specified an invalid path for the log file.

You've got it set to: /home/theuser/public_html/demo/cache/page_parse_time.log
But it should be: /home/theuser/public_html/uksis/cache/page_parse_time.log

Yeah that's just a file issue because i enabled writing parse times to log, i just had to fix the path to the cache directory...that was easy :)

But i can't get the MySQL queries to show as well as the parse times, i'm working on building a clean install to test on, we were using an OpenVZ template before.

I'm working on creating a clean CentOS install and installing everything again to make sure everything is optimized and installed correctly.

I will let you guys know how that turns out, restoring the backup as we speak....haha i mean as i type :)

The parse time output is handled by code in the original tpl_main_page.php file. Maybe the author of your custom template hacked that part out of the file.

Ok so rebuilt new template and still having same problems. Tried no cache, database, and file...still same issue.

Shared server:
Parse Time: 1.233s

VPS Server:
Parse Time: 99.333s

Without the query info it's hard to tell you whether the problem is database-related or just CPU/RAM related.
Assuming your "new template" is a custom template and that your template_default files are all untouched originals, if you switch back to the Classic Contemporary template then your parse times should appear.
How does performance compare when using that template?

Most likely your VPS hasn't been allocated enough CPU and RAM resources, nor has your MySQL configuration.