No matter the site, the traffic, the scope or content, a tip of the hat should always be gestured to the scale it needs to support. Not to say any effort should be put forth to make it the most scalable site or webapp in the universe, but certainly a little thought is allowed. Of course, I’ve said plenty of times before and will continue to: don’t fall into the trap of premature optimization. It’s dumb. And in most cases, developing to solve existing scalability issues is a business case most people are willing to take as it will (generally) save time, money, sanity and morale in the long run. Regardless, I also believe there are simple simple steps everyone setting up a site can take. Not as a premature optimization, but as a logical, default method of installing your web tier to ensure it’s optimized out of the box. Particularly when it’s combining different pieces of proven technology and enabling their features to prevent needless overhead, it’s no longer premature, it’s simply expected.
Posts Tagged: sysadmin
16
Apr 10
Extensible Shell Environment Across Your Servers
One of my biggest frustrations any time I move to a new server: migrating to a new data center, changing jobs or simply adding new servers somewhere in between is keeping my customized shell environment while giving each server a bit of customizability. Of course, in a linux environment, we have our coveted .bashrc that will do this. But what has helped me through this process time and time again is building my .bashrc to allow for server-specific extensions. Here’s how I’ve done it. Continue reading →
19
Aug 09
Avoiding Latency when Using 3rd Party Widgets and Plugins
Anyone maintaining a site, blog or similar at some point has been tempted to add a widget or plugin provided by a 3rd party source. Twitter, Digg and ShareThis are just a few examples of sites that provide code and/or plugins (widgets) to help provide some level of dynamic and valued content. Although each of these can be incredibly useful (at least I think so as I’ve installed the Twitter WordPress plugin on this blog), they implicitly add page-rendering dependencies to your site as anyone who visits waits around for their code to load. Generally, this isn’t all that big of a deal as most of these sites have incredible uptime. But then there are sites like Twitter who seem to have some serious issues of staying alive. Particularly with plugins for content management applications like WordPress and the like, you have very little control into where the source will be loaded in the document and without any intervention, a staggering Twitter will throw your site into a tail-spin of foot tapping until your visitor’s browser finally gets fed up (after 30 seconds or so) and gives up the download. In the meanwhile, expect that person to not only leave your site but likely never come back. Not exactly what you’re looking for. Personally, I got fed up with Twitter’s lack of reliability, killing my load times and losing visitors. Luckily, if you are using a modern web server and you have access to modify the configuration, there is a simple patch you can apply to pull the reins back in and gain control of your own site performance. The example below is a patch you can apply to the Apache HTTP web server config although can be cross-ported to any of the other modern web servers that support Proxying.