The Problem
I've spent the last week optimizing a lot of our JavaScript code at work. We rely heavily on jQuery there (a great framework!) and it's partner in crime jQuery UI for some of our UI widgets. Part of my optimizing including tracking down some of the memory leaks we've been seeing on the site with extended use, especially in IE (surprise!).After tracking down quite a few closures and fixing those up, I was still left with 10 meg leaks here and there. After a bit I tracked it down to every time we used a dialog from jQuery UI's library.
Our helper function was pretty simple -- allow the code to specify the title and the text, and optionally provide a callback function that'll be called with what they clicked to close the dialog. The dialog would pop up on the screen and gray out the background forcing the user to interact with the alert box. I was concerned because we rely on modals quite a bit, especially in the edit pages. A 10meg leak per dialog shown would quickly add up to 100,200,300+megs leaked over the course of a normal session.
I removed a lot of the surrounding code, making sure I wasn't leaking memory in my own code. I was left with a pretty simple use of the dialog use:
function AlertDialog(dialogTitle, dialogText, callbackFunction) {
// dynamically generate and add a div so we can create the pop-up
$('body').append("");
// define/configure the modal pop-up
$("#alertDialog").dialog({
draggable: false,
resizable: false,
modal: true,
buttons: { 'OK': function() {
if (callbackFunction != undefined) {
callbackFunction('OK');
}
//remove the default beforeclose event and trigger the close
$("#alertDialog").unbind('dialogbeforeclose').dialog('close');
}
}
}).bind('dialogbeforeclose', function(event, ui) {
// Close (X) button was clicked; NOT the OK button
if (callbackFunction != undefined) {
callbackFunction('cancel');
}
}).bind('dialogclose', function() {
$('#alertDialog').dialog("destroy").remove();
}).dialog("open");
}
Despite all my efforts I couldn't get the leak to stop. Simply opening the alert would cause it, so I figured it wasn't my callback function. Frustrated I changed the modal option to false. Bam, no more memory leak in IE! How could this be? So I tried playing around with the appearance of the modal in their CSS file. I tried setting the background property to a GIF instead of a PNG, since IE is terrible with PNGs, with no luck. I tried removing the opacity filter in the CSS with no luck too. Turns out it's just how jQuery UI generates the gray background behind the dialog that causes the leak.
The Solution
The solution was to never use the modal: true setting in our use of the dialog boxes. I instead wrote two helper methods that would be used to gray out the UI and block interaction with anything but the alert.
CSS:
#BlockUI
{
position: fixed;
display: none;
top: 0;
bottom: 0;
left: 0;
right: 0;
z-index: 600;
background: url(/Resources/grayout.gif);
}
JavaScript:
var blockCount = 0;
function BlockUI() {
blockCount++;
$('#BlockUI').show();
}
function UnBlockUI() {
blockCount--;
if (blockCount <= 0) {
blockCount = 0;
$('#BlockUI').hide();
}
}
With this I had a common method for triggering a grayed-out background effect. The GIF I used was a checker-board pattern one, alternating between a light gray color and a transparent pixel. One could use a solid PNG with it's alpha set to something around 50%, but I wanted IE6 compatibility. The difference between the two is minimal.
With that in place I just needed to update the dialog to trigger the block and unblock calls. JQuery UI's dialog lets you specify a function for the "open" option which will be called when the dialog opens.
function AlertDialog(dialogTitle, dialogText, callbackFunction) {
// dynamically generate and add a div so we can create the pop-up
$('body').append("");
// define/configure the modal pop-up
$("#alertDialog").dialog({
draggable: false,
resizable: false,
modal: false,
open: function() {
BlockUI();
},
buttons: { 'OK': function() {
if (callbackFunction != undefined) {
callbackFunction('OK');
}
//remove the default beforeclose event and trigger the close
$("#alertDialog").unbind('dialogbeforeclose').dialog('close');
}
}
}).bind('dialogbeforeclose', function(event, ui) {
// Close (X) button was clicked; NOT the OK button
if (callbackFunction != undefined) {
callbackFunction('cancel');
}
}).bind('dialogclose', function() {
$('#alertDialog').dialog("destroy").remove();
UnBlockUI();
}).dialog("open");
}
And with that the memory leak was fixed. It's not ideal to have to rely on custom-code to get around the leak, but until jQuery UI is fixed to avoid this it's the best work around to make sure IE doesn't bloat like crazy when you use modals.
The first Assassin's Creed was a major disappointment, I think few will argue that fact. The original largely boiled down to a game engine with lots of promise but nothing to draw you into the game beyond that. The repetition was mind-numbing, the plot was a joke. I never actually finished the game, I got about 2/3 of the way through it.
After the bad taste the first left in my mouth you can imagine by reservation when Assassin's Creed 2 came out. But this time I was not disappointed; instead I was finding myself unable to put the controller down. Assassin's Creed 2 is the perfect sequel: it took everything that was weak about the first and improved it.
What a difference a plot can make. The first one had a plot but it wasn't a personal plot. You were just a tool of a larger war between two factions being told to go kill boss X and Y. In between bosses they didn't even try to hide that you were doing the same thing over and over again. You always had ~9 smaller missions before the boss, which were always of the same type. In Assassin's Creed 2 it is actually personal and diverse. You start out not knowing a thing about Assassins or Templars (heck you spend most of the game not caring about that), you're just a guy whose family is attacked and you go after the killers in revenge (sweet stabby revenge). You're going around killing people because you want to, not because you're told to. And everything in between killing bosses doesn't feel like repetitive kill X, pickpocket Y, loot treasure Z. Sure it boils down to that in the end, but it doesn't feel like that at all. The game flows so well.
The asides from the plot are vastly improved too. If you find yourself wanting a distraction from the revenge-plot there is plenty to do this time around beyond just climbing around. You can help out in the cities with various assassination and beat-the-cheating-husband up style missions that reward you with money. Partway through you get your own villa which you can chose to sink money into. Doing so gets you the warm fuzzy feeling (also helps the place stop looking so run-down) but also makes upgrades cheaper as you spend money to upgrade your blacksmith. Plus as you upgrade your villa more and more it will start generating money for you every 20 minutes.
This money comes in handy as there is a full weapon and armor system in the game, finally. There are quite a few classes of weapons you can choose to carry around, from daggers to swords to maces, all of which cause you to fight a little differently. Along with weapons and armor there are plenty of little upgrades too, like additional medicine pouches and knife-slots that really help out later in the game. There are six Prince-of-Persia style jump-puzzles (Assassin's Tombs) you can do if you want the best armor in the game.
For the obsessive-collectors they kept plenty to do in the game that requires running around everywhere trying to find things. Most importantly you have hidden glyphs you can seek out (with small hints as to where in the cities they are) that help unlock something within the game. There are hundreds of treasure chests around the city, and a side-quest where you need to find 100 feathers in memory of someone in your family. You can try to buy all the paintings available as part of the side-quest to restore your villa to its former glory.
They added in a notoriety system for the second game. It tracks your notoriety per-city and really helps you gage how cautious you need to be around guards. And now there is finally a way to lower your notoriety if you care: running around ripping down wanted posters, bribing town criers, or killing city officials. And when you are running from guards they're a lot more intelligent with their chase, they'll actually look for you in hiding spots sometimes. This makes it feel much more realistic instead of just having them give up once you jump in some hay.
One can tell that they really learned from the shortcomings of the first game and made sure they didn't exist in the second. A complaint I had was the rebounding-off-walls controls. There were a few times it would have me jump off in a different direction then I was going for, but this really only showed itself during the more difficult jump-puzzles (the most inopportune time for it to happen). The combat wasn't vastly changed in the sequel, it was still a bit of well-timed button-mashing, but it didn't really detract from the fun of the game.
Without a doubt Assassin's Creed 2 was a wonderful game and well-worth the time I sank into it. It's what the first game should have been. I'm glad to see Ubisoft pull a 180 with this game and really produce something with such high quality. And fortunately it ends with a pretty cool twist leaving it open for a third (which they've already said will happen).
Recently I moved away from Apache and to Lighttpd for my web servers to better handle load, especially in a low-memory environment like a VPS. Resources were somewhat scattered when I was trying to get it set up the way I wanted it so I wanted to document the process.
Getting Started
This tutorial assumes you’re running Debian or Ubuntu. Most commands in this tutorial are going to require root privileges, so sudo or su to your heart’s content. Lets get started.
First lets get all the packages we’ll need for the install:
apt-get install lighttpd php5-cgi build-essential php5-dev bzip2
Note: at time of writing spawn-fcgi was part of the Lighttpd package, but in SVN was moved out to its own project. You might need to download the spawn-fcgi package (at this point I don’t know what its name will be, but do an apt-cache search spawn-fcgi and you should find it easily).
If you didn’t have Apache on your system previously, you’ll need to create a group and user for the various services to run as. I stuck with the default Apache one “www-data”.
Setting Up Spawn-fcgi
The standard configuration I saw referenced when setting up Lighttpd was to have it spawn off PHP processes as needed. Lighttpd would control how many processes were spawned, how many children each process supported, etc. With a minor amount of tweaking one is able to get a go-between set up between the PHP processing and the server. I prefer this set-up because then if something needs to change with your PHP configuration you don’t need to take down the whole web server. Plus, if you want to be paranoid, you can further sandbox PHP and have it run as a user independent from Lighttpd.
The first thing that has to be done is to create a script that will spawn off a Spwn-fcgi process with the appropriate arguments that we can reference later:
vi /usr/bin/php-fastcgi
#!/bin/sh /usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -C 5 -u www-data -f /usr/bin/php5-cgi
Save and close the file then you need to make it executable:
chmod +x /usr/bin/php-fastcgi
When this script is executed it will set spawn-fcgi to listen on the local IP and listen on port 9000. It will spawn off 5 PHP processes and have them run as the www-data user. You can tweak the port/user/number of children as needed. The one you might want to play around with is the number of processes; I found 5 to handle plenty of load (90k views in a day) within a 512meg VPS.
Now we need something to kick off this script when the server starts, and a way to restart it when we make changes. We’ll make an init script:
vi /etc/init.d/fastcgi
#!/bin/bash
PHP_SCRIPT=/usr/bin/php-fastcgi
RETVAL=0
case "$1" in
start)
$PHP_SCRIPT
RETVAL=$?
;;
stop)
killall -9 php5-cgi
RETVAL=$?
;;
restart)
killall -9 php5-cgi
$PHP_SCRIPT
RETVAL=$?
;;
*)
echo "Usage: fastcgi {start|stop|restart}"
exit 1
;;
esac
exit $RETVAL
Save and close the file and then run:
chmod +x /etc/init.d/fastcgi update-rc.d fastcgi defaults
This script will allow you to call /etc/init.d/fastcgi stop|start|restart like you would Apache/Lighttpd/Mysql/any other daemon. The last command ran, update-rc.d, will add this script to the normal startup scripts so when you restart the machine PHP is brought back online without having to do anything manually.
Go ahead and kick off the daemon now, we’ll need it for Lighttpd in the next section:
/etc/init.d/fastcgi start
Hooking Spawn-fcgi up with Lighttpd
With all the PHP work out of the way we can hook up Lighttpd now. Go ahead and open up it’s configuration file.
vi /etc/lighttpd/lighttpd.conf
First we need to have it load the fast cgi module. Find the module section towards the top of the file (you’ll see a bunch of “mod_xxxxxx"s) and make sure mod_fastcgi is in that list and not commented out.
Next we need to tell Lighttpd how to access the PHP processor, in our case spawn-fcgi. If you remember from earlier we set it up to listen on the local IP and port 9000, that’s all the info we need to give Lighttpd. So add the following to the bottom of the configuration:
fastcgi.server = ( ".php" =>
( "localhost" =>
( "host" => "127.0.0.1",
"port" => 9000
)
)
)
While you’re in here make sure you update the web root to point to where your site is currently living — probably /var/www.
Save and close and you’re done. Restart the Lighttpd daemon to pick up the changes:
/etc/init.d/lighttpd restart
Now you have a web server with PHP running. To test this create the following file in your web root and load it through a browser:
eAccelerator
Now that everything is running through Lighttpd lets get caching up and running using eAccelerator (similar to APC). eAccelerator provides post-compile caching of your PHP code which will greatly increase performance of your site. It’s one of the first things I lay down when I’m setting up a PHP install. As of writing the latest version is 0.9.5.3, make sure to check the homepage for any updates and use the latest version. It is a manual install, but goes very smoothly:
cd /tmp wget http://bart.eaccelerator.net/source/0.9.5.3/eaccelerator-0.9.5.3.tar.bz2 tar xvfj eaccelerator-0.9.5.3.tar.bz2 cd eaccelerator-0.9.5.3 phpize ./configure make make install
With eAccelerator installed we just need to configure it. Open up its configuration file…
vi /etc/php5/conf.d/eaccelerator.ini
And add the following to it:
extension="eaccelerator.so" eaccelerator.shm_size="16" eaccelerator.cache_dir="/var/cache/eaccelerator" eaccelerator.enable="1" eaccelerator.optimizer="1" eaccelerator.check_mtime="1" eaccelerator.debug="0" eaccelerator.filter="" eaccelerator.shm_max="0" eaccelerator.shm_ttl="0" eaccelerator.shm_prune_period="0" eaccelerator.shm_only="0" eaccelerator.compress="1" eaccelerator.compress_level="9"
Save and close the file. Anything you add inside the conf.d folder in the PHP config will automatically be loaded when PHP goes to run. Now you need to create the cache folder for eAccelerator (as specified the path in the configuration file you just created).
mkdir /var/cache/eaccelerator chmod 777 /var/cache/eaccelerator
And that’s it, eAccelerator is ready to go. Restart the PHP process:
/etc/init.d/fastcgi restart
With that in place you’ll see a dramatic difference in the number of requests per second your server can handle.
You can confirm that is it working by going back to the PHP info page you created above. Do a search for the string “eAccelerator” on the page and you’ll see a section on it.
Done!
And with that you have a working Lighttpd server in place of Apache, with PHP accelerator and everything. I’ll be taking this further with virtual hosts, server-side compression, how to replace .htaccess files, and content expiration in a future post.
Server load can be a hard thing to deal with especially when, in my case, your peak loads occur during only six days of the year. The server will hum along for the rest of the year without issue, no indication of the impending and inevitable doom just around the corner. Then your server gets Slashdotted, or in my case the Nike Outdoor Nationals happen.
Last year I migrated the NSSF server to a VPS with 512megs of RAM. VPSs are a great option for someone wanting some of the benefits of a dedicated box (root access, set it up as you see fit, etc) but doesn’t want to pay ~$250+ a month for the dedicated hardware.
But with the great freedom of a VPS or dedicated box comes new issues you used to not have to worry about on a shared/managed host.
During the last two meets we’ve been running into a problem — the high load of people refresh-monkeying for results and photos of their kids for two days was making the server choke (80k+ pageviews a day; nothing amazing but certainly not a light load for a single-server operation). At the first meet in March I spent the weekend learning about Apache optimization for high load and updating the server’s configuration to meet the swarm of parents and track enthusiasts descending upon our server. Of course the optimizations were bounded by the need to run within 512 megs of RAM, along a MySQL instance. We survived the storm, but the site’s response times weren’t ideal under that load.
It wasn’t until the second meet, held last weekend, that I got to realizing that maybe the solution wasn’t in tweaking Apache, but rather ditching Apache. Now don’t get me wrong, Apache is great and has been my server of choice for six years, but it is a beast. Apache is meant to do everything and because of that isn’t ideal for low-memory-footprint environments that come under heavy load. Yes, more RAM would help, but I’m not the kind of guy that just throws more hardware at a problem when I can do something to fix it. Open-heart surgery, not a band-aid that comes attached to an additional monthly fee, was in order.
I’d heard of Lighttpd before; the servers at Meebo run on it. It’s a very lightweight server that has a small footprint and runs wonderfully under very high loads. So during the first morning of the two-day meet, when Apache was crying in a corner just wanting people to leave it alone, I went about installing Lighttpd.
Within 30 minutes I had Lighttpd ready to go, hooked up using FastCGI for PHP, with the main site running within it on a test port. Usually one doesn’t switch things like this during peak traffic, but desperate times… I flipped the metaphorical switch and shut down Apache and brought Lighttpd up in its place on the public port.
Wow.
Even with only minimal tweaking to the configuration the difference in page response time was comparable to night and day. It felt like the server was under normal load even though we were at our peak traffic for the year! Plus the server went from 80 megs of RAM open with Apache running to 140 megs (which later went up to 200 megs with more tweaking) open with Lighttpd running. Small footprint indeed. A few more minutes of work and I had all the other domains and subdomains back up as well.
Lesson learned: don’t be afraid to switch from the norm. Sure, Apache is pretty much the standard when it comes to a LAMP server, but that doesn’t mean it’s what you have to stick with. In this case Lighttpd had what I needed most: performance, and it didn’t require me sacrificing any functionality I’d come to rely on with Apache.
In short: go see it. I went in with high expectations and wasn’t disappointed.
[Minor Spoilers]
Sure, there were a few plot holes (but, lets be honest here, that’s nothing new for Trek), and way too many lens flares, but it felt like Star Trek and that is really what mattered. And it was fun, something I think the franchise lost some time ago. It washed the bad taste of the last two movies and the last two shows out of my mouth.
The biggest complaint I’ve see so far has been with the use of an alternate universe to reboot everything. I really have to disagree with those who think it “pisses all over the original continuity” — I argue they went out of their way to acknowledge the original work. The movie didn’t just ignore the original work and do what it wanted (we already have one Mirror Universe, why not just make another?), it came up with a plot that allowed it to split off gracefully.
It was very fun, the actors portrayed the characters wonderfully (Scotty and Bones were awesome), and visually beautiful. And best of all it’s Nemoy-approved.
Looking forward to the inevitable sequel, which better have some bad-ass Klingons.