Why is my new scaled droplet (8GB RAM - 4 vCPUs) is 4 times slower than the old one?

August 13, 2018 3.4k views
Apache PHP PHP Frameworks MySQL Ubuntu
KeitelDOG
By:
KeitelDOG

Last Friday, August 11th 2018, I scaled my VPS for my website. As I started to receive more and more requests for LRC Maker and Downloads (Lyrics files), my CPU crossed 100% multiple times, and was averaging 80%.

The Apache server in the old VPS 4GB RAM and 2vCPUs used to load the Main Page in 200-250ms, now the new one with 8GB RAM and 4cCPUs is loading it in 900-1200ms. Just some minutes before the scale, the speed was still excellent. Now all the pages are taking 4x more times than before, I even started to loose some pageviews that kept until then increasing fastly.

I just try to update /etc/resolv.conf, without rebooting, but with no success. What could be behind such a slow performance?

Ubuntu 14.04,
Apache 2.4,
PHP 5.6,
MySQL 5.5.9,
Laravel 5.0,
Same Codes as before...

Log In to Comment
5 Answers
jarland MOD August 13, 2018
Accepted Answer

Hello friend!

Sorry to hear about the trouble this is giving you. The source of the slowdown could be anywhere, and finding it is not always an easy task. It could be anything from a package upgrade going live after the reboot that came along with the resize, to a problem with our hypervisor. To rule out external factors, I've given you some credit to cover the cost of creating a snapshot and spinning up a new droplet. This will help you to determine whether the problem is most likely inside of your operating system or outside of your droplet.

If it is determined to be external, open a ticket with our support team and let us get that documented on your account as we work through it (I saw no clear evidence that it is, but that is not always conclusive). If it is determined to be internal, you're going to need to troubleshoot every layer of your software stack until you find where it is slowing down. That may require watching MySQL queries, running strace on a PHP process, and perhaps even simple use of things like gtmetrix.com.

Kind Regards,
Jarland

Reply
  • KeitelDOG August 13, 2018

    Thanks for your quick reply!

    I don't think the slowdown is in the Laravel Layer App, as it still performing at the same speed that is was on Staging an on Development. Even my Macbook Pro now responses the main page more faster than the production VPS (Mac - 500ms VS 950ms - Production). There hasn't been any code update except that global warning on all pages with message to tell users we would be down for maintenance, and that warning message has been removed after scale.

    Anyway thanks for the Snapshot tip, and this week I will either go with the snapshot approach, or an automatic bash script deployment that recreate the website system on and other VPS. The second approach will give me the opportunity to upgrade safely MySQL to 5.6 or 5.7, but if my pageviews continue to decrease, then I'll proceed with the Snapshot.

    But just in case, I wanna be cleared on the process with Snapshot :

    Create a New VPS
    Shutdown Old VPS (currently online)
    Restore Old VPS Snapshot into New VPS
    WHAT ABOUT THE DNS - IP ? Change the DNS configuration of my Google Domain so it points to new VPS?

KeitelDOG August 13, 2018
[deleted]
Reply
KeitelDOG August 22, 2018

Yesterday August 21th, I have done the Proxy Server with my Staging Server, it's working great. And the new one is a bit faster.
Today I started to do it for production, power down the droplet at 2h46 PM, take the SNAPSHOT. Now it's 5h54 PM (3 hours +), and that SNAPSHOT is still creating. 80GB Hard Drive and about 50GB of Data inside.

I'm planning in the future to move the static audio files to an Object Storage.
I'd like to know if there is a problem with my SNAPSHOT so that I can cancel it and serve the website as it is for the moment.

Reply
KeitelDOG August 22, 2018

4 hours in 5 more minutes till a SNAPSHOT is creating. Now is there a way to cancel the SNAPSHOT process?

I will do a fresh VPS setup instead another day, backup the database and restore it in the new VPS, move the Static files to new VPS, and send request to it with Proxy Server.

Reply
KeitelDOG August 22, 2018

Everything is good now. That means the Physical Server or the Sub-Network hosting the scaled VPS was really slow, even when taking a snapshot!

Now my production server response very fast again.

Thanks!

Reply
Have another answer? Share your knowledge.

Related Questions