Simply Fast WordPress [12] - How fast is KUSANAGI, the "1000x speed" WordPress virtual machine?

This is a series of articles explaining how to speed up WordPress, the use of which is growing rapidly for CMS-based business sites and media sites. In his article, we will verify just how fast KUSANAGI is when operated on a public cloud.

Last time, we introduced seven merits of running a KUSANAGI, the WordPress 1000x speed-tuning virtual machine.
This time, we will launch KUSANAGI on a public cloud service, and verify its speed. We will use KUSANAGI for AWS (Amazon Web Services) and compare the results to the results from our speed-tuning efforts in articles 2-10.

Furthermore, as of August 2016, KUSANAGI can be used as a virtual machine by eleven different public cloud services (IaaS: Infrastructure as a Service). In this issue we will verify its speed by launching an instance on the AWS virtual cloud server "Amazon Elastic Compute Cloud" (below, Amazon EC2). For those using different cloud services, simply replace everything specific to AWS below with your cloud’s information.

couldservicecompanies
Public cloud services that can use KUSANAGI (as of 11/2016)

Launch KUSANAGI on AWS and install WordPress

Launch an instance on Amazon EC2. As we did in Vol. 2 "Speeding up WordPress 250% with PHP Accelerator APC", create a t2.medium instance on the US East (N. Virginina) region. Following the instructions from the link below, log in to the KUSANAGI virtual machine via SSH and switch to an admin user.

1. KUSANAGI for AWS

Choose the KUSANAGI for AWS machine image. KUSANAGI for AWS is in the "Amazon Machine Image (AMI)" section. An instance with at least 4gb of memory is recommended for actual use, but approximately 2gb will be sufficient for this test.

AWSinstall04-small
Choose the “KUSANAGI for AWS” Amazon Machine Image (AMI).
AWSinstall05-small
Create a t2.medium instance on the US East (N. Virginia) region.
This screen will be shown after successfully logging in to the virtual machine from the SSH terminal. After logging in, switch to an admin user with a "su –" command.
This screen will be shown after successfully logging in to the virtual machine from the SSH terminal. After logging in, switch to an admin user with a "su –" command.

From now on, we will assume that you can resolve your host name (public DNS) and that the virtual machine is externally accessible with your host name. Host name resolution with the client machine's hosts file is fine. We will use "ec2-xxx.xxx.compute.amazonaws.com" as a dummy host name in this post, which should be replaced appropriately.

Use the links below to do the initial setup and provisioning for KUSANAGI.

2. KUSANAGI Initialization
3. KUSANAGI Provisioning

Provisioning creates the necessary directories and arranges files for installing WordPress. For the hostname settings, input a hostname that can access the virtual machine, such as "ec2-xxx.xxx.compute.amazonaws.com". This test is not intended for public use, so you can skip the SSL and Let's Encrypt settings. Press the enter key twice on the Let's Encrypt settings screen to skip it.

Install WordPress on Kusanagi using the link below for reference.

4. WordPress Installation

wordpress_install07
The top page that appears after installing WordPress

After the WordPress top page appears, return to the SSH console and use the kusanagi command to confirm the current status.

kusanagi status

The KUSANAGI command to confirm the current status

[root@ip-~]# kusanagi status                                                
Profile: primestrategyus.com
Type: WordPress
KUSANAGI Version 8.0.0-3
aws
*** nginx ***
● nginx.service - The NGINX HTTP and reverse proxy server
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2016-10-31 12:52:54 CDT; 43min ago
*** Apache2 ***
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
*** HHVM ***
● hhvm.service - HHVM virtual machine, runtime, and JIT for the PHP language
   Loaded: loaded (/etc/systemd/system/hhvm.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2016-10-31 12:18:11 CDT; 1h 18min ago
*** php-fpm ***
● php-fpm.service - The PHP FastCGI Process Manager
   Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
*** php7-fpm ***
● php7-fpm.service - The PHP FastCGI Process Manager
   Loaded: loaded (/usr/lib/systemd/system/php7-fpm.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
*** Cache Status ***
fcache off
bcache off
Done.

Information shown by the “kusanagi status” command
Lines 2-4 of the information displayed by the kusanagi status command show: "Currently selected profile", "KUSANAGI version", and "Cloud Service". In this example, you can see that the profile is set to kusanagi_html, the KUSANAGI version is 8.0.0-3 and the cloud service is AWS.

The profile was set when we did the WordPress provisioning. When using multiple virtual hosts, this shows which one is currently affected by the kusanagi command.

The web server and PHP processor are shown in the middle. In this example, the web server is Nginx, and the PHP processor is set to HHVM and shown as active and running.

After “Cache Status” toward the bottom is the status of KUSANAGI's two page-caching plugins. Here, we see that both Nginx FastCGI Cache (fcache) and the KUSANAGI plugin bcache are off.