Slimming The Server
CommentServer 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.
Trek
2 Comments
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.
Semantically Delicious Address Form
Last time I went over my new pattern for forms. It's continued to serve me well so far, so I wanted to dig a little deeper into some more complex form layouts.
One input per line is pretty common for a form online. However it's not always the best-looking; sometimes it really improves the usability of your form to have inputs grouped together visually. A great example of this is an address form. Having one line per input (city, state, zip, etc) takes up a lot of vertical room and leaves for a lot of wasted horizontal space.
The layout for an address form I've decided on is above. It's good to leave plenty of room for address line 1 and 2 — they'll usually contain lots more information than any other field. City, on the other hand, is usually pretty short, as are the state, postal code, and country options. As such I've gone with grouping city and state on one line, and then postal code and country on the last.
The first two lines are simple, pretty much just follow the same formatting from the previous post (note I'm assuming the final CSS from last post is active):
<fieldset> <legend>Contact Information</legend> <ol> <li><label for="address1">Address<span class="error"> *</span></label> <div class="inputWrapper"> <input type="text" id="address1" name="address1" value="" size="50" /> <label for="address1">Address Line 1</label><br /> <input type="text" id="address2" name="address2" value="" size="50" /> <label for="address2">Address Line 2</label></div></li> </ol> </fieldset>
Pretty simple start. We're just having two inputs and labels within the inputWrapper div. One item I'm not 100% on: I have two labels pointing to the first address prompt. Both the main label, "Address:", and the label under the input, "Address Line 1", point to it. Not sure if there is allowed to be multiple labels per input, but in this case it's the markup I'm happiest with.
Anywho with the simple stuff out of the way let's think about the remaining items. At this point my paranoia sets in — I want to avoid floats if possible when dealing with multiple inputs on the same line to make sure floating doesn't get in the way later. So no wrapping each group (input/label) in a div and floating the divs. Fear not, there is an equally as simple way to do this.
We'll have two lines of items (per group): the inputs and then the labels. We can follow the same basic format as have previously, we'll just have to make everything inline and limit the width. With them inlined we can use fixed widths to ensure that the labels line up under the inputs as we want (note CSS is inline to keep this simple, you should bring it out into classes where possible):
<fieldset> <legend>Contact Information</legend> <ol> <li><label for="address1">Address<span class="error"> *</span></label> <div class="inputWrapper"> <!-- Address --> <input type="text" id="address1" name="address1" value="" size="50" /> <label for="address1">Address Line 1</label><br /> <input type="text" id="address2" name="address2" value="" size="50" /> <label for="address2">Address Line 2</label><br /> <!-- City/State --> <input type="text" id="city" name="city" value="" size="11" style="width: 200px; display:inline; margin-right: 30px;" /> <select name="state" id="state" style="width: 175px; display:inline;"> <option value="" selected="selected"></option> <option value="AL">Alabama</option> ... <option value="WY">Wyoming</option> </select><br /> <label for="city" style="width: 227px; display:inline;">City</label> <label for="state" style="width: 175px; display:inline;">State / Province / Region</label><br /> <!-- Postal Code/Country --> <input type="text" id="postalcode" name="postalcode" value="" size="11" style="width: 200px; display:inline; margin-right: 30px;" /> <select name="country" id="country" style="width: 175px; display:inline; "> <option value=""></option> <option value="CA">Canada</option> ... <option value="US" selected="selected">United States</option> </select><br /> <label for="postalcode" style="width: 227px; display:inline;">Postal / Zip Code</label> <label for="country" style="width: 175px; display:inline;">Country</label></div></li> </ol> </fieldset>
And that's it. Not too bad once you take a second to read over it. From here you can easily extend the pattern for any other multi-input group like first name/last name, etc.
Semantically Delicious Forms
2 CommentsI'm continually revisiting my XHTML markup to remove all the excess crud and try to get it semantically correct while keeping the markup flexible and stylish. I think I'm finally happy with the pattern I follow for form markup. Back in the old day you'd just wrap a table around the whole thing and be done with it. However using that method the markup doesn't actually represent the data; a form isn't a table of data. The table tag was just an easy way to get the page to look right. Now we have better ways.
Basic Form Layout
First lets start with the basic XHTML that will represent our form. Thinking about the basic structure you've got a list of fields with labels where order of these inputs is important. These are often grouped together into logical sets of inputs — one group on the page covering the account information, the next group covering the contact information, etc.
Pretty straight forward, right? So, following those concepts, the XHTML would look like this for a form with just two inputs:
<form action="/signup" method="post">
<fieldset>
<legend>Basic Information</legend>
<ol>
<li><label for="name">Name</label><input type="text" id="name" name="name" size="30" /></li>
<li><label for="dob">Date of Birth</label><input type="text" id="dob" name="dob" size="10" /></li>
<li><label for="gender">Gender</label><select id="gender" name="gender">
<option value=""></option>
<option value="female">Female</option>
<option value="male">Male</option>
</select></li>
</ol>
</fieldset>
</form>
Most of that markup should be familiar except maybe the fieldset and legend tags since they are often left out when people create forms. The fieldset tag groups a set of inputs together to show it is logically related and the legend is essentially a caption for that fieldset. In the past developers would perhaps use header elements in between groups of data to separate them. Doing it this way not only visually separates and groups the inputs but it also does so in the markup itself.
I'll repeat the fieldset/legend/ol group as often as needed on a page for different sets of inputs that belong together and I want visually divided on a page (contact info vs basic info, etc). Add an li for every input I need within a grouping.
Why ols and lis? I've seen other sites out there that prefer to use the dd and dt tags to define the list of inputs. I believe that the list tag more closely represents the data: there is no "definition" relationship between an input and it's label. The relationship is defined by the "for" attribute on the label; you shouldn't need to define the relationship beyond that.
Next we need to apply some basic styling to the form. Personally I prefer the labels aligned left with the inputs to the right. In addition I prefer the inputs lined up neatly going down the page. To accomplish this I started with the following:
fieldset {
margin: 0 0 20px 0; }
fieldset legend {
font-weight: bold;
font-size: 16px;
padding: 0 0 10px 0;
color: #214062; }
fieldset label {
width: 170px;
float: left;
margin-right:10px;
vertical-align: top; }
fieldset ol {
list-style:none;
margin: 0;
padding: 0;}
fieldset ol li {
float:left;
width:100%;
padding-bottom:7px;
padding-left: 0;
margin-left: 0; }
fieldset ol li input,
fieldset ol li select,
fieldset ol li textarea {
margin-bottom: 5px; }
Just a few basic things going on here. The fieldset and legend styling sets up how I personally like things to look — a 20px margin between fieldsets and in this case I have a dark blue legend at the top of each fieldset. The ol and li styling ensures that the default nature, indented with numbers, is ignored for the list leaving me to style is as I please. Then the label floating left with a margin ensures that all the inputs make a nice neat line going down the page to the right of the labels (170 pixels in, in this case). If you prefer to have the labels above the input instead of to the left you could just remove the float. Lastly the margin on the bottom of inputs ensures some spacing after the field.
One last part to tweak before the basic form is done. The above code will work perfectly if you have some kind of CSS reset in place. By default the fieldset element has a border and adds a padding around its conents. If you don't have a CSS reset in place (why don't you?) you'd modify the fieldset element in the CSS like so:
fieldset {
margin: 0 0 20px 0;
border: 0;
padding: 0;}
That markup leaves you with:
Descriptions and Required Fields
So that's the basic set-up, but forms are rarely that simple. One of the first items I wanted to add was a description for a field; just a little bit of text below the field to help the user out. Adding the text by itself after the input field results in an undesired look: the text will end up under the label instead of under the input. To combat this we need to add a wrapper element around the input and description and then make sure the entire element is moved to the right the appropriate amount. The changed XHTML and new CSS when adding a description to the Date of Birth field is:
<li><label for="dob">Date of Birth</label>
<div class="inputWrapper"><input type="text" id="dob" name="dob" size="10" />
<span class="note">YYYY-MM-DD</span></div></li>
form fieldset div.inputWrapper {
margin-left: 180px; }
.note {
font-size: 0.9em; color: #666; }
The "note" class is just a convention I use it to specify text that should be a bit more subdued than normal text. In the same vein I use an "error" class to denote error messages and required field markings. We'll use that to add the standard asterisks for noting the fields are required:
<li><label for="dob">Date of Birth <span class="error">*</span></label>
<div class="inputWrapper"><input type="text" id="dob" name="dob" size="10" />
<span class="note">YYYY-MM-DD</span></div></li>
.error{
color: #d00; }
The IE Factor
IE treats legends a little differently than all the other browsers. Most browsers, using the CSS and XHTML just written, will just put the legend above the group of inputs. IE will do that but not without adding it's own flair. It will intent the legend a few pixels. I prefer to have the legends and fieldsets to look as they do in all the other browsers:
To remedy this you need an IE fix in the header of your page:
<!--[if IE]>
<style type="text/css" media="screen">
legend {margin-left: -7px}
</style>
<![endif]-->
This will cause any IE browser to align the legend with the rest of the labels as opposed to indenting it a bit.
The Final Look With Markup
The form is now marked up and should be stylish in all browsers (even that pesky IE). The complete code for this markup is as follows:
...
<!--[if IE]>
<style type="text/css" media="screen">
legend {margin-left: -7px}
</style>
<![endif]-->
...
<form action="/signup" method="post">
<fieldset>
<legend>Basic Information</legend>
<ol>
<li><label for="name">Name <span class="error">*</span>
</label><input type="text" id="name" name="name" size="30" /></li>
<li><label for="dob">Date of Birth <span class="error">*</span></label>
<div class="inputWrapper"><input type="text" id="dob" name="dob" size="10" />
<span class="note">YYYY-MM-DD</span></div></li>
<li><label for="gender">Gender <span class="error">*</span></label>
<select id="gender" name="gender">
<option value=""></option>
<option value="female">Female</option>
<option value="male">Male</option>
</select></li>
</ol>
</fieldset>
</form>
And the CSS:
fieldset {
margin: 0 0 20px 0; }
fieldset legend {
font-weight: bold;
font-size: 16px;
padding: 0 0 10px 0;
color: #214062; }
fieldset label {
width: 170px;
float: left;
margin-right:10px;
vertical-align: top; }
fieldset ol {
list-style:none;
margin: 0;
padding: 0;}
fieldset ol li {
float:left;
width:100%;
padding-bottom:7px;
padding-left: 0;
margin-left: 0; }
fieldset ol li input,
fieldset ol li select,
fieldset ol li textarea {
margin-bottom: 5px; }
form fieldset div.inputWrapper {
margin-left: 180px; }
.note {
font-size: 0.9em; color: #666; }
.error{
color: #d00; }
SyntaxHighlighter 2.0
While working on some new posts I noticed that the ever so popular SyntaxHighlighter just released version 2.0. The new version eliminates my main grip that it required invalid XHTML to work. Previous versions worked by specifying the name of an element to highlight. The problem was the tag it used, PRE, wasn't allowed to have a name attribute. Now it uses a much more elegant solution through css classes.
Installed it on here tonight and it works very nicely. Fair warning this will probably cause some more code-heavy posts later.