UNIXy

Varnish is an excellent Web accelerator that can be made to proxy requests in and out of a cluster of somewhat more fully fledged Web servers like Apache or Litespeed. It has some great features like its compiled language, called VCL, and C-like programming API.

Large vBulletin deployments tend to be heavy on CPU and memory due to PHP script processing. For a large vBulletin forum, we recommend a cluster of 5 physical servers with three of those running Xen virtualization. One of those servers will be dedicated to the MySQL master database. Three to be setup as “headless” PHP nodes and Varnish load balancing and failover. And finally one as the NFS file store. The three headless servers need to run Varnish in their own VM and Litespeed or Apache in their own VM similarly.

The varnish backend director functionality makes it ideal to balance incoming traffic across all PHP headless nodes. It makes the configuration scalable and plug and play especially when needing to scale out within hours. The challenge in this setup is in making Varnish work correctly with vBulletin. Otherwise, session problems will occur.

We have a lot to share on this implementation so keep checking this blog as we will post it all. In the next installment, we’ll go through our deployment of a large vBulletin forum for a customer. In the mean time, feel free to get in touch should you have a question or comment.

That’s all folks!

UNIXy Crash Course accelerator, Apache, cluster, failover, litespeed, load balance, MySQL, varnish, vb, vBulletin, Xen

My interest in NUMA (Non-Uniform Memory Access) has picked up quite a bit as of late. This technology has a huge potential for application in large scale Web hosting and Internet solutions. In brief, NUMA is a technology that was conceived to get around bus contention in general. What this means is that, with NUMA, programs are no longer limited by memory size or disk IOPS on the same host node and can, therefore, harness the power of other nearby servers as if they were part of the same chassis. In fact, IO scales up as a result!

The problem with uniform memory access architectures is that in a single chassis multi-processor system with a large amount of memory the bus tends to saturate very quickly. Processor cores addressing the memory bus are thus contending for the same resource, which becomes a hot spot. Take a 32-core server with 128GB of DDR3 memory. This server will under perform should it run a parallel memory hungry application. The issue being that each task on a core will at some point need to address memory via the bus (DDR3 is a three-frequency or three-channel bus). So out of 32 tasks that are all attempting to access the bus, there will be (32 -3 = 29/3 ~ 9) 9 tasks that contend for the same channel. The end result is a saturated bus and poor performance.

NUMA solves this bus contention problem by creating a virtual network of processor nodes and giving each node a certain weight based on its locality. The most interesting aspect is its true scalability potential. Most importantly, NUMA is the only technology that can scale up. Amazon’s EC2 and most other technologies in the market nowadays can only scale out. In other words, one has to implement load balancing, replication, and data synchronization.

Here’s where it gets interesting. IBM has already comoditised NUMA with its x86 offering: the IBM x440. Although one can only chain two x440 chassis together to form one NUMA network, what was once a concept is now practical! The x440’s can be chained together via their SMP expansion module using remote IO cables. Now imagine having the ability to chain 5, 10, 100 16GB dual quad core boxes! Not only does one take advantage of of a few terrabytes of memory but also scale core compute and IO.

A challenge remains. The remote IO cables that allow formation of a NUMA node cluster is based on proprietary technology. The research and development effort required to deliver such technology is colossal for a smaller firm. Or maybe not!

Joe Future Amazon EC2, bottleneck, cloud, EC2, nehalem, NUMA, rackspacecloud

How else would we attract and keep customers? Does it mean that we have to offer better servers? Is it better uptime? Or is it better service? You bet! It is a difficult feat because one has to keep a perfect record in such competitive environment. Not only do we need a perfect track record but we also need to add value; something the competition has gotten too “fat” to afford providing to customers.

As an example, we are proud to offer third-party application support for in-house or custom software. It translates to hours of free labor on our part. We also offer free hardware upgrades and technology refresh all year long. Larger firms cannot afford to give away complimentary upgrades or provide such higher quality service.

Let us take Hostgator for example. The firm is spending hundreds of thousands of dollars on advertising. It does not impact their bottom line should they make a mistake. In fact, it does not matter at all because they are able to replenish their customer base very quickly. They could care less about low churn rate either (to an extent), again, because of the snowballing and psychological effect that their advertising campaigns create. There is no incentive in providing free add value services.

We, on the other hand, do not advertise. I know that is shocking! In fact, most sign-ups come from customer referrals; our own customers take the initiative to refer others to us, which we are very grateful for by the way. Primarily because we go above, beyond, and through. We do not nickel and dime either.

We have to be better than them!

Joe Business care, competition, service, value

We have had great success with Mediawiki running behind Varnish, a proxy / web accelerator. The role of Varnish is to cache as many requests as possible. This helps alleviate resource consumption on the server such as CPU, memory, and disk, which in turn greatly improves performance and browser responsiveness. With Varnish in place, the load average went down from 30 to 4!

Configuring Varnish is a bit involved and we shall cover it on the next installment. In the mean time, here are some measures that can be put in place to gain a quick performance boost without much complexity.

1. Enable Eaccelerator or Xcache OR
2. Enable Mediawiki’s FileCache driver: $wgUseFileCache = true; AND
3. Enable MySQL query caching by increasing query_cache_size in the configuration file
4. Compile and enable Apache’s mod_mem_cache

Be sure to disable suPHP and set the correct permission on the cache directory so the Apache user is able to read/write to the cache. The cache directory is usually located directly under ${DocumentRoot}/.

As part of our fully managed service, we optimize and configure customers’ servers free of charge! Ask how we can improve your portal’s performance. That’s all folks!

UNIXy Crash Course