LAMP server optimization (caching, OPCache, MySQL DB) for Wordpress / Buddypress network
Budget: €36 – €0 EUR
LAMP server optimization (caching, OPCache, MySQL DB) for Wordpress / Buddypress network
At peak times there are up to 150 members online at the same time.
This platform is based on Wordpress and a Buddyboss / Buddypress attachment. The site is internationalized using WPML and offers the possibility of paid memberships using PMPro and various complementary addons.
GOAL of the assignment is to analyze possible optimization potentials. First and foremost the use of the server possibilities, i.e. analysis of possible bottleneck(s) and tweaking of the corresponding available server parameters for php.ini, MySQL server, Apache etc., so that an optimal use of the possibly still free resources can be achieved.
Since the site is highly dynamic (activity feed, comments, groups and forums, messaging between members), complete caching is difficult to implement.
We have already exhausted some possibilities for optimization:
* Caching of some repetitive and "expensive" (i.e. slow) queries using static variables and using Wordpress transients.
* Caching of various HTML widgets that don't need to update themselves all the time
* Deletion of outdated transients, purging and cleaning of old DB entries and logs
* Rewriting of plugins to avoid SQL queries within for loops, for example
* Memcached and OPCache PHP Extensions were installed
* Update to PHP 8 because of JIT still in consideration
* Wordpress Plugin: Query Monitor -> analysis of results
The site is still extremely slow.
It is currently unknown what the bottleneck is, is it PHP or MySQL. In Linux "htop" both are alternating top loaders.
We have ~50GB of RAM, of which only 5GB is in use. Unfortunately the server does NOT have Plesk or the like, only a proprietary interface with the following options:
PHP FPM / CLI:
* implicit_flush
* max_execution_time
* memory_limit
* output_buffering
* output_buffering_value
* realpath_cache_size
* realpath_cache_ttl
* session_gc_maxlifetime
MySQL:
* default_charset
* ft_min_word_len
* innodb_buffer_pool_size
* innodb_ft_min_token_size
* innodb_flush_log_at_trx_commit
* innodb_lock_wait_timeout
* innodb_log_file_size
* max_allowed_packet
* max_connections
* max_heap_table_size
* max_user_connections
* query_cache_enabled
* query_cache_size
PHP OPCache:
* max_accelerated_files
* memory_consumption
* interned_strings_buffer
* validate_timestamps
* revalidate_freq
* enable_cli
* save_comments
* revalidate_path
* validate_root
* consistency_checks
If the analysis results are code optimizations, these may need to be implemented in consultation and depending on the effort involved.
At peak times there are up to 150 members online at the same time.
This platform is based on Wordpress and a Buddyboss / Buddypress attachment. The site is internationalized using WPML and offers the possibility of paid memberships using PMPro and various complementary addons.
GOAL of the assignment is to analyze possible optimization potentials. First and foremost the use of the server possibilities, i.e. analysis of possible bottleneck(s) and tweaking of the corresponding available server parameters for php.ini, MySQL server, Apache etc., so that an optimal use of the possibly still free resources can be achieved.
Since the site is highly dynamic (activity feed, comments, groups and forums, messaging between members), complete caching is difficult to implement.
We have already exhausted some possibilities for optimization:
* Caching of some repetitive and "expensive" (i.e. slow) queries using static variables and using Wordpress transients.
* Caching of various HTML widgets that don't need to update themselves all the time
* Deletion of outdated transients, purging and cleaning of old DB entries and logs
* Rewriting of plugins to avoid SQL queries within for loops, for example
* Memcached and OPCache PHP Extensions were installed
* Update to PHP 8 because of JIT still in consideration
* Wordpress Plugin: Query Monitor -> analysis of results
The site is still extremely slow.
It is currently unknown what the bottleneck is, is it PHP or MySQL. In Linux "htop" both are alternating top loaders.
We have ~50GB of RAM, of which only 5GB is in use. Unfortunately the server does NOT have Plesk or the like, only a proprietary interface with the following options:
PHP FPM / CLI:
* implicit_flush
* max_execution_time
* memory_limit
* output_buffering
* output_buffering_value
* realpath_cache_size
* realpath_cache_ttl
* session_gc_maxlifetime
MySQL:
* default_charset
* ft_min_word_len
* innodb_buffer_pool_size
* innodb_ft_min_token_size
* innodb_flush_log_at_trx_commit
* innodb_lock_wait_timeout
* innodb_log_file_size
* max_allowed_packet
* max_connections
* max_heap_table_size
* max_user_connections
* query_cache_enabled
* query_cache_size
PHP OPCache:
* max_accelerated_files
* memory_consumption
* interned_strings_buffer
* validate_timestamps
* revalidate_freq
* enable_cli
* save_comments
* revalidate_path
* validate_root
* consistency_checks
If the analysis results are code optimizations, these may need to be implemented in consultation and depending on the effort involved.