Cloud computing, as we currently know it, is broken.  Data isn’t always persistent,  instances are unstable, pricing is confusing, and professional management is nowhere to be found.  Although we will tip our hats to bringing cloud computing to the masses, the cloud model needs a reboot.  It often seems like each month another company releases a cloud computing offering, but nobody ever takes the next step in maturing the delivery mechanisms, stability, or business model.  It is for these reasons that Contegix is proud to introduce Zeus, a managed cloud computing platform aimed at providing consumers with the power and flexibility of virtual systems coupled with the management support that only fully-managed data centers can provide.

Zeus is a unique cloud service that will provide persistent storage, reliable uptime, and managed support.  Based on VMWare ESX, fronted by high-end network gear and physical level 4-7 load balancers, and backed by true SAN storage and advanced monitoring, customers of the Zeus platform will be able to build powerful architectures that scale reliably.  Furthermore, with a 100% network and 100% power uptime SLA, security and compliance audits available for viewing, and the option of including Contegix’s world-class management support, cloud computing is now ready for the enterprise.

Another feature of Zeus that we’re excited about is the use of templates.  Zeus will come with virtual machine templates for several different common configurations.  If you want an Apache box, spin one up.  If you want a MySQL box, spin one up.  And it all happens in about 5 minutes.  If our templates aren’t meeting your needs, or you need to replicate the same instance over and over, simply upload your own template.  Better yet, convert your physical boxes with P2V and upload your enterprise.

Stay tuned for more information on Zeus.  Private beta is targeted for availability at the end of June, with full production availability at the end of July.

Here at Contegix we take pride in the superb team of technical engineers we have on staff.  We have a great team of dedicated engineers who truly enjoy the work they do each and every day for our customers.  We have a team of superstars, and we thought some of our customers might be interested in learning a bit more about what makes our engineers really tick.   Therefore, we give you the opportunity to “Meet the Contegians” through Q&A sessions with our engineering staff.

First up, Mark Rogers, technical support lead.

Mark, where we you born?

St. Louis, MO

What is your favorite open source project?

Pylot, www.pylot.org.  I’m pretty biased though, considering I’ve contributed code to it in the past, and I am listed as a contributor.  It is a sweet load testing application that works in Windows or Linux though.  It is definitely worth checking out if you ever need to do some load testing.

What is your favorite Linux tool?

There are a few items in the land of Linux that firmly cement me in my operating system of choice.  Some I can get elsewhere I suppose, but I can’t live without Klipper, Grep, and BASH.  Sure, I can get most of these in OSX, except for Klipper.  I know there are knock-offs available, and that I could install the KDE stack if I had to, but it’s just not the same.  Klipper managing my clipboard is the best tool I’ve ever used.  With how much copying and pasting I do in my day-to-day life, it’s nice to see the last 300 or so items that I’ve highlighted on a whim.  It comes in handy just way too often.

What is your favorite operating system?

I’m a big fan of Ubuntu.  It’s stable, has deep repositories, and has a ton of community support.  At work I need a distro that is stable, but I also need to be able to install random, off-the-wall packages at times for the various needs I have at work.  Plus, I love to play with new applications all the time as well.  The chances of finding an RPM seem to always be small, but finding Debs is generally easy.

What do you like to do in your spare time?

Well, I blog www.f4ntasmic.com and like to write code.  My personal language of choice is Python, and thus I’ve been playing with Django a LOT lately.

Any personal projects you are currently working on that you would like to talk about?

Well, when I was learning Python I decided to write an application that wraps the Confluence Remote API’s xmlrpc calls.  It is actually handy at times since just about anything you can do in Confluence; you can do via this application remotely.  You can add users, remove users, update posts, add new posts, and so on.  This can all be done without ever loading a browser.  You can find it at Confluence Remote Manager.

What are you currently running system-wise?

I’m running an Acer Aspire right now.  Specs are as follows:

