Share

Question

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…

Answer 1

jarland August 13, 2018

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

Report

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?
Report
- jarland August 13, 2018
  
  You’re thinking on the right path there but I’d change that process just a bit:
  
  Create new server (by snapshot or for a fresh deployment)
  
  Change DNS to new IP
  
  Wait 48h before shutting down the old server.
  
  If the app has live data that changes constantly and the old server receiving new data would break something, my #3 there changes to:
  
  Forward traffic from the old server to the new one for 48h, using a reverse proxy:
  https://www.digitalocean.com/community/tutorials/how-to-configure-nginx-as-a-web-server-and-reverse-proxy-for-apache-on-one-ubuntu-18-04-server (Many other guides around for versions/distros, I just grabbed one as a sample).
  
  Jarland
  
  How To Configure Nginx as a Web Server and Reverse Proxy for Apache on One Ubuntu 18.04 Server
  by Jesin A
  In this tutorial you'll configure Nginx as both a web server and as a reverse proxy for Apache to host four domains on a single server.
  
  Report

Answer 2

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?
Report
- jarland August 13, 2018
  
  You’re thinking on the right path there but I’d change that process just a bit:
  
  Create new server (by snapshot or for a fresh deployment)
  
  Change DNS to new IP
  
  Wait 48h before shutting down the old server.
  
  If the app has live data that changes constantly and the old server receiving new data would break something, my #3 there changes to:
  
  Forward traffic from the old server to the new one for 48h, using a reverse proxy:
  https://www.digitalocean.com/community/tutorials/how-to-configure-nginx-as-a-web-server-and-reverse-proxy-for-apache-on-one-ubuntu-18-04-server (Many other guides around for versions/distros, I just grabbed one as a sample).
  
  Jarland
  
  How To Configure Nginx as a Web Server and Reverse Proxy for Apache on One Ubuntu 18.04 Server
  by Jesin A
  In this tutorial you'll configure Nginx as both a web server and as a reverse proxy for Apache to host four domains on a single server.
  
  Report

Answer 3

KeitelDOG August 13, 2018

[deleted]

Report

Answer 4

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.

Report

Answer 5

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.

Report

Answer 6

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!

Report

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

Leave a Comment

Share

Share your Question

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

Leave a Comment

Related

question

Block all traffic from country's whit CSF

question

Image optimization, recomendations

question

Nginx Configuration. How to simulate Wordpress subdirectory?

question

How to integrate Hubot with Rocket.Chat

Almost there!