The Frontier Group - Blog

Scaling memcached at Facebook

December 18th, 2008, by mhale

Paul Saab has written an interesting article about scaling memcached at Facebook. It looks like they’re doing some cool things over there.

We are a web development company and this is our blog. We specialize in building web applications with the Ruby on Rails framework. You can read more about our Ruby on Rails development or contact us.


Generating random data with MySQL

December 18th, 2008, by mlambie

I’m doing some modifications to a Copper installation for a customer that involved the addition of some new fields to their project table, namely CashContribution and InKind. They both track different donation types that can be made against a project.

I needed a quick way to populate some projects with dummy, random data, and here’s what I ended up with:

UPDATE Projects
SET CashContribution = (SELECT CONVERT(RAND() * 1000, UNSIGNED))
WHERE ID > 600;

This meant that I wasn’t looking at row-after-row of the same dummy data, and that the test system better represents the intended real-world use.

We are a web development company and this is our blog. We specialize in building web applications with the Ruby on Rails framework. You can read more about our Ruby on Rails development or contact us.


25 Tips for Better jQuery

December 18th, 2008, by aaron

Typically these types of “25 Tips To…” or “10 Things That…” style articles have a few good points but are filled with fluff. However the article 25 Tips for Better jQuery is full of great points that cover architecture, coding conventions, compatibility and performance.

If you are looking to get a better handle on jQuery and more importantly how to use it well, I haven’t seen many better places to start.

We are a web development company and this is our blog. We specialize in building web applications with the Ruby on Rails framework. You can read more about our Ruby on Rails development or contact us.


Handling Permissions for AJAX Requests

December 17th, 2008, by aaron

Again I have a website where a lot of data transfer is done asynchronously and a large amount of the presentation is done using Javascript. Different users have different access to features across the site, and I can’t just rely on hiding links given the data is a simple HTTP request away. Protecting this data on the server side has always been easy to me, but I’ve typically found building the persistent abstractions I like to have far more difficult on the client side. As per usual, it’s probably just another issue I haven’t spent enough time to get a grip on.

It’s possible technologies such as Prism and Gears will help with this in the future. Unfortunately, it is the present.

This time I think I have a solution that I’m pretty happy with though. On the server side it involves using the existing HTTP response codes to indicate to the requester what happened with their request. On the client side the ajaxComplete() event is used to handle these codes.

jQuery will automatically call the function you specify as your callback in an AJAX request if the request is successful, so I’m only interested in handling failures. At the moment I’m assuming that all of my calls use JSON for their data format, but the alternative is a case I can handle later if need be. Only do what is necessary right now is a great credo I think.

So here is my event handler, it’s very simple but the documentation on the arguments to the event are a little slight. The success() call just makes a call to the function specified in the original call, hence passing in an empty array, simulating no records returned. The code I’m handling is for 401: Unauthorized, which in this case is the truth. This code will be sent back when I determine that the user is trying to access some data they aren’t supposed to. HTTP codes handle the majority of cases you’ll run into.

(function() {
	if (typeof(jQuery) != 'undefined') {
		jQuery().ajaxComplete(function(ev, req, settings) {
			if (req.status == 401) {
				settings.success([]);
				alert('You have insufficient privileges.');
			}
		});
	}
})();

The server side code is simple, it’s just a matter of sending back the appropriate header:

	header('HTTP/1.0 401 Insufficient Privileges', false, 401);

This function is specified in a global include where part of the website uses prototype, I’ve been slowly integrating jQuery. Therefore the first thing I do is check if jQuery has been defined, if it has then I register my function as the handler for the ajaxComplete event. Since it’s declared globally this will happen on every AJAX call. If the response code is 401 then first I pass back and empty array to my success handler so that the little loading notifier disappears, and then I notify the user of the error.

It seems to be a trend lately, but again this is just a very simple idea but I hope it saves someone some hassle. I know I’ve searched high and low on the topic and haven’t found a nice generic solution.

We are a web development company and this is our blog. We specialize in building web applications with the Ruby on Rails framework. You can read more about our Ruby on Rails development or contact us.


Bench marking instead of bench warming

December 16th, 2008, by mlambie

In August of this year we deployed a series of new server and storage devices which we expect will carry us through to 2011. One of the negative side effects of this deployment was that all of the sites and services we hosted on the new hardware performed significantly better than on the old configuration.

I hear you ask “how is that a negative side effect?” It meant that I put off the investigation into bench marking and tuning our server platforms simply because the move to newer hardware gave us significant gains. I had planned on doing some configuration tuning and system refinement, but the sheer increase in processing power meant that I didn’t bother with it back then.

Today, however, I decided to investigate what the addition of a PHP opcode cache would provide, and I was very happy with the results.

I came across an issue with running APC, the opcode cache developed by Rasmus and other core PHP developers, alongside the Zend Optimizer. The two are incompatible so you’ll have to play favourites and pick one or the other.

Installation of APC is easy on Ubuntu. There’s many guides online, but I found this one to be the most succinct. You end up installing the following packages (note: I didn’t have build-essential initially and PECL couldn’t build the package because I was missing make):

mlambie@prime:~$  sudo aptitude install php-pear php5-dev apache2-prefork-dev build-essential

The installation of APC is easy via PECL:

mlambie@prime:~$  sudo pecl install apc

Then enable the module by creating an apc.ini file:

mlambie@prime:~$ cat /etc/php5/apache2/conf.d/apc.ini
extension = apc.so
apc.enabled = 1
apc.shm_size = 48
apc.include_once_override = 1
apc.mmap_file_mask = /tmp/apc.XXXXXX

I ran some benchmarks using Apache Bench. The results were very encouraging. I saw a reduction in the time per request fall from 91ms to 37ms (250% improvement). The volume of requests per second increased from 11/sec to 27/sec (245% improvement). Lastly, 98% of all requests are served within 639ms instead of 1165ms (182% improvement).

Each actual apache process saw a significant memory reduction too, from 26MB down to 20MB (almost a 25% footprint saving). When you’ve got multiple processes running the reclaimed memory adds up quite quickly.

I found the figures staggering, and the improvements are actual, real things that are visible when interacting with the sites and applications hosted on prime.

It’s fair to say that we more then doubled our performance, from a single server, simply by adding PHP opcode cache. If you’re not running one on your server, you might want to consider why.

We are a web development company and this is our blog. We specialize in building web applications with the Ruby on Rails framework. You can read more about our Ruby on Rails development or contact us.


Follow Us

Stay in the Loop

  • Enter your email address to subscribe to our mailing list. You'll get updates about our products, specials and bonus offers, and general behind the scenes news from our team.

Twitter

Newsletters

Alexa Rank

Testimonial

The boys at The Frontier Group are amazing! For such a relaxed and personable organisation, they have phenomenal technical ability and a rampant professionalism. They have customisable solutions for all of my IT needs and they always deliver, on time and beyond expectation.

They fix problems other service providers can't and they helped me get a critical section of my web site up and running 10 minutes after I emailed the request!

Alex Hyndman, Nexus Car Share.

Featured Project

Case Study - Caudo Group - www.caudo.com.au

Website

www.caudo.com.au

Caudo Machinery

Caudo Group engaged our services to redesign their outdated website. We sent our photographer on-site to capture the essence of their business and turned it into a stunning web design.