As folks noticed on Thursday morning when we opened hotels, the website displayed errors for 5-10 minutes starting at 9 AM EST due to the rush of traffic that came in. This was due to a few factors, which I'd like to go into in technical detail below.
First, some raw stats:
Peak bandwidth: approx 3.6 Megabits/sec
Peak connections: 1,060 concurrent connections
Number of users logged into the site: 100+
Here are some graphs that show just how big those numbers are, compared to normal traffic levels:
For those who saw last year's post about the load on the webserver when we opened up hotels, this year's traffic was about twice what last year's traffic was. I didn't see that coming.
As is plainly visible in the traffic graph, the machine that this website runs on is capabale of much higher bandwidth throughput. So, what happened?
In a word: caching. Or rather, the lack thereof in certain cases.
Earlier this weekend, I began work on a new Drupal module: Fivestar Stats.
Right now, it does the following:
I have more features (and screenshots!) planned, but this is just the start.
Fivestar Stats can be downloaded from:
http://github.com/dmuth/fivestarstats
Enjoy!
Earlier today, I performed a major Drupal upgrade on another site that I run. Part of the upgrade involved me installing the Advanced Forum module to bring the forums a little more up to date with other sites that are out there.
Along the way, I learned something interesting: the Author Pane module does NOT display on blog posts.
It looked rather odd when comments on the blog posts had detailed user info, but the post itself did not. So I set out to fix that. I ended up commenting out the line print $picture; in node.tpl.php and instead adding in these lines:
$account = user_load($node->uid);
$template = "advf-author-pane";
$author_pane = theme('author_pane', $account,
advanced_forum_path_to_images(), $template);
print $author_pane;
The code is fairly straightforward. It loads user info on the author of the post, and the theme() function loads the author_pane template, passing in the user data.
Enjoy!
Wow, it's been awhile since I've written here. Real life has had me very busy lately. I've done some neat things though, and I hope to post more about them soon.
The first neat thing I did recently was to roll out some badly needed updates for the user pages on anthrocon.org.
Before, I merely used the default pages that Drupal provided. The problem was that the pages looked a little... bland. Among other things, there were no icons for the various social networking services, and that just wouldn't do. So I read up on how to customize the user profile layout in Drupal and spent a couple of evenings writing some PHP code and making use of Drupal's theming functions.
Here are the old and the new pages side by side. Click on either to get a full page in a separate window.
| Old and busted: | New hotness: | |
|---|---|---|
|
|
The upside of this effort is that when I'm ready to upgrade the Save Ardmore Coalition site to Drupal 6, I can pretty much just copy over my user templates on a wholesale basis, and save myself from having to redo all that work. :-)
Looking back after this morning's stampede, I thought I'd share with folks how the webserver held up, since I know I am not the only geek out there. And, truth be told, I was a bit nervous myself, since I wasn't quite sure just how much traffic we would get and if the webserver would survive, or turn into a smoking crater.
Well, here's what we got:
The first hump is a manual backup I did last night. The second is the automatic backup that runs every morning, where the database and files are rsynced to a machine at another data center. The third hump at 9 AM was when we opened hotel reservations. 1.4 Megabits/sec doesn't look too bad, until you look at:
The 336 simultaneous connections a second was far more interesting. That's about 16 times the normal number of connections to the webserver.
So, what were the effects? Let's look at MySQL first:
While using the nginx webserver with a Drupal installation I noticed something odd. Whenever I submitted a form (with the GET method) or clicked on a link that had a space in it, it would be converted to a plus sign in the URL. Actually, that's not the odd path--the web browser is doing proper URL encoding since spaces are not allowed in URLs.
The weird part is that after the request got to the webserver, and the server processed it and passed it to PHP, and PHP loaded Drupal and executed the PHP code, the plus sign failed to be turned back into a space when using the nginx webserver. Works fine in Apache, but not in nginx.
The symptom is that if I tried to perform a search or edit my user profile, or anything else that involved a plus sign in the GET data, when that data was processed by PHP, the plus sign was still there. i.e., I would see "term1+term2" in the search box, instead of "term1 term2".
So, how to fix this? I could have spent some time reading RFCs, and looking through the source from PHP and nginx, or I could have my site working again. I opted for the latter, and found that this line of code at the very beginning of Drupal's index.php seems to do the trick:
$_GET["q"] = strtr($_GET["q"], "+", " ");
It's silly, and may even be a bit stupid, but it sure does the trick.
This part of the site contains software that I have written over time. Everything here is available under the Gnu Public License (GPL).
Newer stuff:
Older stuff: