nc -l -p 12345 < pipe | tee outgoing.log | nc server 12345 | tee pipe incoming.log

Now this may seem a little cryptic so I’m going to dissect each portion to explain how it works. Keep in mind the “pipe” references an actual pipe. You can make a FIFO pipe by running “mkfifo pipe” or “mknod pipe p” – the former is the most usual way. If you’re not familiar with named pipes I recommend reading up on them before continuing with this post as you may get a little confused.

nc -l -p 12345 < pipe

This portion simply has netcat listen on port 12345 and send anything from the pipe to the connected client. If you’re not familiar with the pipes think of it as a simple file with the word “hello” in it. When someone were to successfully connect to the netcat instance it would send the “hello” to the client.

| tee outgoing.log

If you’re not familiar with tee this may seem a bit obscure. Tee prints the things piped to it to stdout as well as writing it to a file. In this instance any traffic from the connected client will get printed to stdout and to the file “outgoing.log”. An example of how this would work is if I connected to the netcat instance and simply typed “hello” it would print it out to the screen and log it to the “outgoing.log” file.

| nc server 12345

This is the server that you would normally want to connect to. Remember the goal is to make a quick intercepting proxy to see how the client reacts to the server. This is the server.

| tee pipe incoming.log

Here is where the magic happens. This completes the relay so the client and server can communicate across the proxy. What this does is takes the network traffic from the server and using tee prints it to stdout while piping it to our “pipe” and “incoming.log” files respectively.

Now all of this may make sense individually, though how they work together might be slightly confusing.

If you recall the first command sends all data from our “pipe” to the client – and at the end we pipe all data from the server to the “pipe”. See now? We’re simply taking all data the server send and sending it to the client completing the relay and allowing for normal operation.

Now in this case I needed this for a quick look at how a normal IRC client interacts with the server since the RFC is lacking – so here is a real world example of where this was used (though there’s likely infinite better ways to do it):

nc -l -p 12345 < pipe | tee outgoing.log | nc irc.freenode.net 6667 | tee pipe incoming.log

You’ll notice when you execute the above command you’ll start seeing some traffic from the server instantly:

NOTICE AUTH :*** Looking up your hostname…
NOTICE AUTH :*** Checking ident
NOTICE AUTH :*** No identd (auth) response
NOTICE AUTH :*** Couldn’t look up your hostname

Now we connect to the netcat server – in this case localhost on port 12345 and if everything goes as planned it should connect like normal to Freenode. If you take a peak at the netcat server you’ll see a bunch of activity!

The cool part is the logs – we can see exactly how this particular IRC client (IRSSI) and server (Freenode) interact.

incoming.log
outgoing.log

Once again this isn’t the best way to do this – tcpdump, wireshark and infinite other choices are available. That being said it’s fun to fiddle and learn.

-Cody

I’m seeing more and more where wordpress themes are not using style.css or at least .css for their style sheets.  More and more they are using style.php which in turn simply outputs the style sheet.  This sort of setup suddenly requires an extra PHP process every page load thus increased memory as well to compensate.  The fact it’s just going to output CSS still does not matter it’s really bad to be doing.  This is especially bad when a wordpress blog is running say wp-super-cache they’re probably trying to serve everything via html files.  Well that purpose is defeated when every page load PHP is loading up to serve their style sheet.  Now as to why more themes are doing this I’m not sure maybe it’s make them look more professional in the eyes of the users I have no idea.

Of course if you see style sheets being displayed via php you also get the same thing with java script.  All the js files become js.php with simply the javascript being output in the php file.  There is no actual using of PHP logic besides the print “js stuff”

There is one other problem I see quite a bit and that’s extra features included in the theme.  For example we’ve had several users use themes with phpthumb included.  The theme was using it in several places to make smaller images of portions.  Along with that they also did not configure it properly and some bots found it and started using the install to generate thumbnails for other web sites.
That’s just a few examples but I would advise anyone when installing a wordpress theme take a look at what it offers and what it’s doing.  If it’s using php files everywhere you might want to see if it’s actually necessary.  If they include extra features or include third party scripts you might want to check if they even set it up properly.  I would not rely on the theme developers on these sort of things.  I’ve seen some free themes not even doing relative paths properly resulting in serving images and such via their own demo of their script.  So I really would not trust the theme maker has done a great job with the other aspects of the theme.

