Getting busy

Without hestitation, I launched my “sandbox” Amazon EC2 instance with Ubuntu 12.04 x64 and jumped straight into SSH to install G-WAN. Installation was a breeze. Configuring G-WAN is a bit different than usual though, but 15 minutes of reading documentation later, I had it up and running on non-standard port 8888 (G-WAN uses port 80 by default).  Getting it running as a daemon took a bit longer, but in the end it was all running smoothly.

Then came the benchmarking. My initial tests involved simply reloading a small (~57KiB) image a bunch of time while watching `top` running in the shell. It didn’t take long for the problems to show up. Initially G-WAN didn’t give a peep. Using a single process with less than 1% of memory (Apache2 typically uses 1.5%-2% for each process and Nginx used ~0.5% per process); much better. CPU% remained at 0%. For a simple image request, Apache tends to show a short 1% peak whereas Nginx keeps a cool 0% as well.

Standardized testing methodologies

Trouble starts however, when I pressed the Shift+F5 (no client-side cache, please) a few more times. Memory remained low, but CPU%… wow. “Wow” meaning “jumping to 100% for a few seconds”. Quite impressive, though not of the right kind. For comparison, Apache2 just kept giving those small 1% peaks and Nginx, trusty old Nginx, still didn’t register any CPU%.

It wasn’t just CPU% though, the latency as measures by the Chrome browser’s excellent developer tools showed wildly varying numbers for G-WAN responses. Again, initially G-WAN performed an admirable ~45ms for that picture, but when hitting the F5 key some 50 times, I occasionally got responses of over 2 seconds. That’s two whole frickin’ seconds for a 57KiB image file! Shame! Apache2 handles the same image at right about 160ms each and every time. Nginx, as a reversal of G-WAN’s behaviour, starts out at ~150ms but quickly drops to ~90ms. Again, neither of these show any weird behaviour as far as CPU% is concerned.

20-20 hindsight

As I said before the fold, in hindsight I should have known. The benchmarks on that blog (which are the same shown in the documentation and frequently mentioned on their forum) are somewhat… “unworldly”. By now you’re probably thinking that a smallish image isn’t a very reliable real-world benchmark. Compared to the 100-byte text file with only ‘x’ characters that is the “official” benchmark, it is practically science! Shame! I noticed this before I started testing myself, so I guess that shame is on me.

For what it’s worth, I’ve also tried the “100 ‘x’” file, using the same hightly acclaimed “Hit Shift+F5 like a spastic” method. CPU% for G-WAN remained at a comfortable zero this time, but again, latency slowly increased. In this test, at it’s best G-WAN performed equal to Nginx at ~45ms and at it’s worst equal to Apache2 at ~75ms. Apache2 peaked at 1% CPU, Nginx again remained at zero. Also notable is that both Apache2 and Nginx performed consistantly and reliably.

It smells funny

I’m keeping an open mind. The only thing I changed in G-WAN’s configuration was the port number, and this may be responsible for it’s lacklustre performance. Also, the G-WAN site clearly states it was tested on Debian and CentOS. Ubuntu derives from Debian, but they are not identical. Another thing to note is that G-WAN is also capable of dynamic websites. Then again, so do Nginx and Apache2. All this does not bode well for G-WAN. Perhaps somebody should do some quality benchmarking. As for me, the G-WAN benchmarks take effort to point out how bad Varnish performs, so that’s what I’ll be testing next.

Update; please read the comments and addendums for more.

Addendum; Varnish

Okay, installing Varnish was pretty easy. Although they claim to support LTS versions of Ubuntu, their site lists only the Lucid (Ubuntu 10.04) repository. Thankfully it was just a matter of search and replace. Simply add “deb http://repo.varnish-cache.org/ubuntu/ precise varnish-3.0” to /etc/apt/sources.list and just sudo apt-get update, sudo apt-get install varnish. Some minor configuration later and it’s running on port 888 with Apache2 as a backend (Varnish is different in that it can’t serve files on it’s own; it needs a backend). The 57KiB files has consistent latency in Chrome of about ~60ms (faster than any) with small 0.3% CPU peaks and 0.5% of memory combined over two processes (oddly enough, as I expected it to take the full 256MiB I configured). The small ‘x’-file runs past at ~35ms with same CPU%/memory%.

