Wow, has it really been five months since I last posted here? Somehow, it’s not hard for me to believe. I’m breaking the blog silence proseletize the newest tech frippery I’ve become enamored with: Sass.
Sass is compiled CSS. It fits in with the current (kind of stupid, in my opinion) trend of taking a language or syntax that doesn’t need compilation, then adding a compilation step in order to get some syntactic sugar. Coffeescript is another example. Sass is a Ruby program that will sit in your CSS directory, scan your .scss or .sass files, then spit out .css results. With these sorts of things, you have to decide if learning new syntax will save you time later on.
I’m doing some CSS work for the first time in about a year, so figured I’d give Sass a shot, because I’m bored out of my mind, and need to do something to keep myself entertained. After working with it for about an hour, I was pretty much converted.
The main benefits I see to Sass are the nested syntax, mixins, and variables. With it, you can write CSS in a “nested” fashion, similar to how your HTML document is arranged. It makes it much easier to scan a block of Sass to see what style corresponds to what HTML element. An additional benefit is that copy/pasting large blocks of CSS is now possible, without having to remove or change the top level selectors for a rule. I’ve been able to create whole new page layouts extremely quickly using this technique.
Mixins and variables are just extra bonuses. Instead of having to write a bunch of vendor prefixes for box shadows or gradients, I can create a
box-shadow mixin that can then be included in every rule that requires that style. Variables are great, too: you can just define a
$text-color variable, then refer to it easily later without having to memorize an arcane hex value.
Most people know that you can drag tabs out into their own separate window in Safari. But did you also know you can combine them again? Yep, just make sure that the tab bar is set to always be displayed (Shift + Command + T) and then you can drag tabs from one window to another easily. If a window only has one tab, it’ll disappear when you move the tab to the second window. Jawesome!
(Also, Command + Click opens links in a new tab. When I had a scroll wheel mouse, I used the wheel click to open/close new tabs, but since I’m Magic Mousing it up, I’ve had to drop that habit.)
Hey web developers, check this out. I’ve been using IE8 recently to do cross-browser testing, and have been using the “compatibility mode” to simulate IE7. Well apparently you can lock IE8 into running a specific mode by using the developer tools (Tools > Developer Tools). Kinda nice if you want to focus on a particular browser, but then again you have to remember which one you’re using.
If you’ve been following along, you’ll know that JMeter is most commonly used to do automated testing; you can create a bunch of virtual users to perform a set of pre-determined actions on your website. In my previous post, I detailed how to manually create a list of actions for your test users to perform. However, manually creating long lists of test actions is kind of a pain! Fortunately, JMeter includes a proxy utility that can intercept your browser requests and store them as user actions.
Fire up JMeter, and you’ll be presented with a new plan. Create a new thread group (your users) in the Test Plan (as detailed in the previous tutorial). Now, instead of manually adding HTTP Requests for these users to perform, we’ll hook up a proxy server to create the HTTP Requests for us.
Right-click on the WorkBench item in the sidebar, and select Add > Non-Test Elements > HTTP Proxy Server. You don’t have to configure anything here, just click the Start button at the bottom of the config window to start the proxy server on port 8080. Now you’ll have to configure your browser to pass its’ requests through the proxy server. In Mac OS X, you do this system-wide by accessing your System Preferences. Go to System Preferences > Network > Advanced (the “Advanced” button is in the lower-right corner of the window). When the advanced options window pops up, click the Proxies tab, then check the Web Proxy (HTTP) option, and change the Web Proxy Server port to 8080. Click OK to save your changes, then Apply to make them take effect.
Next, open your browser and go to the JMeter homepage (http://jakarta.apache.org/jmeter/). Click a few links, and then go back to your JMeter window. There should now be an arrow next to your thread group, meaning that the group contains some actions. Click the arrow to expand the list, and you should see requests for all the resources that you requested in your browser. You’ll see that requests have been made for every resource your browser asked for, such as images and CSS files. You can remove those requests if you want, or leave them in for a more realistic simulation.
Don’t forget to go back into your Network settings and disable the proxy server, otherwise you won’t be able to make HTTP requests when you close JMeter. However, this method of creating JMeter test cases is way easier than its’ manual counterpart.
Recently for a project at work, I was tasked with doing research into load testing software. Now, there are tons of options for load testing; in my search I found some nice-looking hosted solutions, such as browsermob.com. But of course, if you can get away with doing something for free, that’s usually the option that makes the most business sense (that is, if the time you invest in learning the free tool is less than the money you would save by using the easier solution). The free solution in this case is JMeter, a Java-based program maintained by the Apache Foundation. Since I gained a basic understanding of the software through my recent research, I thought I’d share a bit here on how to create a basic load testing script. JMeter has many more options that what I’ll detail here, but hopefully this tutorial will at least get you over the initial learning curve.
Obviously, first of all you should download JMeter. Unzip the downloaded package, and place the whole folder structure somewhere easy to remember. If you want, you can set the /bin directory on your path so you can start the program from the command line. I just double-click the ApacheJMeter.jar package to start the program.
After JMeter starts up, you’ll be faced with a totally blank slate. What we want to do is create a group of users, and have each of those users perform a certain sequence of actions (such as access a URL, post a form, or whatever). There are two ways to do this with JMeter: enter the sequence by hand, or configure a proxy server to intercept your browser requests and save them as an action sequence. If the list of actions you want to perform is complex, it might be a good idea to set up a proxy. I’ll show you how to manually set up your test; running the proxy server will be reserved for a future post.
First, let’s rename the test plan to be something more descriptive. Click on the “Test Plan” text in the project sidebar, and rename it to something descriptive, such as “My Jawesome Test Plan.” Now, the first step in creating your test scenario is to make a group of users. Right click on your test plan, then select Add > Threads (Users) > Thread Group. “Thread Group” is kind of a confusing term, so you can rename the group to “Users” if you want. When you click on your user group in the sidebar, you’ll see there are various options you can change about it, the most significant being the number of users, how fast they start performing their tasks, and whether they repeat their tasks. Change the number of users to 10, and the ramp-up period to 10 as well. That means that it’ll take 10 seconds for all the users to be activated. Since there are 10 total users, that means that one will start up each second. Change the loop count to 2, so that each user runs through their tasks twice.
Next, we’ll add some configuration options to the test, so that you don’t have to enter certain info each time you want to add an action for the user group to perform (such as the base site URL). Right-click your user group and select Add > Config Element > HTTP Cache Manager. This simulates a browser cache for each of your users, so if they download a static resource on the first test run, they’ll have a cached version for the second, making the test more realistic. Select the user group again, right-click, and choose Add > Config Element > HTTP Request Defaults. You can put in any default options you want here, such as the site name, port number, and path. So for example, if you were testing your site foo.com, you could put in “http://foo.com” as the server name. Then all subsequent requests from your users would use that information. If a user requested plain ol’ “bar.html,” the defaults would be prepended to that request, resulting in a request to “foo.com/bar.html.” When creating a test by hand, the Request Defaults configuration becomes very useful. For our example, let’s query the JMeter site, so in the HTTP Request Defaults options, enter “http://jakarta.apache.org” as the server name.
OK, we’ve got the test users all set up. Next, let’s have them try to make some requests. Right click on your user group in the sidebar, and select Add > Sampler > HTTP Request. This represents a request for a single page or resource on your site. Let’s have it request the JMeter homepage. If you remember, we already set up the default site URL and path, so the only option we have to change for the sampler is the path value, which we’ll set to “/jmeter/index.html” (for the homepage). Also, change the name of the HTTP Request to “JMeter Homepage” so that it’s easier to see what it’s requesting.
At this point, you’ve got enough set up to actually run the test and see real results, but let’s go ahead and add another HTTP Request to the test. Right-click your user group, add another HTTP Request, and set the path to “/jmeter/usermanual/index.html.” Rename this request to “JMeter User Manual.” Now the test is completely set up, but there’s no way to view the test results yet. To remedy this, we’ll add two “listeners,” which track results and display them in a human-readable way. Right-click your user group, and select Add > Listener > Graph Results. Also Add > Listener > Summary Report. These are two simple listeners that show your results in a graph and text-based summary.
Now, go ahead and run the test by choosing Run > Start (or Command-R). Wait for a bit for the test to finish, then click on your results listeners. You should see the (hopefully successful) results of your test. Now for some embellishments. In a more realistic scenario, users would load a page, read it for a few seconds, then click a link to go to a different page. In the test script right now, your users make requests as fast as they can. To insert a random delay between requests, right click each HTTP Request in the sidebar, and choose Add > Timer > Uniform Random Timer. This timer allows you to set a base constant delay (such as 2 seconds), and then add another random delay on top of that. I like to have a 2 second constant delay and a 3 second random delay, so go ahead and edit both timers to have values of 3000 (random) and 2000 (constant). Also, ideally we want to make sure that the results of each request were successful. There are a number of ways to do this in JMeter, but the simplest is to make an assertion that each request returned a HTTP status code of 200. Right-click each of the HTTP Requests and choose Add > Assertions > Response Assertion. Modify each assertion to check the Response Headers, choose “Equals” for the Pattern Matching Rules, and add “200″ as a Pattern to Test. The Response Assertion is very powerful… you can modify it to check for patterns in the HTML of the requested page, etc., but this basic assertion is enough for our needs right now.
And that’s it! You now have a fully functional basic test plan. You can run it and see a cool graph of response times as well as get the summary report for the whole test. Hopefully that will get you started with the wonderful world of load testing.