Intel Core 2 Duo 2.2 GHZ
3GB of RAM
250G hard drive
Nvidia GeForce 9500 (I think.  I could be wrong, but its’ nice.)

What books, magazines, and journals are you currently reading?

I’ve had a subscription to PC Gamer for about five or six years now, so I’m always reading that.  Even though it’s recently jumped the shark in my opinion with this new EIC.  Bring back the editorial columns please!!!  Not really reading any books right now.  I have a stack of Ruby books I need to read, along with some stuff on PyGame.  They’re just staring at me, begging to be read.  If only I could just suck the knowledge out via osmosis or something.

What was the last book you read?

Python Web Development with Django.  It was a decent read, and it got me rolling with Django.  The online docs for Django are great and all, but I learn so much better from books.  Plus, this was one of the few books already updated for Django 1.0.

What is your favorite book of all time?

Fahrenheit 451.  Amazing book, terrible movie.  I personally feel everyone should read the book at least once, so that they can see the dangers of law by opinion and censorship in general.

What music and movies do you enjoy?

I enjoy all sorts of music genres like rap, death metal, hair metal, anything from the 80’s, a bit of country, some pop, and other random stuff.  My favorite bands in rotation right now though are the White Stripes, 3OH!3, and Mindless Self Indulgence (only their first CD.)  Movie –wise I enjoy most of the David Lynch films (Mulholland Drive, Blue Velvet, Lost Highway), and other movies that tend to make me think.  That’s not to say I don’t love mindless comedies and action flicks though.  I’m a huge fan of parody movies like Scary Movie, Airplane, Naked Gun, etc.

What was the last movie you saw?


Yes Man with Jim Carrey.  Pretty funny overall.  It’s Liar Liar, but this time he has to say, “Yes” to everything instead of not lying.  Incredibly original and creative.  ☺

What is your favorite movie of all time?

That’s tough.  It’s one of three:

SLC Punk
The Jacket
Pulp Fiction

I don’t think I could pick just one.

What was the last concert you attended?

It’s been awhile since I’ve been to a concert.  I think the last one might have been Nine Inch Nails like eight or nine years ago.

What is your favorite band of all time?

If I had to pick just one, it would be Nine Inch Nails.

What do you like most about working at Contegix?

I get to play with random cool technology just about every single day.  I never know what the day has in store for me, and for the most part, no two days are the same.  It helps keep life rather interesting.

What do you like most about our customers?

That’s a tough question.  Customers are so unique, that it is hard to find a global reason on why I like all of them.  We are home to some major open source projects and players, and I love that.  I love to see customers building a business with open source software, and to contribute to the open source community in the process.  We also have customers that are building applications that you can see the potential in, and that I find myself browsing at times.  I guess I just enjoy that a lot of our customers are very creative and seem to be living the dream of doing what they enjoy.  I’m glad to be a part of that in whatever capacity that might be.

The winners were not supposed to be announced until May 1st. Yet, you can not keep the publisher and the USPS from their missions…

We are very proud to announce that our customers and the readers of the Linux Journal have selected Contegix as the top linux-friendly web hosting company, ahead of some of the biggest names in hosting. The June 2009 issue of the Linux Journal features the results of the Annual Reader’s Choice awards, where the Linux community votes on top products, tools, and services in the market. Contegix had a higher percentage of votes than any other hosting company included in the survey. We are proud to share the “favorite” distinction with many other excellent Linux products, such as Ubuntu - the “favorite primary Linux distribution”, Apache - the “favorite web server,” and Python - the “favorite programming language.”

From the article:

Talk about a meteoric rise, Contegix went from one write-in vote in 2008 to champion of the Favorite Linux-Friendly Web Hosting Company category in 2009. Otherwise, four well-known names have remained among your perrenial favorites for years, namely Rackspace, GoDaddy.com, DreamHost and 1&1. Of the four, only Rackspace broke the 10% barrier this year for Honorable Mention, while the other three were just shy of the mark. GoDaddy.com was category winner last year, and DreamHost and 1&1 were the two Honorable Mentions.

