Performance very slow when navigating through website - Help Needed to understand why

bluesteam

bluesteam

Verified User
Joined
Jan 28, 2021
Messages
66
Hello,

About a year ago my client purchased a VPS server from me. The server was hosted in the UK.

Recently the provider has indicated that they are pushing up their prices so the client wanted to anyway move the server to be more local here in South Africa and purchased a new server through me but this time from a local provider.

My client runs and online store in Prestashop with +-40 000 products.

The server in the UK is running cPanel on Centos 7.
The NEW server in South Africa is also a VPS server but running DirectAdmin with CloudLinux and the resources have been doubled on the server.

The same site running from the CURRENT server is much faster than the site running on the NEW server:

CURRENT SERVER:
2 Cores
2GB RAM
50GB Storage
cPanel
Centos 7

NEW SERVER
4 Cores
4GB RAM
250GB Storage
DirectAdmin
Cloudlinux

We decided to go for DirectAdmin because of the price hikes from cPanel and the client doesn't want such hefty price hikes every year. So I am new to DirectAdmin and hoping someone can guide me here. cPanel was a breeze. It was just an install and forgot situation.

CURRENT SERVER URL: https://www.performanceproducts.co.za
NEW SERVER URL: https://testing.performanceproducts.co.za

So I thought at first that the problem was possibly that Cloudlinux was limiting resources so I set the limits for the webapp user and the clients user to be unlimited but this didnt resolve anything.

The command I ran was this: lvectl set <userid> --unlimited

I then checked in cloudlinux and the limits were now unlimited but still no change.

So I then thought that maybe mod_security was causing the issue so I disabled that but still no change.

I then enabled memcached in the PHP options on the server and then installed memcached by running the command "yum install memcached" for his online store. I then also added the memcached server through the prestashop admin dashboard to ensure the site was using it but STILL no change to the performance.

I then thought that maybe this was a prestashop problem but quickly dismissed that because the CURRENT server is running it fine as you can see when you navigate through the site on the CURRENT server URL.

So I am not sure what to do now because the client is upset that the NEW server with MORE resources is not performing properly and the only differences that we know if is that the Control Panels are different and that we are running CloudLinux vs Centos 7.

Any help and guidance would be greatly appreciated.
 
Check your dns looks like you dont have all your dns set up correctly.

intoDNS: performanceproducts.co.za - check DNS server and mail server health

intoDNS: Checking health and configurtion of DNS server and mail server for domainperformanceproducts.co.za.
intodns.com intodns.com

When I click on the links they are just as fast to the eye. No super fast which below backs up.

Current server D rating https://gtmetrix.com/reports/www.performanceproducts.co.za/qbwlFZ1Z/

New server F rating https://gtmetrix.com/reports/testing.performanceproducts.co.za/YHlnKWo8/

Neither server is real good. It most likely due to needing to be tuned.

Looks like you need to tune the Mysql server and have him compress all of his images for starters. If it's the new version of prestashop its coded pretty poorly.
bluesteam said:
cPanel was a breeze.
Click to expand...
For sure it was. Once you learn DA it's a breeze to but it requires more Admin knowledge. It not all click a button. Start reading the documentations. Have fun.

Welcome to the forum and welcome to DA.
 
Make sure the php memory limit is set high enough, default of 128mb isn't enough for a webshop, try 512mb or even 1gb (you set this in the cloudlinux php options, in your case)
 
bdacus01 said:
Check your dns looks like you dont have all your dns set up correctly.

intoDNS: performanceproducts.co.za - check DNS server and mail server health

intoDNS: Checking health and configurtion of DNS server and mail server for domainperformanceproducts.co.za.
intodns.com intodns.com

When I click on the links they are just as fast to the eye. No super fast which below backs up.

Current server D rating https://gtmetrix.com/reports/www.performanceproducts.co.za/qbwlFZ1Z/

New server F rating https://gtmetrix.com/reports/testing.performanceproducts.co.za/YHlnKWo8/

Neither server is real good. It most likely due to needing to be tuned.

Looks like you need to tune the Mysql server and have him compress all of his images for starters. If it's the new version of prestashop its coded pretty poorly.

For sure it was. Once you learn DA it's a breeze to but it requires more Admin knowledge. It not all click a button. Start reading the documentations. Have fun.

Welcome to the forum and welcome to DA.
Click to expand...
I'm not convinced the problem is with the hardware. If this were true then the new server is a complete ball of crap because the new server hardware has double the resources as well as it being local vs international. Local cuts down on server access time by +-150-200ms which in my experience has always been quite an obvious improvement.

GTMetrix scores are not based on hardware alone. That F and D rating are based on all tests overall.