[an error occurred while processing this directive]

The user will see this error over and over again when adding the package.  There is also an error in the cPanel error_log which I cannot remember at this point as we had a machine give this error a while back.  The thing is we know what causes it now so I did not bother checking the error_log of cPanel.  So all you need to do is go into tweak settings and find the following setting:

The maximum memory a cPanel process can use before it is killed off (in megabytes). Values less than 256 megabytes can not be specified. A value of “0″ will disable the memory limits.

We typically set this value at 768-1024 MB on our higher end systems (12GB ram total).

Do not feel bad if you did not know as I honestly did not until I made a ticket with cPanel support.  Even then at the time they needed to login to figure out what was causing it.  It’s really not a well documented problem but it seems to be coming up more often now.  You probably see the same thing with other applications and even the languages themselves.  For example PHP the memory limit of 32MB is really problematic on 64bit systems which is why we use 128MB.

This is where WP-Super-Cache comes into play what it does is when pages are served the first time it checks the caches and if they do not exist it then creates the cached file and serves it.  It has two options using rewrite rules to send users to .html versions if they’re available or to have PHP still handle it but load the PHP files instead.  How the HTML version works is the rewrite rules it inserts into the .htaccess file checks for file existence in the cache folder and if it’s there that’s where the file is served out of.  This is the ideal situation as no PHP being loaded at all means a server can handle a lot of traffic meaning even being on the frontpage of digg may very well be handled fairly easily.  There are some cases where users forget this portion so we always make sure to remind users to get the rewrite rules in.  In a lot of cases their blog goes from using a lot of resources under traffic to being a user we have no idea we’re even hosting.

So how do you know if the cache is working?  Well on each page if you view the HTML source you’ll see something like this:

<!– Dynamic page generated in 0.277 seconds. –>
<!– Cached page generated by WP-Super-Cache on 2009-09-13 14:22:03 –>

You should also make sure the cache page generated time has not changed on a refresh of the page seconds later (tells you it’s broken).  So if I refresh the page again and I have made no changes to the blog I should see this again:

<!– Cached page generated by WP-Super-Cache on 2009-09-13 14:22:03 –>

This tells me the cache is working and the page was served via a html file.

I hope this convinces everyone who is not running WP-Super-Cache to install it now and configure it!  Especially if you’re hosting with us because eventually if your site becomes popular I’m sure you’ll hear from us about installing it to reduce your usage so that your site can scale up much better.

I plan on posting some more Wordpress related posts in the next few weeks regarding things I’ve noticed on blogs that decrease performance and increase resource usage.  Hopefully the tips help users who think they might not belong in a shared hosting environment to think otherwise after correcting these issues.

With the rise of spam and users no longer displaying their emails on sites the spam bots have become much smarter.  It’s no longer use email addresses found on web sites and only use them.  The spam bots now send mail to jimmy@domain.com, johnny@domain.com, susan@domain.com ect. ect.  As a result of this a simple spam email could become a mail bomb of thousands of emails hitting a single email account thus putting extreme strain on the server as well as quickly filling a users mail box.  So a lot of users stopped using this feature in favor of forwarders for the specific email accounts so it’s been less of a problem.  Of course some users still use this feature until they get hit by mail bomb and they end up switching out as it’s impossible to manage their own mail anymore.

Even with this no longer being a preferred feature of users we still run into problems with people having the default/catch all set to their accounts username.  We by default have this set to fail rather than catch the mail unfortunately by cPanel last I checked the default was catch-all.  The majority of web hosts do not do a great job with managing their servers so they have it set to catch all.  When we have to restore a users account from another server we inherit the ugly catch all that was setup.  So we get to deal with the spam and mail the user receives to any possible email address to their domain.

Now you might be saying well doesn’t spam help prevent all this mail?  It does but it cannot stop it all and it also slows down a server.  The mail portion on a server is one of the most intensive portions due to just the volume of mail coming in every day.  This is why a lot of providers have suggested to their users use services like google apps or have outside mail servers.  They are attempting to off load one of the most expensive things on their servers which is mail.  Now add in the fact the mail includes spam from every possible email address for a domain and it becomes much more of a problem.  So us using spam blocking techniques do not solve the issues they just help the user while we still need to process the mail going through our spam checker system then if the spam count is high enough getting thrown away.  Also spam blocking systems do not come near effective at blocking everything without blocking a lot of legitimate mail in the process.

