ipHouse Blog » Doug Rau

Speeding up CSS

Doug Rau — Tue, 31 Jan 2012 16:14:16 +0000

As web pages become richer and more complex, they can also become burdened with numerous CSS files, background images, icons, and scripts which put additional load on your network and degrade the user experience of your website. Fortunately, there are a few things you can do to improve things.

First, its become common practice for many pages to have at least three stylesheets; one for all media, one for screen-specific instructions, and another for print. Other stylesheets might be imported for specific pages or resources, such as a lightbox library or HTML form suite. Instead of putting each stylesheet existing in a separate file which must be loaded and parsed separately, consider consolidating them as much as possible by using @media directives within the CSS file. For example,

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // combined.css // these styles apply everywhere, all the time
body { color: black; }
h1 { font-size: 150%; font-weight: bold; }
// – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - -
// these styles only apply on-screen
@media screen {
body { background: url(‘background.jpg’); }
div.nav a:hover { font-weight: bold; }
}
// – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - -
// these styles only apply in-print
@media print {
div.nav { display: none; }
p { text-align: justify; }
}
// – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - -

Placing all your stylesheets in the section of your web page is best practice, and also improves apparent performance since the web browser can load and parse the style information before it begins rendering the page body. Associating stylesheets via tags instead of @import is better, since not all browsers handle @import directives promptly.

Also consider using Expires headers to instruct web clients to cache CSS files for a long time. In apache, this is easily achieved through the mod_expires instructions,

ExpiresActive On ExpiresByType text/css "access plus 1 year"

If you need to retain the ability to change your CSS files more frequently, add a version number to the filename and update it as necessary. For example, combined-1.0.css

What does a VDC get you out of?

Doug Rau — Fri, 20 Jan 2012 18:38:45 +0000

A vmForge virtual data center gets you into a private pool of computing resources which you can custom configure to your needs. It gets you into a lean, efficient, reliable, and elastic platform for your business, which can easily grow as you do. But it’s also worth looking at what it gets you out of.

It gets you out of hardware. Out of substantial up-front costs, management and repair, depreciation, and end-of-life planning.

It gets you out of data centering. Out of power, cooling, and cabling overhead and management.

It might even get you out of this. With a virtualized infrastructure, you can get access to and administer your servers and network from almost anywhere. From your office, your home, the beach…

What else could you be getting out of with a virtual data center?

Idle Thoughts: Things to do with your VDC

Doug Rau — Tue, 17 Jan 2012 20:19:31 +0000

By now, you might have a virtual datacenter, and whether by design or happenstance, you might have some extra capacity in reserve. Rather than letting it sit idle, why not utilize it for some small, temporary projects? Since creating and starting a virtual machine takes minutes instead of hours, and the resources invested can be recovered just as quickly, its relatively easy to explore options which you might not have had time for before. Maybe you can solve a problem you’ve been struggling with, or discover new capabilities for your business. Here’s a few ideas.

If your company still doesn’t have a blog, it can be a great way for your employees to connect and communicate with your market in a regular and timely manner. If you’re already blogging on LiveJournal or some other blog community, you might want to bring it in-house, to take greater control over your blog’s capabilities or user experience, or to consolidate staff blogs in a single location.

Managing a modern, complex web site can be made easier using a CMS, or content management system. A CMS can help you think about your website as separate design, structure, and content layers, and work with these layers separately for best effect. It can also help decentralize maintenance and updating, while enforcing consistency across the site. Some blog software can double as a basic CMS, but there are many systems capable of much heavier duty.

A photo gallery, either public or private, can provide a single, controlled repository of photos taken by your company of products, processes, and publicity events for reference or use in blogs, training, etc.

As your business grows, you may reach a point where email can’t keep up with your customer support needs. A support ticketing system offers a single, shared repository of customer issues and responses which can be used and referenced by everyone on your staff.

Wikis can be a great solution for collaborative knowledge management and documentation. An internal wiki could be used to document and maintain your company’s documentation on everything from products to processes and policies. Pages can be created in the wiki for ad hoc planning and documentation of individual projects.

Have more ideas on what else you could use your VDC for? Post them in the comments!

Building things: cubicle analogy time

Doug Rau — Wed, 04 Jan 2012 22:17:34 +0000

This week, I’ve been building (actually, rebuilding) cubicle desks in our new office space and comparisons were naturally drawn to building virtual machines a few weeks ago.