Some info that has come to light now is that the CURRENT server is running an older version of Prestashop with far fewer products and the NEW server is running the latest version of Prestashop with 40000 more products.

This is a huge difference so I'm suspecting that the tables might need better indexing.

I have never had to tune a myself system as I'm not a DBA. This is why I'm starting to much prefer cPanel even though it is a "one-click" setup. We don't want to work more in life. We want to work smarter.

That higher premium is starting to look acceptable now.

Which documentation in DirectAdmin is best to go through in order to do just that?

k1l0b1t said:
Make sure the php memory limit is set high enough, default of 128mb isn't enough for a webshop, try 512mb or even 1gb (you set this in the cloudlinux php options, in your case)
Click to expand...
We have increased the memory to 2GB and removed all limits in cloudlinux and disabled mod_security.
 
bdacus01 said:
Check your dns looks like you dont have all your dns set up correctly.

intoDNS: performanceproducts.co.za - check DNS server and mail server health

intoDNS: Checking health and configurtion of DNS server and mail server for domainperformanceproducts.co.za.
intodns.com intodns.com
Click to expand...

One additional thing I wanted to add regarding the DNS is that the www.performanceproducts.co.za domain is still hosted on the CURRENT server. The testing.performanceproducts.co.za is now hosted on the NEW server.

The report you linked is only complaining about issues that will not affect performance.

The first is one about the parent tld's which is unrelated
The other is about the name servers being in a different subnet, again unrelated
The other is a warning about a single point of failure which is also unrelated
The last is a warning is about MX records which is unrelated

So from my point of view, there is nothing wrong with the DNS.

The only DNS changes that were made for this testing was to point the testing subdomain to the NEW server IP so that we could run the tests from the NEW server so the DNS is not actually a problem.
 
run mysqltuner and tune your mysql server on new VPS.
also check what CPU cores you have, maybe old server has fresh generation CPU 2x4Ghz, and new cheaper VPS has old CPU with slow 4x2.6Ghz
 