All the CPU usage from the mail does not factor in the pure amount of mail you will receive when you have a default mail address set to say the username of your account.  We’ve had users move from another host and it’s enabled and they do not check the default email address.  A few years later and they’ve hit their quota as their default mail address is 2GB of mail or more.  So it can fill a users quota up pretty easily if left unchecked for a long time which is usually the case since the user is not aware it’s even enabled.

So the only solution here is to say no to the catch all email feature.  If you’ve never checked it out in cPanel I suggest visiting the “Default Address” feature in cPanel and making sure it is set to “Discard with error to sender (at SMTP time)”.  A lot of hosts do not have this set so if you came from another host it’s probably not set to fail on a non existent email address.

The first one is to modify the init.d script of Apache to reduce the stack size.  So for a cPanel system it’ll be located at /etc/init.d/httpd and you’ll want to add the following:

ulimit -s 256

This will make the stack size just 256KB which will suffice for most users.  I prefer to just do this with Apache but if you like you could modify this globally by changing /etc/security/limits.conf or for all services you could change /etc/init.d/rc .  I believe though the best action is to just change Apache until you run into an issue with another service having the same issue.  As you may not want just 256 but higher for a specific service or the defaults are fine in other cases and lower may reduce performance.

Well I hope that helps everyone out to get the performance of mpm_worker while not having to deal with the memory issues with regards to the default stack size.

VLAN Routed IP’s

VLAN routed IP’s most believe are only useful for virtual private servers where you can use IP pool features to spread a range across numerous servers.  This is untrue as we actually have every single IP routed to our VLAN’s to make it possible to share ranges among servers.  That’s actually easy to do you just need to use the right netmask on the IP’s so a 32 IP range is a 255.255.255.224 for example.  You can use the site http://grox.net/utils/whatmask/ to quickly calculate this for you if you’re unsure so say you were given 1.2.3.4/28 255.255.255.240.  So for each IP you add or a range you add specify the netmask as otherwise you can cause some very strange routing later on when re-routing IP’s.

So the second portion is I have 1.2.3.4 on Machine1 and I want to route it to Machine2 this is very easy to do.  You want to add 1.2.3.4 to Machine2 then arp the IP to the new server.  I prefer to remove it from the old server as well before doing the arp as I don’t want to cause any confusion but it may not be necessary I just prefer to be safe than sorry in case it causing routing issues of the range.  So to re-route the 1.2.3.4 with the gateway 4.3.2.1 you’d run the following command on Machine2 in SSH:

arping -A -s 1.2.3.4 -I eth1 4.3.2.1

Obviously you’d change 1.2.3.4 with your IP and 4.3.2.1 with the gateway of your VLAN.  In the SoftLayer panel you can find the gateway of your VLAN by going to any IP and looking for the server address and below that it lists the gateway of the VLAN.  It is also worth noting with this setup you lose the use of 3 IP’s so I recommend your minimum IP range is 32 IP’s and you also obviously need softlayers VLAN routed IP’s.  In the Softlayer IP manager it also tells you which IP’s are not usable so it’s pretty self explanatory there.

Private IP’s on VPS

We also give each VPS it’s own private IP so they have access to Softlayer tools such as the resolvers but we could expand this out to NAS, iSCSI ect.  There are several topics going around on how to do it in OpenVZ but we’ve found the easiest solution is just one command on the VPS and it does not even care where the private IP is on the VPS’s ip list.  The first thing to do this is you need VLAN routed private IP’s which you should have if you have a public IP set.  Add one private IP to the VPS which is it no in use then login to the VPS in question.  We’ll say the private ip is 10.10.10.10 in this case and we’ll need to run the following command:

ip r a 10.0.0.0/8 dev venet0 scope link src 10.10.10.10