Running with Nginx as backend (itself with Apache2 as backend) makes no difference whatsoever. That means there is no point in having Nginx sitting between Varnish and Apache2. Alternatively, drop Apache2 and use only Nginx, ideal for pure static content. It should also be noted that Varnish does not handle PHP files by default, some minor configuration lets it cache only specific file extensions (or vice versa). This lets you use Varnish for a dynamic site as well. With Varnish configured like this, it’d make a great load-balancer/reverse-proxy when used on a separate server (due to memory requirements).

Addendum; Partial G-wan redemption.

As commenter Bert so aggressivly pointed out, I made a mistake regarding the “100-x” file. I again compare G-wan and V+N (ruining a perfectly good evening) with both the “official” ab.c test file and a number of other files. You can read my full findings in the comments below.

The summary conclussion is that, for some files, G-wan does indeed perform quite well. Not quite as well as Varnish+Nginx (although it does have the benefit of a lower memory profile than Varnish), but a lot closer than in previous tests. For some other files, G-wan still uses an extraordinarily large amount of CPU to the point where it dramatically impacts it’s own performance as well as the entire server. The bad news is that I can see no pattern in which files are delivered fast and which aren’t.

Sadly this still makes G-wan a bad choice for a production server, though it does show promise for the future.
If it can perform (nearly) on par with Varnish+Nginx, it may have a bright future ahead of it.

1. Make a subdomain like normal using Plesk (I use version 9.2.3, but should be the same atleast for all Plesk 9′s).
2. Log in to SSH or FTP as root user (you can’t do this through the panel; shame on you, Parallels!).
3. Make a “vhost.conf” in the /conf directory in your subdomain. For subdomain “test.example.com” (assuming the domain is example.com) this would be “/var/www/vhosts/example.com/subdomains/test/conf” and the file would be “/var/www/vhosts/example.com/subdomains/test/conf/vhost.conf“. The vhost.conf file is an empty, plain text file.
4. Edit vhost.conf and insert a line for each alias. For example, alias “alias.example.com” would require the following line in vhost.conf:
   ServerAlias alias.example.com
   1. If you use SSL, you must make (copy) an identical file named “vhost_ssl.conf” in the same directory.
5. Log in to SSH.
6. Enter the following command in the terminal (obviously replacing the marked parts):
   /usr/local/psa/admin/sbin/websrvmng -u –vhost-name=example.com
   1. If you want to reconfigure all (sub)domains at once, you can use:
      /usr/local/psa/admin/sbin/websrvmng -a
7. Restart the server through the Plesk panel.

The Afterdark theme has mutated to become a flexible theme framework, where multiple similarly styled themes could be generated from a single “source code”. The first product of this is the new “Afternoon” theme, a bright and shiney theme with blue tones, for a professional but lighthearted feel intended for front-end use.

As with Afterdark, it’s a total conversion set of jQueryUI theme settings, form components HTML components and a number of common extra’s (still working on this). It’s not complete yet, but the core is growing stronger and more stable all the time.

Next step will be to extract more stuff out of the core source and into the “theme” configuration. Eventually the theme should be easily user-configurable from a web interface and be able to render any number of combinations of the style sets “jqueryui”, “html”, “form” and “extra”.

If anybody want to dare a “themeroller” type site even while this project is still under active developement, please contact me. If you’re an expert with CSS3 styling, in particular with Mozilla or Opera, your help might even be invaluable.

The location is still unchanged:

Demo: http://vanderlee.github.com/Afterdark/
Project: https://github.com/vanderlee/Afterdark

Afterdark delivers a complete style for jQueryUI driven sites, changing not only the look of jQueryUI components, but all layout including body and form elements. It is designed for admin backends but can be used for any purpose.

This update adds a little bit of Mozilla (Firefox) support and some fixes/additions for Webkit (Chrome/Safari). More importantly, it is now compiled from a .less file using LessPHP, making it much easier to support multiple browsers and keep style more consistent. LessPHP might also make it possible to influence colors/style in the theme, kinda like themeroller, but different.

It should be noted that support for styling of form elements differs wildly among different browsers, so Afterdark will probably look different on each browser. Ideally Afterdark will have some level of native support for  IE9 (and graceful degradation for IE8), Chrome, Firefox, Safari and Opera. Realistically it should atleast look “normal” on all browsers.

Demo: http://vanderlee.github.com/Afterdark/
Project: https://github.com/vanderlee/Afterdark