Everyone here at Contegix would like to thank our customers, our partners, and the members of the Linux community who voted for us. This award would not have been possible without your support. You trust us everyday to manage your infrastructures. We are grateful for that privilege and the award you bestowed upon us. You are the reason we do what we do.

Finally, we would like to thank the Linux community in general for continuing to develop the technologies that we know and love and that make us passionate about being the best Linux hosting company we can be.

(Picture of Phil Jacobs from StyleFeeder who sent us our first congrats tonight.)

Contegix is proud to announce our platinum sponsorship of Atlassian’s upcoming user conference, Atlassian Summit.

Summit is Atlassian’s first ever user conference, designed to provide information to developers, users, managers, and anyone else interested in the Atlassian suite of collaboration and development tools.  Some of the agenda points include:

• the future of collaboration and dev tools
• roadmaps, feature previews and demos
• how-tos on deployment, tuning and mods
• in-the-code labs on plugins and APIs
• presentations from your peers
• “meet the engineers” workshops

As the platinum sponsor for Summit, Contegix hopes to show the Atlassian user community our dedication to Atlassian’s products and customers, and how users can pair Atlassian’s software with Contegix’s hosting and management for a truly powerful collaboration and development environment.

Summit is being held at the Palace Hotel in San Francisco from May 31st to June 2nd.

For more on Summit, visit Atlassian’s Summit homepage.

NR Notify is a simple ruby based notification tool for New Relic RPM. With NR Notify you can add email and SMS notifications to your Ruby on Rails and Merb applications. By using the the New Relic API, NR Notify provides email and SMS notifications based off of your “Traffic Light” settings within New Relic.

Features:

• Multiple Email Support
• Multiple SMS Support
• Adjustable Alert Escalations Policies
• Supports Multiple Rails Applications
• YAML Configuration
• Adjustable Update Interval

New Relic Notify is easy to setup. All you need to do is adjust the config.yml to your liking and run the included Ruby script. However it is recommended that NR Notify is ran under a service manager such as daemontools or runit. This also requires a SMTP server to deliver the emails.

For more details on NR Notify please visit our project home:
http://code.contegix.com/wiki/display/NRN

For the project source please visit:
http://code.contegix.com/svn/NRN/trunk

Back in December when things slowed down a bit we were asked to try to use the free time to catch up on documentation.  One of the specific areas of documentation that is usually neglected is that of what is on the servers.  My first thought when I saw the request was “why isn’t this happening semi-automatically”.  In order for us to document a server we run commands and then format the output to be understandable and pretty.   There is little or no reason why these commands could not be put into a script and ran automatically.

So I started out writing a bunch of little scriptlets to do the different parts of the documentation procedure.  When Mark saw what I was doing he suggested that we take this a step further by having one big script that does all the documentation and outputs it in wiki-markup that could go straight to confluence.  So we collaborated on building a big documentation script.  Then through work on another project to build a tool that would allow engineers to copy files to a customers server through the central midpoint server I realized we had the potential to push and pull this documentation with little effort.

Meanwhile Mark was working on a program that would allow an engineer to post a document to confluence from the command line.  With this program and the copy program the workflow was complete.  By building a wrapper script using some of the logic in the copy program I could push the documentation script up to a customers server then pull the output back, remove the litter files on the server then push the output document up to confluence all in one easy command.

Once things were working as intended it struck me that our initial attempt at the documentation script was not nearly detailed enough.  So I went back and rewrote the hardware section to use the Dell utilities or fall back on standard Unix utilities if the Dell software isn’t present.  Then I started to rework the J2EE application section.  So far the J2EE section has grown over ten fold in size and the documenting of Tomcat containers is almost finished.  There is much work to be done yet on getting better information for the other containers and applications within them.  After that will be a rework on the apache vhost documentation.