Building a cubicle, no matter what the instructions say, is not exactly trivial. Even after putting the walls together, trying to get them all even and lined up is a trick. Then putting up the desk supports and the desk surfaces themselves, which are usually massive slabs of particle board and plastic veneer. If they’re fastened with screws, it’s always from beneath, out of the light, where you’re certain to get wood dust in your face.

In stark contrast, using vCloud Director to build a virtual machine was easy. Login, select a hardware and OS template, optionally configure, and deploy. It was up and running in a few minutes, maybe a little longer if you have added software or network configuration requirements. It’s all done with a keyboard and mouse, and I’m pretty certain I’ve never gotten wood dust in my face from it.

In both cases, a little planning goes a long way. Making a map of your cubicle layout lets you know whether everything is going to fit, what you’ll need, and whether you have it. Updating your map when you change your mind is also important. Making a map of your systems and network is similarly illuminating. How much CPU, memory, and disk do you need? What systems need outside IP addresses?

Also, paying attention to the details pays off. It’s a lot easier to make the desks level if all the supports are attached at the same height. Double check your IP address assignments and DNS records.

Finally, building a virtual machine doesn’t involve any power tools. Well, let’s hope not.

Setting up a LogicMonitor Agent

Doug Rau — Fri, 30 Dec 2011 19:38:21 +0000

LogicMonitor is a really cool server and network monitoring and measurement system which we’ve been working with. It uses a lightweight monitoring agent installed on your local network which collects data from your systems and passes it over SSL to an external aggregator. It’s capable of auto-discovery and is mostly self-configuring though you can adjust many of the metrics. After many years of working with patchwork monitoring and alert systems we’re pretty excited about it. Call us if you’re interested.

Setting up a monitoring agent on your local network is easy. The server hosting the agent just needs a JRE (Java Runtime Environment) installed using version 1.6 or greater and must be able to make an outgoing SSL connection. To monitor Windows systems, you’ll need to install the agent on a Windows server.

Login to the LogicMonitor website, click on the “Settings” tab, then on “Agents” in the left navigation, then on the “Add” button. Click past the introduction, and indicate whether you’ll be installing the LogicMonitor agent on a Windows or Linux server. Download the agent installer, or copy the link and use wget to download the installer directly to your Linux system. Run the installer to install the agent on your server then return to your web browser and click “Next” to verify that its been installed correctly and is able to communicate with the LogicMonitor system.

To begin monitoring a host on your network, click on the “Hosts” tab, then on the “Add Hosts” button and select “New Host (wizard)”. Enter the host name or IP address. Note that if your monitoring agent and host are on a private internal network then this should be the IP address visible to your agent. Select your monitoring agent (if you have more than 1), and LogicMonitor will go ahead and verify that its able to gather information about the host.

NOTE: at this time, LogicMonitor does not support IPv6

SysAdmin Golf: The Hard Way

Doug Rau — Fri, 09 Dec 2011 19:04:01 +0000

This is the hard way to p2v a Linux server into a vmForge VDC. You’ll need the VMware Converter bootable CD, and somewhere to store your disk image. If you have a Windows server and shared disk on your local network, that may be faster than a USB hard drive, which is what I used. This is a cold clone procedure, which means that your server is down while its being copied. And it may be down for a while, depending on how much disk your server has, how quickly it can be cloned to local storage, and finally how quickly it can be uploaded to your VDC.

Reboot your server from the VMware Converter CD. Once VMware Converter is running, click on “Import Machine”. Click through the first couple of panels. On the “Source Data” panel, select “Import all disks and maintain size”. On the “Destination Type” panel, set the destination type to “Other VMware Virtual Machine”. On the next panel, set the VM Name and the Location where you’re storing your disk image. Since Converter doesn’t support direct OVF export here, you’ll have to set the type of virtual machine to Workstation 6.x and change it later. Click through the rest of the panels, and Finish. VMware Converter will now export your server to a .vmx description file and .vmdk disk image(s). This may take a while.

After VMware Converter is done, you’ll need to use VMware’s OVF Tool to convert the .vmx file to a .ovf file.

ovftool.exe name.vmx name

Next, the tricky bit. You’ll need to edit the .ovf file, which is in XML format, and find and update the VirtualSystemType field to vmx-07, a reasonably current version. Once you’ve edited the .ovf file, you’ll also need to generate its SHA1 hash and update the .mf manifest file. Now, you should have something which can be imported into your vmForge VDC.

Login to your vmForge VDC (or any VMware vCloud Director system), and create a new catalog if you don’t already have one. In your catalog, click on the Upload button. Select your .ovf file, give it a name and description, and click on the Upload button. Again, this may take a while. Once its done, you’ll be able to use the template from your catalog to create a new virtual machine, a clone of your old physical server. The last step will be to power on the virtual server, login via the virtual console, and reconfigure networking.