It looks like a proper jQueryUI themed component and feels like a proper PhotoShop colorpicker, so you get the best of both worlds.

My hope is that this plug-in will eventually become part of jQueryUI itself, in order to guarentee the best support and stability, but for now it’s still in active development.

This colorpicker already includes all the core features and should be stable enough for production (I’m using it for a production application myself), so give it a try!

Demo: http://vanderlee.github.com/Afterdark/
Project: https://github.com/vanderlee/Afterdark

For one the projects I work on, I needed a theme for the admin backend. Since the admin backend is pretty much for me to do with as I please, I wanted to give it a unique UI. Just because. The site will be jQuery/jQueryUI-based, so the obvious choice would be a jQueryUI themeroller-based theme. But those themeroller themse are just so boring; they all look the same, no matter how you change the colors.

Instead I decided to follow the route of the excellent Aristo (which we’ll hopefully use for the customer-facing UI) and Absolution themes; take a custom themeroller theme and manually overhaul it to look like I want it to. The demo page I borrowed from Aristo, I hope Mr. Brown doesn’t mind .

Since the theme was made in my spare-time I’m able to release it to the public with a Creative Commons license! I hope people will find this theme useful and release their own further modifications of it to the open source community; the jQueryUI community desperately needs more freely available non-themeroller themes.
Also; if you find any problems/fixes/improvements/etc. (in particular regarding browser-compatibility), please post issues on github or email me directly.

So it all boils down to common subexpression elimination (easy, since SynthMaker creates so many) and good ol’ cycle counting. I haven’t counted cycles since the 6510! Since most ASM programmers have the full set of SSE* operands at their disposal, which typically implements a specialized op for most of what you do, it’s hard to find a decent cycle chart; most people don’t need to bother.

Luckily, there are still some resources around. And since I hate to forget, here’s the best one I found: http://www.intel80386.com/simd/mmx2-doc.html
Yup! It’s supposedly for the 386, which didn’t even have MMX, but there you go! It’s not complete but good enough.

If somebody finds a better chart, let me know!

It’s easier to just demonstrate: http://blog.vanderlee.com/demo/shadowtext 

One important note is that it does NOT work on IE (anything upto and including IE9, last time I checked), because IE still doesn’t support CSS3 text-shadow. But it should work on every other normal browser. IE does have filters and some other tricks that kinda look like text-shadow, but catering to their ugliness simply wasn’t worth the effort for me.

Anyway… demo/instructions/download can be found here: jQuery.shadowtext.

p.s. ShadowText can use our jQuery.px plugin if installed. It’s not required, but having it installed allows you to use more unit types for various distances.

The situation

1. Add a function to Array.prototype. In my case this was handily provided by a third party plug-in in the form of an Array.prototype.contains() function.
2. Use jQuery to load some JSON array. (Haven’t tested it, but I think any array will do, not just ones created using jQuery, JSON, AJAX or any other specific method).
3. Iterate over the array using the For…In loop.

Seems innocent enough, but FireFox will also iterate over the contains() function, causing all sorts of weird problems.

An example

(Actual buggy code!)

$.post('fields.php'
	,	{	'action': 'get_fields'
		,	'listid': listid
		}
	,	function(json) {
			for (fieldid in json.fields) {
				$('#fields').append(getFieldHTML(fieldid, json.fields[fieldid]));
			}
		}
);

So… how to fix it?

Since I was using jQuery, the obvious fix was to just use $.each, which is a usually more convenient anyway. Here’s the same bit of code as before, but using $.each:

$.post('fields.php'
	,	{	'action': 'get_fields'
		,	'listid': listid
		}
	,	function(json) {
			$.each(json.fields, function(fieldid, name) {
				$('#fields').append(getFieldHTML(fieldid, name));
			});
		}
);

For a pure Javascript solution (but why bother if we’re already using jQuery?), the following should work as well:

$.post('fields.php'
	,	{	'action': 'get_fields'
		,	'listid': listid
		}
	,	function(json) {
			for (var fieldid = 0; fieldid < json.fields.length; ++fieldid) {
				$('#fields').append(getFieldHTML(fieldid, json.fields[fieldid]));
			}
		}
);

The benefit of this last solution is that only the line with the for(…) statement changes, but I think a similar problem to the one we were trying to fix might occur when iterating over an Object. I’d rather stick with jQuery and let the collective hivemind of developers prevent my bugs