• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Issue Moved from AWS t1.small to m5a.xlarge , Wordpress poor performances

benacler

New Pleskian
Hi there,

I moved a wordpress site from an AWS t1.small to a dedicated plesk setup on a m5a.xlarge.. I was not expecting to have an huge boost on the site, but the performance of the wordpress website has dropped down to a level that I had to run in under a dedicated php-fpm pool (just to optimize it a little).

So considering that the site has no problems, because it was blazing speed on the t1.small instance, where's the bottleneck ? Plesk has no memory/cpu/other stuff issues and I cannot find a real bootleneck using profilers and other stuff.

Any hint ?
 
Hi,
Did you config mysql?
Try mysqltuner script, it does a great job to start a proper db setup.
Google to find where to download it and remember It has to be installed and run through ssh.

Regards,
 
I know it, nope the old server got an "untuned" mysql installation and a legacy php-fpm configuration on apache. I've also set the new one to a dedicated php-fpm , but we have a TTFB different from 0.4 (old server) to 2.0 (new server). I'm going mad, this has no sense.
 
Mmmm why don't you try changing to a different kind of instance and then go back to m5a.xlarge?
Last year I had some predifined days every 2 months when we knew traffic/ load would make us crawl, so we stopped the instance, changed to a much bigger resources instance and started again. The whole stop, change and start took 4 minutes and when the demand was over, we switched back to the original instance keeping costs under control.
In your case, the instance you got assigned has some kind of problem and switching it off and on may solve the issue.
Hope it helps.
Regards
 
hello @benacler ,

I guess you can try to install Plesk extension called Monitoring (+Grafana extension)
it will help to highlight the bottle necks.

if you sure that there's no problems with RAM and CPU I suggest to check disk load.

and the point about tuning Mysql/MariaDB also valid.
At least you can read about
- innodb_buffer_pool_size (and a little increase it).
- innodb_flush_log_at_trx_commit (and probably value=2 will handle your needs)

but you MUST understand what are you doing and to what results it can lead to.
 
Well I know quite well the Mysql optimizations, I run the perl optimizer and increased some buffers/values, but that had no effects.
Also by calling the same page /wp-login in a row should now affect the disk load in any case, I mean, we are talking about a 0% cpu server that respond in 2 seconds to a /wp-login request.... at this point, is that possible that the instance itself has problems ? I already restarted it with no success by scaling to an xlarge (it was large before), indeed I have almost always 8GB free RAM....so what else to try ? Should I move it completely to a new instance ? IS it enough by attaching by storage, or I should make a clean install ? thanks !
 
Additional notes: I detached the volumes and moved from a m5a.xlarge to a t3.xlarge.... things gone worst. JUmped from 1.8-2.0 to 3.0 secs response times. what the hell is going on there on aws ?
 
@benacler ,

it is too hard to find root cause by photo )

as I recommended before, you may install free extension monitoring, collect data for some time and analyze them.

you should compare your AWS instance types and decide what you need:
t3.xlarge limited by CPU per hour. they are recommended for general usage.
m5a.xlarge should use fast ssd disks, so operations that depends from disk should goes faster.

as an example you can try m4.large instance type. It should cover applications that utilize not only RAM+CPU but also disk (like databases)

another way - tuning your mysql server and application so they will be able to work faster without huge resources utilization

I can suggest you to contact Plesk Technical support.
Without access to the server it is hard to say what is the exact reason, only general recommendations..

In general, i don't think that you need to re-deploy Plesk instance.
But you need to do deep investigation to find root cause (bottle neck), and choose appropriate instance type based on this information.
 
Well I just discovered that the machines are running a different version of Mariadb (5.5 against 10.5), I measured disk performances and are better on my new instance, I've run a couple of mysql testing tools and also performances are better, but I had to think that 5.5 against 10.5 have different performances related to wordpress.... I'm out of idea, will get in contact with technical support.
 
omg. I was sure that you just have changed instance type without changes of installed software.
MariaDB 5.5 is out of date, so it is better to use 10.5 (or at least 10.3).
And of course performance comparison should be done with identical software configuration.

Otherwise it is much larger task: to find ideal architecture and software components for your needs ))
 
Back
Top