uncomplicated firewall

Doug Rau — Fri, 02 Dec 2011 17:05:55 +0000

ufw, or uncomplicated firewall, is the default host firewall tool for Ubuntu and is designed to be easy to use.

unless you don’t realize that its been enabled for you, in which case you’re likely to spend an hour bashing your head into something trying to get nfs to work. ufw is normally driven from the command line, although a GUI is also available.

you’ll need to have root privileges to run ufw.

the command to see whether or not ufw is running is ‘ufw status’. if ufw is not running, you should see…

$ ufw status
Status: inactive

if ufw is running, you’ll see something like this instead…

$ ufw status
Status: active

To                         Action      From
--                         ------      ----
Bind9                      DENY        Anywhere
22                         ALLOW       Anywhere
3306                       DENY        Anywhere
Apache Full                ALLOW       Anywhere

here, ufw is active, and is configured to deny or allow specific types of traffic. for example, connections to port 22 (ssh) are allowed from anywhere, whereas connections to port 3306 (mysql) are denied from anywhere. in addition to simple port numbers, ufw can recognize applications, such as ‘Apache Full’ (ports 80 and 443/tcp). for more information, see the Application Integration section of the man page.

the basic command for opening ports is ‘ufw allow 161′. ufw will also refer to the /etc/services file if you specify services by name, ‘ufw allow snmp’. either will allow connections to port 161 (SNMP) from anywhere.

these examples imply ‘from any to any’, but you can also specify source and host addresses. for example, ‘ufw allow from 10.0.0.42 to any port 161′ only allows connections to port 161 from a single address. you can also specify a netblock, such as 10.0.0.0/24. there are additional options, including specifying protocol (tcp or udp) and direction, and limiting or rejecting connections (instead of dropping them); see the man page for these and for more examples.

also note that rules are processed in order, and the first match wins. more specific rules should come first, followed by more general rules. you can insert a rule into the list using ‘ufw insert 2 allow snmp’ (here, into the number 2 slot, moving the current number 2 and following rules down one slot).

ufw isn’t a bad thing to have running on your ubuntu host, and is particularly important if its not behind a network firewall. but if you’re having problems getting a new service running, it’s probably something worth looking at.

comparing software load balancers

Doug Rau — Thu, 01 Dec 2011 19:42:19 +0000

now that i have three different software load balancers installed (Balance, Crossroads, and Pen), i want to evaluate their relative performance. benchmarking a single web server isn’t difficult using tools like ab, but trying to benchmark a load balanced cluster is somewhat different. since most load balancers support stickiness, all the requests from a single source will be directed to a single back-end server. thus, i’ll need to run the benchmarker from several different sources simultaneously, or i’m really just testing one server with something in the way. fortunately, i have three machines on different IP addresses sitting idle.

my first test is 10,000 requests for a static HTML page (2866 bytes). this test was run against a single apache server in the pool and against each of software load balancers with two back-end servers, from one source and from three simultaneously.

handler	single source	three sources
apache only	21.659 seconds	33.822
balance	106.794	failed
crossroads	37.729	failed
pen	39.112	failed

the single apache server actually performed the best, easily beating any of the software load balancers in raw throughput. the test from three sources is effectively a mild denial-of-service attack, and none of the software load balancers could handle it. each of them failed and stopped accepting connections well before 10,000 requests were completed.

the second test is 20 requests for a PHP script which performs exactly 1 second of mathematics then returns results. in this case, almost all the load is on the back-end servers, and there was negligible difference in results between the four front-ends.

the third test is 400 requests for the PHP script, but issuing 20 concurrent requests from each source at a time. this generates significant load on the back-end servers, but is the first test where having multiple back-ends shows any improvement.

handler	single source	three sources
apache only	23.493 seconds	31.097
balance	22.820	26.191
crossroads	34.199	40.355
pen	24.721	28.365

the fourth test is a monster, 400 requests for the PHP script, 100 concurrent requests from each source at a time.

handler	single source	three sources
apache only	14.912 seconds	22.604
balance	10.355	18.909
crossroads	failed	failed
pen	15.219	failed

these results suggest that a software load balancer might be an option for putting more capacity and resilience into a script-heavy website, but clearly shouldn’t be chosen for performance. the single apache server performed better than my small cluster in nearly every test, and much better in a few cases. the total meltdown of the software load balancers in difficult situations is of particular concern. the results for the cluster might improve with more back-end servers, but the software load balancer itself seems to be the bottleneck.