A sample screenshot of magic documentation

Contegix has been hosting the initial meetings of the Gateway Groovy Users, a group dedicated to Groovy and Grails.  The first two meetings were on the small side ( 6 people ) but they were productive.  Plans are underway for our first “big” meeting.

Contegix is the natural place to host a group for Groovy and Grails, since both of these open source projects are part of codehaus.org, which is hosted at Contegix.  Attendees to our meetings have the unique privilege of being in the hallowed halls that house the main source code repository of the tools they love!

If you are already using Groovy or Grails (or Griffon) or are interested in these technologies, please join us at our next meeting on Wednesday, March 11, 2009 at 6:30pm.  We will be having a presentation on developing desktop GUI applications with Groovy.  Then, for those who want to stay, we will be starting on a group project.  It promises to be a great learning experience and a lot of fun.

Hope to see you there!

Prior to the existence of Mod Proxy AJP being built into Apache HTTP we used Mod JK for any Tomcat based instance we hosted here. All of our Resin containers would use Mod Caucho, and all the Tomcat containers used Mod JK, and all was well in the world. We never had any significant complaints with Mod JK (Caucho’s another story for another day), other than it being a bit of a pain to setup, and it needing to be built from source. This created a situation where maintaining Mod JK was problematic, because it wouldn’t automatically be updated in our routine RHEL updates forcing us to manually rebuild for critical security updates. Then you added in the fact that the configuration files totalled in at three, with a mod_jk.conf, a worker.properties file, and the actually JkMount itself in the virtual host configuration, and you had yourself a maintenance headache. Not too mention the slightest of typos and a simple Apache reload turns into Apache going belly up like a poisoned whale.

Needless to say I suppose, when Proxy AJP came into our lives we as engineers were smitten. We were all quite familiar with ProxyPass, and simply swapping “http://” with “ajp://” to proxy to Tomcat containers seemed like the best solution we had ever seen. We were practically partying over the idea that we could finally ditch JK like a bad habit, and ride off into the sunset with our new ProxyPassing beast of a friend. The only downside is it required Apache 2.2, so our RHEL 5 boxes were all set, but the RHEL 4 boxes left us in the hands of old faithful, Mod JK. The ultimate question continued to linger though: Which would hold it’s own under high stress more effectively? In terms of average browsing, I don’t think you’d ever notice a difference, even after the tests I’ve done. The difference, to the human eye at least, is negligible. Nevertheless, I constructed a few test to put both through their paces.

Test Environment:

• Apache 2.2
• Tomcat 5.5.20
• Java 1.6 64 bit
• PostgreSQL 8.3.5 (tweaked for performance)
• Confluence 2.10.1

Test Tools:

• Pylot
• BrowserMob

To get the ball rolling I started with Pylot. This was a quick and free way to start some preliminary testing. My initial tests fired up a constant flow of 200 (virtual) users at the instance for 10 minutes to see what would happen. To my initial surprise, Proxy AJP was a pretty clear winner to start things off. It was able to serve 1-2 more requests per second, while serving an average response time of roughly 1 second better than JK. Surely that couldn’t be right, it couldn’t possibly be that easy right? Right, not that easy. With some adjustments to Mod JK, like giving it a connection pool, I was able to get the results from my tests with Pylot to average out to be roughly the same. Under constant pounding from 200 agents, both were able to average an average response time of approximately 8.3 seconds, while serving roughly 23 requests per second. I was pretty pleased with my test environment at this point, and ready to kick it up a notch.

We got in touch with Patrick from BrowserMob, which is a site that offers real load testing with real browsers. I was hoping that with his service, I’d be able to find distinguishing differences between the two AJP connectors for Apache. After crafting myself a script using Selenium, and testing it ad nausem locally, I was prepared for my first test against Proxy AJP. I ran a 15 minutes ramp up to 100 users, and then put a constant load of 100 users across 45 minutes on the new kid in town. Surprisingly, the throughput looked pretty incredible:

