Archive for May, 2009

Server Control Panel Comparison

Friday, May 22nd, 2009

Control panels are used to configure and maintain servers by both system administrators and users.  Years ago all the server settings for web, e-mail, name service, and other packages were done manually by system administrators.  Nowadays there are powerful control panel packages that configure the settings based on relatively simple interfaces.

We have experimented with several Control Panels for our Gorges servers.  This blog post is not intended to be an exhaustive list of all control panel software, but rather a summary of our own experiences.

PLESK and CPANEL

These two solutions are terrific, and they present the obscure settings needed to control web/e-mail/etc. packages in a meaningful way.  The biggest drawback is the price.  At Gorges we run our servers “lean” with relatively few customers per server; this maximizes the web page performance.  Adding a commercial control panel to our servers would be costly and our hosting fees would have to rise perhaps unacceptably.

We do not host all the web applications we develop, and we often work with Plesk and CPanel on customer-supplied servers as well as one of our own.  These packages work, but for hosting companies to justify their cost they either overload the servers with domains or use virtual machines to squeeze more clients onto each server box.  You get what you pay for – and it can be truly frustrating when your domain is hosted on a server that has other customer domains saturating the bandwidth and processors.

WEBMIN

Webmin is perhaps the simplest of control panels, and basically just adds web page interfaces for packages.  We used this for a while, but the settings were so low-level that one had to be a system administrator to understand the screens, so the improvement was only marginal since most savvy sys-admins know the text interface already.  The companion package Usermin was perhaps more useful to the customer since it is for configuring e-mail accounts.

VHCS2

We have VHCS2 installed on most of our production servers.  This decision was made almost five years ago, and it took months to both learn all the nuances of how it works and to develop some custom solutions for important-but-missing features such as name service records and backups.  Although we liked VHCS2 at the time, work on this open-source package has apparently stopped, so it is stuck in time while better control panel software has surpassed the supported VHCS2 features.

ISPCONFIG

When we purchased several 64-bit quad-core servers in late 2007, we reviewed available control panel solutions.  The package ISPConfig was selected since it appeared much better than other control packages and was under open source license (i.e. free for us to install and use).

ISPConfig is not without problems, but we have extended this control panel solution with custom patches for grey-listing and spam filtering, propagating domain name service (DNS) records to our production name servers, and integrating it into our system-wide backup.

SUMMARY

Perhaps the biggest drawback of all control panel solutions is that it is not easy bypassing the panels and doing custom configurations for special-needs clients.  It’s pretty obvious that labor costs much more than hardware or bandwidth nowadays, so automating as much of the account setup and maintenance is the key to staying profitable.

As for us, we’ll keep using ISPConfig and passing the cost savings for hosting back to our customers.

Matt Clark worked in academia, corporate research labs and several technology startup companies prior to GORGES. His expertise is software architecture, database development, and system administration. Matt brings GORGES over 25 years experience developing fast and robust software on a multitude of platforms and languages.

When to Optimize Code for Performance

Monday, May 4th, 2009

Question:  When should a web developer optimize?

Answer:  When you have to improve the performance.

Of course writing bad or inefficient code is not a good way to develop code.  But spending time optimizing code before you know there is a problem can be a waste of time.  I value legible and readable code over unnecessarily-optimized code anyday.

If a web page or certain feature is too slow, then diagnosing exactly where to optimize is appropriate.  Here are some things to consider and test:

Is the bottleneck in the code or within a database call?
Perhaps the database needs to be indexed or normalized.
How many SQL calls are being performed?
Caching the database calls may solve this issue.
Is a database the best solution for storing all your information?
LDAP or memcache are two other options that may work best depending on what you are trying to do.
Are your files and images just too big?
Be sure the images are appropriately compressed, and that server-side compression for text files (HTML, CSS, JavaScript, XML) is activated.
Could any of the heavy logic code be pre-computed?
I recall one project (Straight Line Performance Solutions) where I pre-computed a big table of possible values from a complicated statistical function, and just looked up an approximate number quickly instead of spending 5-10 seconds computing the exact value.
Are you using a bloated CMS (content management system)?
If you are and the web pages are static, then a page-caching system will work wonders.
Is the server limited by bandwidth, RAM, or CPU?
Monitor server performance indicators to see if  there is too much disk thrashing.  Hardware is relatively cheap nowadays, and may be a better solution than spending days unsuccessfully tweaking code.
Does the page feel like it loads fast enough?
Perception is everything to a web user.  Some non-essential web page items could be changed to load a few seconds after the visible part of the web page is loaded and refreshed.  For example, there’s no reason to preload all images in a Javascript-based slide show.
Is there just too much traffic to your site?
Wow – what a great problem to have!  Maybe it’s time to scale your web application to multiple servers or host your application in the cloud.  There are sometimes session-management issues when using multiple web servers, but some real smart folks have figured most of this out for the major languages and popular frameworks.

There are only some ideas of what to look for – and I’m sure I missed a bunch of simple ones.  As you can see, I recommend spending time diagnosing the real problem before jumping in and optimizing code right away.

I’d rather have a correct program than a fast incorrect one.  Optimizing code when needed is better than having to debug faulty code.

Matt Clark worked in academia, corporate research labs and several technology startup companies prior to GORGES. His expertise is software architecture, database development, and system administration. Matt brings GORGES over 25 years experience developing fast and robust software on a multitude of platforms and languages.