Web Hosting: VPS vs Shared

Everyone prefers a fast website. Even a few extra seconds spent loading each page can be a drag on your visitors attention. While there are a lot of factors that determine a website’s loading speed I recently ran a test of different web hosting environments on my own site.

The defacto hosting standard for many WordPress sites is a cPanel account on shared web hosting. This setup is ubiquitous and easy to manage. One alternative is a Virtual Private Server (VPS) with SSD storage. The trade off is that a VPS requires more knowledge to setup and manage, but the performance can be a big step up.

I ran a test, running this WordPress 4.0 website on reasonable (i.e. not bottom dollar) shared hosting account and a Vultr VPS with 768mb RAM and SSD storage and monitored response times.

Website Details

basic WordPress 4.0 site, without page caching. The VPS was running Apache 2.4 and the shared hosting on Litespeed HTTP.

Results

(Lower is better. Both servers are in Sydney and response time measured from the US)

VPS vs Shared hosting response

  • Shared Hosting: averaged 1583 ms with the slowest measured peak at 4602 ms
  • VPS SSD Hosting: averaged 448 ms with a slow peak of only 656 ms

The result was noticeably snappier pages on the VPS. The other take away is the consistency. On a shared server your response times can vary depending on what other sites on the server are doing. The VPS which has isolated resources gave far more consistent performance.

 

Detecting Environment in Laravel 4

Update: How to Get Environment in Laravel 5

Your PHP application should have different settings for its development and production environments. Here’s how you can set your Laravel 4 app to detect the environment, load the appropriate settings and keep installation-specific things like database credentials out of your Git repo.

Detecting The Environment

Laravel lets you provide arrays of hostnames it will check the server against to determine the environment.

Open bootstrap/start.php

$env = $app->detectEnvironment([
   'local' => ['MyMachineName', 'AnotherDevMachine'],
   'staging' => ['StagingEnvName']
]);

If unsure, use PHP’s gethostname() function to find your machine names.
This is the value to use inside the local/staging arrays

Laravel will default to ‘production’ if no other environment is matched.

 

Setting Environment Config Values

Laravel looks for .env.*.php files in the root directory (beside your composer.json and .gitignore files).

You will want to exclude these files from your Git repo. Add the following lines to your .gitignore

.env.*.php
.env.php

Then create an env file for each of your environments. Use .env.php for the production environment.
They should look something like this:

<?php

/**
 * Local Development
 */
 return array(
	'app.env'		=> 'dev',
	'app.debug'		=> true,
	'app.url'		=> 'http://example.dev',

	'mysql.host'	 => '127.0.0.1',
	'mysql.database' => 'bestDbEva',
	'mysql.username' => 'me',
	'mysql.password' => 'myTremendousPassword'

 );

The actual values are up to you. You can store whatever values you need within the application.

Using The Environment Values

Laravel config can now call getenv() to get the dynamic environment variable. For your DB config open app/config/database.php

'mysql' => array(
	'driver'    => 'mysql',
	'host'      => getenv('mysql.host'),
	'database'  => getenv('mysql.database'),
	'username'  => getenv('mysql.username'),
	'password'  => getenv('mysql.password'),
	'charset'   => 'utf8',
	'collation' => 'utf8_unicode_ci',
	'prefix'    => '',
),