I installed and ran the tuner but I have no clue what Im looking at as I am not a DBA. :-(
 
General recommendations:
Reduce your overall MySQL memory footprint for system stability
Dedicate this server to your database for highest performance.
Configure your accounts with ip or subnets only, then update your configuration with skip-name-resolve=1
We will suggest raising the 'join_buffer_size' until JOINs not using indexesare found.
See https://dev.mysql.com/doc/internals/en/join-buffer-size.html
(specially the conclusions at the bottom of the page).
Increase table_open_cache gradually to avoid file descriptor limits
Read this before increasing table_open_cache over 64: https://bit.ly/2Fulv7r
Read this before increasing for MariaDB https://mariadb.com/kb/en/library/optimizing-table_open_cache/
This is MyISAM only table_cache scalability problem, InnoDB not affected.
See more details here: https://bugs.mysql.com/bug.php?id=49177
This bug already fixed in MySQL 5.7.9 and newer MySQL versions.
Beware that open_files_limit (655350) variable
should be greater than table_open_cache (2000)
Before changing innodb_log_file_size and/or innodb_log_files_in_group read this: https://bit.ly/2TcGgtU
Variables to adjust:
*** MySQL's maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***
join_buffer_size (> 256.0K, or always use indexes with JOINs)
table_open_cache (> 2000)
innodb_buffer_pool_size (>= 1.1G) if possible.
innodb_log_file_size should be (=16M) if possible, so InnoDB total log files size equals to 25% of buffer pool size.
Click to expand...
The memory situation baffles me. The box has 8GB RAM and this is a default install of DirectAdmin. The server only runs 1 website which is an online store with 40 000 products apart from DA itself.
 
higher must be current config, put here all output
maybe you have max_allowed_packet high, script counts total consumption max_conn * (each conn memory + max_allowed_packet)
so if you have 150 connections with 5mb/connection and max_allowed_packet 32mb - totally=150*(5+32)=5.5gb, and if max_allowed_packet 128M
you will see 150*(5+128)=19,6gb but you will never reach it because it's not possible to have 150 simultaneous connections with db/table imports
 
Last edited:
well, as I mentioned its default install so if the default install has the max_allowed_packet high, then thats just the way it gets installed.


>> MySQLTuner 1.7.21 - Major Hayden <[email protected]>
>> Bug reports, feature requests, and downloads at http://mysqltuner.pl/
>> Run with '--help' for additional options and output filtering

[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.7.31
[OK] Operating on 64-bit architecture

-------- Log file Recommendations ------------------------------------------------------------------
[OK] Log file /var/log/mysql.log exists
[--] Log file: /var/log/mysql.log(0B)
[--] Log file /var/log/mysql.log is empty. Assuming log-rotation. Use --server-log={file} for explicit file

-------- Storage Engine Statistics -----------------------------------------------------------------
[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MEMORY +MRG_MYISAM +MyISAM +PERFORMANCE_SCHEMA
[--] Data in MyISAM tables: 8.4M (Tables: 32)
[--] Data in InnoDB tables: 1.1G (Tables: 754)
[OK] Total fragmented tables: 0

-------- Analysis Performance Metrics --------------------------------------------------------------
[--] innodb_stats_on_metadata: OFF
[OK] No stat updates during querying INFORMATION_SCHEMA.

-------- Security Recommendations ------------------------------------------------------------------
[OK] There are no anonymous accounts for any database users
[OK] All database users have passwords assigned
[!!] There is no basic password file list!

-------- CVE Security Recommendations --------------------------------------------------------------
[--] Skipped due to --cvefile option undefined

-------- Performance Metrics -----------------------------------------------------------------------
[--] Up for: 1d 19h 40m 53s (1M q [8.398 qps], 70K conn, TX: 1G, RX: 652M)
[--] Reads / Writes: 83% / 17%
[--] Binary logging is disabled
[--] Physical Memory : 7.6G
[--] Max MySQL memory : 9.8G
[--] Other process memory: 0B
[--] Total buffers: 169.0M global + 65.1M per thread (151 max threads)
[--] P_S Max memory usage: 72B
[--] Galera GCache Max memory usage: 0B
[OK] Maximum reached memory usage: 2.6G (34.64% of installed RAM)
[!!] Maximum possible memory usage: 9.8G (127.90% of installed RAM)
[!!] Overall possible memory usage with other process exceeded memory
[OK] Slow queries: 0% (0/1M)
[OK] Highest usage of available connections: 25% (39/151)
[OK] Aborted connections: 0.03% (18/70647)
[!!] name resolution is active : a reverse name resolution is made for each new connection and can reduce performance
[OK] Query cache is disabled by default due to mutex contention on multiprocessor machines.
[OK] Sorts requiring temporary tables: 0% (67 temp sorts / 37K sorts)
[!!] Joins performed without indexes: 1328
[OK] Temporary tables created on disk: 6% (3K on disk / 49K total)
[OK] Thread cache hit rate: 99% (402 created / 70K connections)
[!!] Table cache hit rate: 5% (1K open / 34K opened)
[OK] table_definition_cache(1400) is upper than number of tables(1065)
[OK] Open file limit used: 0% (38/655K)
[OK] Table locks acquired immediately: 100% (4K immediate / 4K locks)

-------- Performance schema ------------------------------------------------------------------------
[--] Memory used by P_S: 72B
[--] Sys schema is installed.

-------- ThreadPool Metrics ------------------------------------------------------------------------
[--] ThreadPool stat is disabled.

-------- MyISAM Metrics ----------------------------------------------------------------------------
[!!] Key buffer used: 18.3% (1M used / 8M cache)
[OK] Key buffer size / total MyISAM indexes: 8.0M/4.5M
[OK] Read Key buffer hit rate: 100.0% (750K cached / 45 reads)
[!!] Write Key buffer hit rate: 0.9% (271K cached / 2K writes)

-------- InnoDB Metrics ----------------------------------------------------------------------------
[--] InnoDB is enabled.
[--] InnoDB Thread Concurrency: 0
[OK] InnoDB File per table is activated
[!!] InnoDB buffer pool / data size: 128.0M/1.1G
[!!] Ratio InnoDB log file size / InnoDB Buffer pool size (75 %): 48.0M * 2/128.0M should be equal to 25%
[OK] InnoDB buffer pool instances: 1
[--] Number of InnoDB Buffer Pool Chunk : 1 for 1 Buffer Pool Instance(s)
[OK] Innodb_buffer_pool_size aligned with Innodb_buffer_pool_chunk_size & Innodb_buffer_pool_instances
[OK] InnoDB Read buffer efficiency: 99.97% (454087559 hits/ 454204721 total)
[OK] InnoDB Write log efficiency: 95.61% (3931059 hits/ 4111544 total)
[OK] InnoDB log waits: 0.00% (0 waits / 180485 writes)

-------- Aria Metrics ------------------------------------------------------------------------------
[--] Aria Storage Engine not available.

-------- TokuDB Metrics ----------------------------------------------------------------------------
[--] TokuDB is disabled.

-------- XtraDB Metrics ----------------------------------------------------------------------------
[--] XtraDB is disabled.

-------- Galera Metrics ----------------------------------------------------------------------------
[--] Galera is disabled.

-------- Replication Metrics -----------------------------------------------------------------------
[--] Galera Synchronous replication: NO
[--] No replication slave(s) for this server.
[--] Binlog format: ROW
[--] XA support enabled: ON
[--] Semi synchronous replication Master: Not Activated
[--] Semi synchronous replication Slave: Not Activated
[--] This is a standalone server

-------- Recommendations ---------------------------------------------------------------------------
General recommendations:
Reduce your overall MySQL memory footprint for system stability
Dedicate this server to your database for highest performance.
Configure your accounts with ip or subnets only, then update your configuration with skip-name-resolve=1
We will suggest raising the 'join_buffer_size' until JOINs not using indexes are found.
See https://dev.mysql.com/doc/internals/en/join-buffer-size.html
(specially the conclusions at the bottom of the page).
Increase table_open_cache gradually to avoid file descriptor limits
Read this before increasing table_open_cache over 64: https://bit.ly/2Fulv7r
Read this before increasing for MariaDB https://mariadb.com/kb/en/library/optimizing-table_open_cache/
This is MyISAM only table_cache scalability problem, InnoDB not affected.
See more details here: https://bugs.mysql.com/bug.php?id=49177
This bug already fixed in MySQL 5.7.9 and newer MySQL versions.
Beware that open_files_limit (655350) variable
should be greater than table_open_cache (2000)
Before changing innodb_log_file_size and/or innodb_log_files_in_group read this: https://bit.ly/2TcGgtU
Variables to adjust:
*** MySQL's maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***
join_buffer_size (> 256.0K, or always use indexes with JOINs)
table_open_cache (> 2000)
innodb_buffer_pool_size (>= 1.1G) if possible.
innodb_log_file_size should be (=16M) if possible, so InnoDB total log files size equals to 25% of buffer pool size.
Click to expand...
 
all ok with mysql, you can try increase innodb_buffer_pool_size=512M or up to innodb_buffer_pool_size=1G
you can set skip-name-resolve=1 - if you don't use domain names as host in db-connection settings.
all this can be set in /etc/my.cnf
Also check your CPU speed on both Vps
cat /proc/cpuinfo
 
[root@###### ~]# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 23
model : 49
model name : AMD EPYC 7302 16-Core Processor
stepping : 0
microcode : 0x1000065
cpu MHz : 2999.998
cache size : 512 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 16
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm art rep_good nopl extd_apicid eagerfpu pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext perfctr_core retpoline_amd ssbd ibrs ibpb vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 arat npt nrip_save spec_ctrl arch_capabilities
bogomips : 5999.99
TLB size : 3072 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : AuthenticAMD
cpu family : 23
model : 49
model name : AMD EPYC 7302 16-Core Processor
stepping : 0
microcode : 0x1000065
cpu MHz : 2999.998
cache size : 512 KB
physical id : 1
siblings : 1
core id : 0
cpu cores : 1
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 16
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm art rep_good nopl extd_apicid eagerfpu pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext perfctr_core retpoline_amd ssbd ibrs ibpb vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 arat npt nrip_save spec_ctrl arch_capabilities
bogomips : 5999.99
TLB size : 3072 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:

processor : 2
vendor_id : AuthenticAMD
cpu family : 23
model : 49
model name : AMD EPYC 7302 16-Core Processor
stepping : 0
microcode : 0x1000065
cpu MHz : 2999.998
cache size : 512 KB
physical id : 2
siblings : 1
core id : 0
cpu cores : 1
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 16
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm art rep_good nopl extd_apicid eagerfpu pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext perfctr_core retpoline_amd ssbd ibrs ibpb vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 arat npt nrip_save spec_ctrl arch_capabilities
bogomips : 5999.99
TLB size : 3072 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:

processor : 3
vendor_id : AuthenticAMD
cpu family : 23
model : 49
model name : AMD EPYC 7302 16-Core Processor
stepping : 0
microcode : 0x1000065
cpu MHz : 2999.998
cache size : 512 KB
physical id : 3
siblings : 1
core id : 0
cpu cores : 1
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 16
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm art rep_good nopl extd_apicid eagerfpu pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext perfctr_core retpoline_amd ssbd ibrs ibpb vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 arat npt nrip_save spec_ctrl arch_capabilities
bogomips : 5999.99
TLB size : 3072 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
Click to expand...

Here is the CPU info. Its a VPS with 4 cores
 
I dont agree that it is cloudlinux. I have lifted ALL limits from cloudlinux entirely.
 
bluesteam said:
I dont agree that it is cloudlinux. I have lifted ALL limits from cloudlinux entirely.
Click to expand...
Hi there, could you share the investigation results? Have you solved the issue?
I'm also considering now moving to the new server and would be appreciate to get the result shared.
 
If you use all features from CloudLinux with there PHP selector as well, your server will be for sure slower then only with DirectAdmin running on it.,
 
You must log in or register to reply here.
Back
Top