Now you can ping 10.0.80.11 and you’ll notice it now responds to pings!  You can also receive 10.x.x.x traffic from any IP and also send it to any this includes VPS’s (might be useful to some).  Just so this is automatically ran you can add it to /etc/rc.local or someway so it automatically executes this.  There might be a way to do this without modifying the VPS it self but I have yet to find one so if anyone knows feel free to add a comment about it.

So I hope this helps some how or maybe if you have a better way of doing either of these feel free to post a comment.

In this post I’ll be using two different VPS accounts as an example since we will need to spread the load across something. I’ll be referencing them as VPS1 and VPS2. In the examples they will be running Ubuntu, though most of the tutorial can be applied to any distribution. One thing to note is I’ll be using Aptitude for package management which is fairly specific to Debian based distributions. Usually Yum will be your alternative – and in the worse case scenario you will have to compile the packages manually.

What is Perlbal?

Perlbal is a single-threaded event-based server supporting HTTP load balancing, web serving, and a mix of the two.

Perlbal is a software load balancer created by Danga Interactive for the use on LiveJournal, Typepad, and other ventures. It’s a lightweight reverse proxy that has the ability to serve as a web server, though that is out of the scope of this post.

What is a “reverse proxy”?

According to Wikipedia a reverse proxy is:

A reverse proxy or surrogate is a proxy server that is installed in a server network. Typically, reverse proxies are used in front of Web servers. All connections coming from the Internet addressed to one of the Web servers are routed through the proxy server, which may either deal with the request itself or pass the request wholly or partially to the main web servers.

I believe this description is very fitting – it’s essentially a “middle man” for a request (in this case HTTP request) that decides where it should be routed to. This could mean simply deciding to put it on VPS1, or VPS2 – or it could mean if the HTTP request is for an image we’ll send it to Lighty, and if it’s a normal request to a PHP page we’ll send it to Apache. Think of it as a “router” in the literal sense.

Why is it useful?

I’ll give two simple scenario’s to try and explain the useflness of reverse proxies:

Scenario 1

You’re serving 100 requests/second and are running out of memory on your server – you notice that a good 80% of the requests are simply for static files, such as images and stylesheets – unfortunately Apache still takes a large amount of memory / CPU for these requests causing you to exhaust your resources. One way you could reduce the usage is simply setting up an alternative web server such as Lighty that has a lighter footprint to serve your static files, and keep Apache for the requests serving your application.

Scenario 2

We’ll also use the example of serving 100 requests/second – but let’s just say your server simply can’t handle the traffic. You could setup another server identical to your current one, and have the reverse proxy listen for incoming requests and it will direct the traffic to both servers seemlessly – allowing you to split the resources across the board and maintaining a fast / stable website.

These examples may have some flaws, though they’re simply here to illustrate common uses / the benefits of using a reverse proxy (or software load balancer).

First things first

First you need to find where your bottleneck is in your application. Is it the web server or is it the database server? Could it simply be slow SQL queries that could be fixed by adding a index? Ultimately you want to make sure that your application is optimized as much as possible – and make sure the bottleneck can’t simply be fixed by a few tweaks.

How do I setup the environment described in Scenario 1?

In this setup we’re going to use Apache to serve all HTTP requests relating to PHP – or your application, and use Lighty to serve static files such as images. The goal here is to use Lighty because of its low footprint to serve static files such as images and to lower the overall usage of your server.

1) Getting the packages

You will need the following packages:

• Apache  (setup for PHP)
• Lighttpd
• Perlbal

In Ubuntu each of these should be in the repositories, so you can install them with via Aptitude:

aptitude install apache2 lighttpd perlbal -y

I believe most package repositories have Apache and Lighttpd, though Perlbal could be a hit or miss. Luckily Perlbal is in CPAN so you can install it fairly easily:

perl -MCPAN -e ‘install perlbal’

2) Setting up Apache, Lighttpd

Once you’ve installed the packages you will need to configure both of the webservers to listen on a port other than port 80. The reason for this is Perlbal will  be listening on port 80 and deciding what to do with the requests. In this example I will have Apache listen on port 8080, and Lighty listening on port 8181:

Apache2 Configuration:

Listen 8080

It’s up to you to configure Apache completely, the point here is to simply have it listen on port 8080 instead of 80.

Lighttpd Configuration:

server.port = 8181

Once again it’s up to you to configure Lighty, we’re just having it listen on port 8181 instead of 80.