If you click the image you can get a better view of the results, and see that we topped out around 140MB per minute being served. You’ll also see that the ebb and flow of data being pushed out was incredibly spiky. There are numerous jumps up and down the graph as more and less intense pages are hit throughout the tests. At first this seemed a bit scary, because I somewhat expected a smoother line across the board. I left all configurations the same though, and proceeded to test Mod JK, where I received the following throughput graph:

In a side by side comparison (or for better results lay the images over the top), Mod JK suffers from similar, but less severe spikes. It never quite reaches the highs that Proxy was able to reach, and never dips to the lows the Proxy had succumbed to. However, there’s something else at play here that caused this to happen. Mod JK caused Apache to reach MaxClients, and hold fairly steady there. There were only 100 users, and there were 256 MaxClients available in Apache, so numerically speaking, Mod JK should have been able to handle this without cracking under the pressure.

However, since it was at max connections, it didn’t have the downward spikes that Proxy did, because it was still trying to serve past requests. At the end of the day, we saw roughly 630 timeouts from JK in the tests, with the tests timing out at 30 seconds. Yes, I could have cranked up the timeouts to allow every step to completely finish, but this is real world testing. When was the last time you allowed a page more than 30 seconds to load? Proxy AJP on the other hand only sufferred from 450 such timeouts, showing me that it was able to pump out requests, and break off connections faster than Mod JK. The way I currently see it, JK failed to serve 200 people. That’s 200 people that think my site’s down, or heaven forbid, a Google bot that is prepping to denote me as a downed site. That’s 200 requests I’m not able to serve advertisements on, and thus not able to make money off of. Might not seem like much, but it is a big deal to some degree.

Now it would be interesting to crank up the MaxClients, and see what happens in that scenario. However, I needed to keep parity between the tests, so they were both performed within the exact same scenarios. We can always do more tweaking, and make more adjustments though. However, at the end of the day, Proxy has a lot going for it. It’s a built in module in 2.2, configuration is insanely easy, balancing is a cinch, it works with the balancer manager of mod_proxy_balancer, it receives automatic security fixes via RHEL updates, and so far, it out performs JK. We plan on doing more tests with altered configuration in the future, so look forward to future rounds. Perhaps JK can make up some ground in Round 2? Perhaps you’ll also get some insight on methods to tweak your Confluence installation to squeeze a bit more performance out of it as well. Many updates to come…

As of late, Erlang (the functional programming language behind ejabberd and portions of Facebook) has been picking up steam and gaining some popularity. Recently, there was a question regarding Erlounge meetings in Missouri on the Erlang email list. I have personally been hacking around with Erlang for a few months and decided it would be the perfect time to start ErloungeSTL.

I am proud to announce the first meeting will be held at Contegix on September 11th at 7pm. There will be something for the seasoned Erlanger as well as the novice. The presentations/sessions should be interesting for anyone that has a background or interest in Erlang, functional languages, concurrent programming, or just programming.  More info can be found here.

All are welcome to come.  Contegix will be providing food and drinks to celebrate this first step.

We’re often asked at Contegix, “Do you perform automatic upgrades of Application XYZ?”, and are answer is always emphatically, “No”. This tends to spark some debate, since we do tend to perform RHEL updates automatically. First, let’s define “automatic”, because obviously we’re not shutting down instances/servers without explicit permission from you or your team. In regards to standard RHEL updates, we inform you after the updates have passed a rigorous round of testing and have both the Redhat and Contegix internal “go-ahead” that we need to perform updates on your servers. We consider these mandatory for the reasoning of security. Redhat doesn’t push superfluous updates down the pipe to your servers. They’re generally provided for very specific means, and the number one reason is security. We can push these updates because 99% of the time, the end-user (you) won’t even notice the difference in most cases. On the rare occasion an update may have an odd effect, but I’d like to stress that the case of that happening is excruciatingly rare.