of the three software load balancers, the simpler Balance and Pen outperformed Crossroads in general. interestingly, Balance fared spectacularly poorly against heavy traffic in the first test, but very well against a different sort of heavy traffic in the fourth.

software load balancing

Doug Rau — Tue, 29 Nov 2011 17:20:56 +0000

load balancing is a common technique for distributing a workload, such as handling a web site, across multiple servers. a pool of several smaller servers can be more efficient than a single large server, since the size and capability of the “server” can be changed just by adding or eliminating servers from the pool. a pool of servers can also be more responsive than a single server, and more fault-tolerant.

one of the simplest forms of load balancing is round-robin DNS, where a single hostname is pointed at multiple IP addresses, each of an individual server. this is very easy to set up, but changes to the pool are limited by DNS caching and TTL. on the other end of the spectrum are dedicated hardware load balancers, such as the F5 Big-IP we use, which monitor the status of each server in the pool and intelligently route incoming requests. these are awesome machines, but come with equally awesome price tags. between these two extremes lie some network firewalls with load balancing, and software load balancers, which run on a front-end server.

i’ve been looking at a few software load balancers for a small virtual server project; Balance, Crossroads, and Pen.

Balance looks interesting, and supports either round-robin or sticky load balancing, and failover. it also supports IPv6 on the listening side, which might be useful if you have to bridge IPv6 into a pool of IPv4 servers. unfortunately, the Ubuntu package is an old version which i was unable to get working properly, and i had to compile from source instead.

what’s sticky load balancing? directing requests from a particular client to the same back-end server, when possible. this is useful for applications that need to support state or session information between requests.

what’s failover? if none of the servers in the regular pool are available, requests are directed to a backup server. the backup server is usually only intended to return a friendly ‘site down’ page.

Crossroads appears to be a fast, multi-threaded, and very capable load balancer. it supports a variety of dispatching algorithms, including several different ways of handling stickiness. although it doesn’t support failover, it does offer options for access control, protection against overloading, and a basic web interface. although the Ubuntu package is an older version, i’m using it because i wasn’t able to get the current version to compile.

Pen is probably the simplest of the three. and although it’s the only one with a current package which installed correctly, its documentation is pretty sketchy. it supports round-robin and sticky load balancing, and has “highly experimental” support for SSL.

Reengineering in a Virtualized System

Doug Rau — Thu, 10 Feb 2011 18:06:53 +0000

In addition to scalability and redundancy, one of the advantages of a virtualized system can be a single point of configuration across multiple servers. This not only streamlines day-to-day maintenance, it can also facilitate making significant system engineering changes.

For example, several months ago, we looked to FastCGI to improve the performance of PHP scripts on our webhosting cluster. These scripts have always run under individual account UIDs for security, via mod_cgi and suexec. However, this additional overhead meant that PHP scripts took longer to run and required more CPU relative to the in-process execution of mod_php.

The ipHouse webhosting platform is a load-balanced cluster of multiple identical web servers. In a non-virtualized system, each of these web servers would have its own set of account and server configuration files (etc/passwd, httpd.conf, usw.) which needed to be maintained and kept synchronized between servers. In our virtualized cluster, each server loads its configuration from centralized sources. All server configuration is stored in a shared file repository, and all user account information is stored in a database and retrieved as required.

After determining the necessary pieces, implementing PHP via FastCGI was relatively trivial. Beside installing the mod_fcgid package, it took just a few changes to the shared server configuration files. After waiting for each server in the cluster to load the updates (an automatic process), we were done. Really, that’s it. Virtually any change is write once, run everywhere.

Technical

# Load the FastCGI module
LoadModule fcgid_module libexec/mod_fcgid.so

# Assign PHP scripts to the FastCGI module
AddHandler fcgid-script .php

# Execute PHP scripts via the fcgid_php wrapper script
FcgidWrapper /webroot/cgi-bin/fcgid_php .php

# Enable additional script path processing
# Make sure that cgi.fix_pathinfo is set to 1 in php.ini
FcgidFixPathInfo 1

# Terminate processes after handling some number of requests
FcgidMaxRequestsPerProcess 10000

The fcgid_php wrapper script is a relatively simple shell which sets up the environment before launching the PHP interpreter.

#!/bin/sh

export PHP_FCGI_MAX_REQUESTS='10001'
ulimit -t 3600
exec /usr/local/bin/php-cgi