3) Setting up Perlbal

Now we have to setup Perlbal to handle the request. What we are going to do is have every request that is going to the subdomain “static.domain.com” be served via Lighttpd, and everything else via Apache. A quick note before we begin – Perlbal is capable of serving files, so Lighttpd is not required. I’m simply using it to illustrate how one would go about doing it.

Perlbal configuration:

load Vhosts

CREATE SERVICE select
SET listen = 127.0.0.1:80
SET roles = selector
SET plugins = vhosts

VHOST *.domain.com = apache_server
VHOST static.domain.com = lightttpd_server
ENABLE select

CREATE POOL apache_server
POOL apache_server ADD 127.0.0.1:8080
ENABLE apache_server

CREATE POOL lighttpd_server
POOL lighttpd_server ADD 127.0.0.1:8181
ENABLE lighttpd_server

In a nutshell this configuration does three important things – it tells Perlbal to listen on port 80 so it can accept the normal HTTP requests, it then says any request going to “*.domain.com” will be sent to our Apache instance, and anything going to “static.domain.com” go to our Lighty instance. For more information on Perlbals configuration please check out their documentation & mailing list.

4) Start everything up

Now we simply need to start up our web servers and Perlbal accordingly:

/etc/init.d/apache2 start
/etc/init.d/lighttpd start
/etc/init.d/perlbal start

5) See if it works