Let’s compare this to… well, -any- web application you’re running right now. First off, keeping up with what’s running on every customer’s server is a massive chore in of itself. Keeping up with that list, and checking to make sure every web application is running the newest version is just a research nightmare. Obviously, the big applications (aka our managed applications) we’re aware of, such as the Atlassian suite of applications, Wordpress, Jive’s suite of applications, and so on. Unfortunately, keeping tabs on all the various web applications we use, and their version numbers, is a bit rough, but is something we plan on tackling in the future. The real problem however exists in the following question: “Do you really want to upgrade?”

The problem is that many applications have introduced the wondrous world of plugins into their applications. Honestly, from our side of the fence, plugins create a lot of havoc. For one, they’re not always supported by the main developers of the application in question, which leaves us restricted in the level of support we can offer to a product using them. Secondly, they make application upgrades comparable to a roller coaster where the cars may or may not come unhinged from the track, sending you careening into a brick wall. That’s not to say we don’t like plugins, because we love plugins. For instance, the Wordpress Automatic Upgrade Plugin turns Wordpress upgrades into a quick 5 minute ordeal. No need to worry about asking us to upgrade your Wordpress, take backups, and hope that we catch any theme changes that need to be made in the process. Instead, a few button clicks and this plugin will complete the upgrade in no time flat, bringing you to the latest version of Wordpress. I’ve used it on my personal blog a couple times now, and it worked flawlessly. Obviously, your mileage may vary, but if nothing else it performs backups before it does anything, so if the upgrade fails, reverting back is a snap.

Why on Earth would a Wordpress upgrade fail though? Plugins. It’s the same reason we have upgrade problems with any application we work with, plugins inherently create issues for upgrade procedures because they introduce new quirks that may fail when the core application is upgraded. Depending on how integral that plugin is to your application instance, this could cause an upgrade to become a complete failure. A default instance of Confluence/JIRA/Crowd upgrades smoothly, no problems to worry about. An instance of Confluence with a bunch of plugins, theme changes, and so on, however tends to be a bit more interesting. It’s not really Confluence’s fault, in fact it’s quite likely that weird plugin you were skeptical about installing is breaking something internally, thus causing the upgrade to fail. More often than not though, Confluence upgrades can fail due to heavy edits to themes, generally via the Theme Builder plugins. This causes theme anomalies, as the Theme Builder plugin is out of date, not functioning properly, and the changes in Confluence between versions have also contributed to some issues with your themes, such as in 2.8 when the theme was prettied up quite a bit (nice job Atlassian!). All of sudden, what should have been an easy, smooth ride, is now resulting in an extra half hour of down time as we scramble to fix the problems. Then we have to come to a decision on rolling back, or progressing through the issues.

This is why we generally frown on automatic upgrades, because plugins add a significant curve ball to the mix that we can’t foresee. If keeping up with every web application is a documentation job of epic proportions, imagine trying to track compatibility of plugins, the plugins installed, and the ones not installed on all customer Confluence instances! We like to keep downtime to an absolute minimum, which is half the reason you’re with us we hope, and that’s why we avoid automatic upgrades. Instead we encourage staging instances, scheduled tasks, and taking each upgrade on a case by case basis. Do you want us to merely say “Confluence 2.8.1 is out, and we’ll be upgrading you on MM/DD/YYYY at 00:00″? We believe it’s in everyone’s best interest for you to decide when to upgrade, and to let us know. We’ll work through the process with you, check compatibility/dependency issues, and set the event up for a time that suits your needs best. If you’d like to see it staged out first, that’s fine too, we’re more than happy to setup a small staging instance for the upgrade when necessary, assuming it’s not detrimental to the overall health of the server. We want to work with you, as much as we work for you and your company. If you have any thoughts or suggestions on our upgrade procedures, feel free to drop them in the comment box!