the initial load of several sites that are on CMS are very slow (Debian Jessie) ISPConfig 3.1.2 static pages are fast but CMS sites using mysql / mariadb are pretty bad slow..
wondering if these settings will help or not https://www.howtoforge.com/communit...other-apps-wp-front-end-ok.55383/#post-272494 really old threads but similar sounding issues.
Your php version also play its parts. Php 7 and above for example is much more faster than any php 5.
good call was running default 5.6 5.6.30-0+deb8u1 just was set to fast-cgi vs fpm - fpm for some reason fails to work - something with php messed up on my 7.x installs and paths somewhere. Currently set to 7.1.0 FastCGI and testing again.. that the backend of joomla site works fine - but front end gets: Error displaying the error page: Error decoding JSON data: Control character error, possibly incorrectly encoded: Error decoding JSON data: Control character error, possibly incorrectly encoded setting to 7.1.0 FPM same issue - which is with the sites not the php - but also very possibly a bug in php 7.1.0 since its now up to 7.1.4 and updating is a little more of a hassle since there ins't an auto script - which would be nice!
Now set at 7.0.11 fpm and still pretty slow only on CMS pages, but updated both themes to their current versions and all other parts but only below really seemed to help. Error in particular was due to theme issue I found https://goo.gl/DUqI0F however Wordpress didn't have an issue but is now also working much better... odd... maybe just needed a kick in the right direction! ---- still initial load is pretty slow but that might be the VM - I'll see if I need to add more resources but odd its got way more power than another host I'm using with a different hosting engine and its much faster... interesting...
Viper, Have you optimized your database server? usually poor CPU performance and slow loading CMS sites are due to default or bad sql database configs. If you're on mysql, can you check you /etc/mysql/my.conf and see what you have for settings? The defaults are garbage, so if you've never tweaked these you should as you'll need to add some optimizing variables. Here are some you may want to consider: [mysqld] key_buffer = 512M innodb_buffer_pool_size = 2048M innodb_log_file_size = 256M tmp_table_size = 128M max_heap_table_size = 128M query_cache_limit = 2M query_cache_size = 128M The key_buffer helps my MyISAM tables. For InnoDB tables the best optimizer is changing you buffer_pool_size and log_file_size. These will give your database enough RAM to complete tasks more quickly. These numbers are for a 12GB Linode, for a smaller VPS you'll need to adjust accordingly... You need to keep in mind that you need to leave ram available for other processes besides just the database, though if you use a lot of CMS's on your server this will be hugely important to optimize. For log_file_size you want to keep this at 25% the size of the buffer_pool_size for optimal performance. You should google "sqltuner howtoforge" and run that in SSH to get some more pointers about optimizing your database server. It's also important to note that to add more resources to the log_file_size you cannot *just* update the my.conf, you need to actually follow a procedure to insure no data loss/corruption: 1. # service mysql stop 2. Move ib_lofile0 and ib_logfile1 from /var/lib/mysql to a temp folder like /var/lib/mysql/temp (just in case things go bad and you need to reset). 3. Upload your new my.conf with new innodb_log_file_size settings to /etc/mysql/ 4. # service mysql start 5. mysql should regenerate your ib_logfile's with the new proper sizes, as long as there are no errors from starting mysql you should be good to go with the new optimized log_file_size. As a rule of thumb, you can figure out how much ram should be allocated to your database by taking your total amount of ram, subtracting whatever you need for your system to run, then plopping 80% of whatever is left into your database settings... I actually like to leave a bunch of extra ram available for other things, but with 12GB of ram I don't really need to give all the spare ram to the DB lol... On some of my smaller servers the settings get real tight, but still a lot better than default settings - you'll experience huge gains in frontend speed. There are also a lot of other things you can do to tweak your database, but those few things I gave you should fix your immediate problem and get you on the right track. Your next step should be to optimize your php settings - if you go with php-fpm you'll want to attack each site's settings from ispc>websites>settings/options, or go to their pool directory to edit each. If you use FastCGI then you can also edit the settings in ispc>system>server config>fastcgi and change children to 1, and max requests to 500, then finish by editing the php.ini in the main config folder for fastcgi Hope some of that helps you get going!
HUGE thx @Thane! will post what my results after tuning per your information that is most likely exactly what the issue is I'm dealing with.. part of it is also php-fpm not working due to php addons not working correctly in fpm mode sites load with error php5-fcgi/index.php not found or something like that - have seen a thread to resolve with options but think i"m not savvy enough to know exactly what to paste where!
Hey Viper, You're welcome! Looking forward to seeing what tuning your sql does What size server are you running? What kind of addons did you put on php-fpm? Sometimes I've done some custom work on servers and had problems with php, switching from fpm to fastcgi will sometimes work, I guess fpm just doesn't play well with some things - same with fastcgi, I usually like fpm because it uses less ram - but I've had websites where fpm KILLED my cpu usage and switched back to fastcgi... I haven't experimented much with the other php engines. I don't know about the error with php5/index.php... I think maybe you have some plugins in your cms that aren't php 7.1.x compatible? I tried php 7.1 once, it gave me lots of problems and white screens of death on lots of sites, recently I tried php 7.0.x and those same sites run great on it. For stability and compatibility I try to keep production sites on php 5.6.x - maybe in a year or two "everything" will be compatible with php 7, though I'm not so sure about 7.1 - I read about the differences between 7.0 and 7.1 and the consensus seemed to be that they were so completely different that big problems were almost guaranteed if you weren't 100% compatible. Maybe if I ran simpler sites or built custom sites it would be easy to work with the absolute latest php version - but I pretty much stick to cms's so I can get sites built faster, most of my clients want a certain cms because that's what their 'friend' told them to get, or they just have really small budgets - so cms helps keep me in line with little budgets Really though, the speed gains I got on php7.0 sites versus php5.6 wasn't super huge, some sites would load in 4 seconds on 5.6 and run in 2 seconds on 7.0 - both times are great and acceptable, just 5.6 offers more compatibility where 7.0 offered better speed/efficiency... In the end compatibility means more to me than speed, because sometimes customers want things added to their site - being compatible makes that easier... So I mostly stick with 5.6... Unless it is a business website - like just 4-5 pages of static content (home, about us, services page, contact page, etc) - in that case I feel safe using php7.0 to get the efficiency boost just because I know there is going to be little to add/change if anything... Ecommerce clients though - 5.6 all day long. Good luck man!
mariadb currently installed. [!!] Currently running unsupported MySQL version 10.0.30-MariaDB-0+deb8u1 [!!] Aborted connections: 9.79% (4628/47274) [!!] name resolution is active : a reverse name resolution is made for each new connection and can reduce performance [!!] Query cache may be disabled by default due to mutex contention. [!!] Query cache efficiency: 15.6% (136K cached / 870K selects) [!!] Key buffer used: 18.3% (3M used / 16M cache) [OK] Key buffer size / total MyISAM indexes: 16.0M/2.8M [OK] Read Key buffer hit rate: 99.0% (1M cached / 15K reads) [!!] Write Key buffer hit rate: 66.7% (472K cached / 315K writes) [!!] Ratio InnoDB log file size / InnoDB Buffer pool size (75 %): 48.0M * 2/128.0M should be equal 25% [!!] InnoDB buffer pool <= 1G and Innodb_buffer_pool_instances(!=1). [--] InnoDB Buffer Pool Chunk Size not used or defined in your version [OK] InnoDB Read buffer efficiency: 99.99% (28929328 hits/ 28931616 total) [!!] InnoDB Write Log efficiency: 72.91% (5177 hits/ 7101 total) [!!] Aria pagecache hit rate: 92.9% (1K cached / 81 reads) General recommendations: Reduce or eliminate unclosed connections and network issues Configure your accounts with ip or subnets only, then update your configuration with skip-name-resolve=1 Increase table_open_cache gradually to avoid file descriptor limits Read this before increasing table_open_cache over 64: bit.ly/1mi7c4C Beware that open_files_limit (1024) variable should be greater than table_open_cache (400) Performance should be activated for better diagnostics Consider installing Sys schema from github.com/mysql/mysql-sys Variables to adjust: query_cache_size (=0) query_cache_type (=0) query_cache_limit (> 1M, or use smaller result sets) table_open_cache (> 400) performance_schema = ON enable PFS innodb_log_file_size * innodb_log_files_in_group should be equals to 1/4 of buffer pool size (=64M) if possible. innodb_buffer_pool_instances (=1) --- Ran through this: tecmint.com/mysql-mariadb-performance-tuning-and-optimization/ still not much better.. currently its a VM with 4 CPU and 3gb ram max available to to the VM. just running about 5-10 websites that are mostly joomla/wordpress all current (3.6.x- not 3.7 yet) static sites that are just html are fine and once the initial first load goes - the subsequent page loads even on new pages is fine. /php5-fcgi/index.php - php-fpm-redirect-errors.65160 sorry account to new to post links. is a subdomain that is loading - only errors in 7.1 - set to 7.0.x seems to resolve also setting to fast-cgi 7.1.x seems to resolve as well. FPM-7.1 seems to be where the issue occurs. being that it is a subdomain and a redirect both - causes the issue for FPM...