Last but not least we need to make sure everything works. Simply visit “domain.com” and make sure it loads accordingly, then visit “static.domain.com” and verify that loads. If both load fine it should be working – if you want to make sure you can take a peak in the logs to see incoming requests (/var/log/apache2/* , /var/log/lighttpd/*).

How do I setup the environment described in Scenario2?

In this setup we’re simply going to split the requests across two VPS servers. One of the VPS instances will house the Perlbal instance as well as the web server, and the other VPS will simpy house another web server.

1) Getting the packages

I’m going to assume you already have a web server of your choice setup on  both VPS1 and VPS2. All you will need to download is Perlbal:

On Ubuntu:

aptitude install perlbal -y

or installing Perlbal via CPAN:

perl -MCPAN -e ‘install perlbal’

2) Configuring the web server

The only configuration required on the web server is simply changing what port it is listening on. Keep in mind you only have to do this if Perlbal is sharing the same system as a web server – if you’ve decided to give Perlbal its own environment this is not necessary. In these examples I’ll assume you changed the web servers to listen on port 8080.

3) Configuring Perlbal

Now we have to setup Perlbal to listen on port 80 and direct the requests among VPS1 and VPS2

Perlbal Configuration:

CREATE POOL web_servers
POOL web_servers ADD 1.2.3.4:8080
POOL web_servers ADD 1.2.3.5:8080

CREATE SERVICE balancer
SET listen = 0.0.0.0:80
SET role = reverse_proxy
SET pool = web_servers
SET persist_client = on
SET persist_backend = on
SET verify_backend = on
SET balance_method = random
ENABLE balancer

Though the configuration is fairly self explanatory – we’re creating a “pool” and adding our web servers to it. We then create a “service” for Perlbal saying we want it to listen on port 80 and act as a reverse proxy. We also tell it to use the pool we just created. The other options you don’t need to worry about too much – though the “balance_method” option you have two choices: random and round-robin. The differences between them should be fairly obvious – random will choose a random server out of the pool while round-robin will go through each of the servers in the pool in a more orderly manner.

4) Start Perlbal

Now all you have to do is start perlbal:

/etc/init.d/perlbal start

5) See if it works

Simply visit your domain and see if the page loads – you can refresh a few times to make sure that it’s hitting both servers and both servers are responding accordingly. Once again you may want to check your web servers logs to verify it’s getting the requests.

This post is meant to be only a primer and not used in a production environment. I understand there are some principles I either skimmed over or completely omitted. This post was done solely off of memory and past experiences – so please be careful if you try to use a setup similar to the ones outlined in this post. If you come across any errors please let me know so I can fix them.

Some other similar topics I’ll try to cover in future posts:

• Setup software load balancing using HAProxy
• Setup software load balancing using NGINX
• Setup software load balancing using Pound

Poorly Made Wordpress Plugin

There is a wordpress plugin that when activated causes large amounts of strain on MySQL servers.  This is so bad it’s even bad on a dedicated server due to the nature of the plugin.  I believe it has to do with some sort of rss reader system and the ranking of posts but I am not entirely sure.  It does not sound bad yet but in every case we’ve had to warn or disable user accounts performing queries that generate millions of rows only to limit them to just a few displayed which is the sure sign of a poorly made query.  Some cases the user does not even realize it but with the plugin enabled their site was taking 10-15 seconds to load but they just sort of shrugged it off!  It was probably hurting their traffic significantly due to the page load times thanks to the query that even on an empty server would take 10-15 seconds to run!

The Chat Script

There was a web site recently that had a chat system right on the front page of their website available to their users.  This was a flash based system querying the server constantly.  It was causing a small site to generate hundreds of thousands of page views a day.  This meant constant php processes running and constant mysql queries to have the chat system to run.  It did not affect their page loads but it sure made a big red warning sign on our end to why in the world is a site using a large amount of the resources.  This was the most recent case but we deal with people all the time putting up chat systems on their sites that throws the users straight into the chat.  It’s just a recipe for disaster and in most cases once the users realize they disable it.  The few say we will host it elsewhere and our site and move and we just sort of shrug as someone using 10% of one of our servers is like a small dedicated server somewhere else.  It’s just not something we could afford to give someone or frankly any shared host could do for $10/month or whatever low price the user would be paying.  The most frusterating part about these is we clearly state we do not allow chat systems of any kind on our servers.

The Shoutbox

The one we deal with the most is the shout box which is basically a constant refreshing chat system. A user throws it on every page of their forum and turns that 1000 visitors a day into 100,000 page views. As their site grows it becomes more and more obvious to us what they’re doing and we end up asking them to remove it.  We point to our acceptable use policy about not allowing them and explain how little gain the shoutbox provides.  The cost to run one outweighs it’s gain and most agree but a few will disagree and believe 100,000 page views to PHP+MySQL is reasonable for every 1000 real visitors per day.  We never attempt to retain them as they cost us more than they’re worth having and it only gets worse and their visitor count climbs.

The Wordpress Skin

We’ve seen a growing trend of users sign up with us and they provide wordpress skins.  The scary part is just how many have not heard of relative links.  In some cases we’re used as an image host as all the skins images are accessed via http://thersite.com/skin/wp-content/images/myimage.png rather than the relative link so it would use the users server to display the image.  They are worse though some will have PHP code in their skin which will generate a side bar and rather than using a relative include they do <?php include(“http://theirsite.com/skin/sidebar.php”);  ?> Or using file_get_contents or something along those lines so that we are used to generate some sort of sidebar.  Now the most startling one I’ve seen thus far is one offering the ability to generate thumbnails in their skin.  Cool feature except they did not use the relative thumbnail generator url but rather their site’s url to do it.  As a result we were now acting as the thumbnail generator for various web sites images which is intensive and doing it a few hundred thousand times a day can really bog down a server and make a site use a lot of resources.  A very simple fix in every case except for the sites already using the older versions of the skins.

These are just a few of the common situations we run into constantly.  A very frusterating problem as most users never realize what they’re doing is a bad idea.  In some cases they do not even understand the problem making it impossible for us to even help.  Those cases they may very well just cancel over it and go to the next host with the same problem and repeat the cycle.  I figured I’d share a few of the many situations we deal with frequently.  These few users cause almost all our problems and if we were to have some automatic system to find all these trouble makers it would save us a lot of time.  That’ll never happen though as it’s a tough thing to allow normal amounts of traffic and just the odd intensive thing through while stopping these bad ones that crop up on machines.  There are hosts who have some systems in place but they shut down high traffic sites to so they base it off of the number of CPU cycles in x amount of time and the visitors get this nasty message.  Those would not solve our problems so they’re not an option and we continue to just look at resources being used on machines on a general overview and when a site is using an abnormal amount we contact them.  It would just be great if we could somehow know what a user would run 6 months down the road and tell them it’s not going to work.  I’m just dreaming though that’s mind reading

I’ve recently been fiddling around with multivariate testing on several websites I run (including Hawk Host) and I though it may prove to be a useful blog post for our customers. Here I’ll explain how to setup multi-variant testing using Google Site Optimizer and a simple web page (though you can apply it to any page / website).

Step One

After signing up for Google Site Optimizer sit down and decide on which portions of your website / webpage you want to subject to testing. Usually this is something like the a header, image, description or something along those lines. For example I’m currently utilizing it for Hawk Host on the tabbed content section.

Step Two

Once you’ve decided what you want to subject to testing on your website select “Create Experiment” on Google Site Optimizer. You will be prompted with two options: A/B Testing & Multivariate Testing. Select the latter. You will be prompted with a brief introduction to selecting which portions of your website you want to subject to testing (same as I said above) – scroll to the bottom of the page and select the check box and hit “Create”.

Step Three

You will now be asked to provide three URL’s:

1. Name Your Experiment
   This is an internal name for your experiment. Name it anything you like.
2. Identify Your Test Page
   This will be the URL to the page you’re testing. In Hawk Host’s case it’s the main page, or www.hawkhost.com
3. Identify Your Conversion Page
   This will help you identify which variants are converting – usually this will be your shopping cart success page or the page you want the visitor to end up on (a sales page, etc)

Once you’ve filled out the prospective fields hit “Continue”. You will be prompted with two radio buttons asking if your team will be installing the JavaScript code or if you will be. Depending on your situation select the appropriate option (usually the latter one).

Step Four

Here’s where we get nerdy. You will be presented with four sections of JavaScript to add to your webpage, each are very important so don’t skip any.

1. Control Script
   You will put this right after your beginning <head> tag. This just adds Googles JavaScript functions to help identify the sections you’re testing.
2. Tracking Script
   Paste this right before your closing body tag (</body>). This chunk of code adds Google’s tracking to your web page to provide detailed stats on which variants are being displayed, converted, etc.
3. Page Selections
   Use the example they provide for you and paste the code they provide right before the portion you want to be a variant. Here are some examples:

   
<script>utmx_section("heading")</script>
<h1>Test heading</h1>
</noscript>

   <script>utmx_section("content")</script>
<p>Test content</p>
</noscript>


   In these examples the portion directly following the utmx_section code is the default content. Usually this is what you currently have on your website. The variants are handled on Google’s end.

4. Conversion Script
   This portion of code will goes to the page where you want the visitor to end up. Usually this is a “Thank you” page after purchasing an item or something of that nature. Paste this on that page (ideally near the bottom).

Once you’ve done that select “Validate” – this will attempt to validate that the scripts are properly installed. Don’t be concerned if the conversion portion fails – depending on the software you’re utilizing for your website you may not be able to confirm the code directly (EX: success page after purchasing an item). Select “Continue” if everything passes the validation.

Step Five

You will now be prompted with an area to create your variants. You will notice all of the sections you created now show up on the left. Simply select “Add new variation” under the section you want to create a new variant. It will bring up a little text box with the default HTML code for your default value. From here modify it however you see fit – once you’re finished (make sure to preview it!) select “Save”. Go and do this for every section – but don’t add too many variations for each section. Unless you have a large amount of traffic you won’t get enough statistics on each permutation and will end up with worthless stats. Google recommends no more than 3 variations per section (we personally use 5~ per section on Hawk Host).

Once you’ve finished select “Continue”

Step Six

You will be brought to a page with a summary of your experiment. The most important thing on this page is deciding how much traffic you want to send to the experiment. If you select 100% that means everyone visiting your webpage will be subject to the variating content. If you select 50% only half of the visitors will be subject to the variating content, the other half will see the default content. We personally use 100% the majority of the time depending on how drastic the content change is. Use your discretion here.

Once you’ve finished with that select “Launch Now”

Step Seven

Wait! Wait several weeks to gather enough statistics – Google will provide you with in-depth stats on which combinations are being displayed, which are converting, and if possible it will tell you which seem to be converting on a regular basis. Using this information you should be able to find tune your website to convert as much as possible (based on design at least).

I hope this was useful to someone – I’ll try to clean this post up a bit over the next week or so, though feel free to ask any questions you may have in the comments. I’ll add image in the next couple of days to help clarify the steps mentioned.

Until next time,
Cody