Workaround for Kubuntu 8.10 (Intrepid) problems with “.local” DNS addresses

October 18, 2008

I installed Kubuntu 8.10 (Intrepid) Beta on one of my Workstations at work this week and I had really problems to get into the internet. Why? We have a PAC (proxy auto-config) script for our proxies and that PAC is reachable under http://pac.companyname.local (You put that into your Browser.). The problem with this setup is that somehow Kubuntu has problems resolving the .local DNS Zones. I did following as a workaround:

$ sudo vim /etc/nsswitch.conf

Replace:
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

with:
hosts: files dns

I hope Google helps others to find this post fast, so they don’t need to search that long for a workaround.

Mini Howto for JMeter, an open source web load testing tool

October 4, 2008

In this post I describe in short how to make your first steps in JMeter. I found JMeter when I wanted to test how stable a new written web application was and searched for a tool that allowed me to record my browsing and rerun it multiple (and parallel) times. JMeter is quite pretty easy to get up and running and it’s quite fun to test and break things on your own server.

As JMeter is a Java application the installation comes basically down to extracting the zip/tar.gz file and start bin/jmeter.sh or bin/jmeter.bat, if you’ve setup your Java correctly.

So now to the actual howto:

Start Jmeter by changing to jakarta-jmeter-2.3.2/bin and executing ./jmeter.sh You’ll see following screen:

First we add a “Thread group” to the “Test Plan” via right click onto “Test Plan” as shown in following screenshot:

After this we add an “HTTP Proxy Server” to the Workbench (as “Non Test Element”) to capture the traffic between your browser and the web site to test. Following screenshot shows how to add the proxy server.

Open the “HTTP Proxy Server” page and change the port if required and set the “Target Controller” to “Test Plan > Thread Group” on the same page.

Now configure your browser to use the Proxy Server (127:0.0.1:8080 in the default settings) and go to bottom of the “HTTP Proxy Server” page and click the “Start” button. Make also sure that you deleted the cache of your browser or even better deactivated it for the test. Otherwise you will not see the full traffic a new visitor would generate.

Now, JMeter will record all the HTTP requests your browser makes, so make sure you have closed all the other tabs you have open, otherwise you will get a mixture of Ad’s and AJAX requests recorded as well. After you did click through the workflow JMeter show test later you click the “Stop” Button and take a first look what JMeter has recorded for you.

Delete any request that you don’t like by right clicking onto the node and selecting “Remove”. Now we’ve recorded everything we need and we wand now to simulate a typical user. For this we want a time delay between the various http requests and the delay should not be fixed. If you want to query the server as fast as possible to you don’t need this step. We add therefore the Gaussian Random Timer as shown in this screenshot:

The last thing we need for a first test run is a Listener which tells us what worked and what not. We use for this “View Results Tree”. This Listener is not good for later use when you want to hammer with multiple threads onto the server.

Now we’re ready for our first run, the default settings are fine (in the Menu: Run > Start).

You should get something like this:

This Listener is good for testing your test setup, as you can look at request and response data. Now it would be the time to add an “Cookie Manager” or “User Parameters”. The First you need if your site requires cookies and the second is handsome when you want different threads to use different user/password combinations to login, as one use can only login once at a time.

After you verified the setup you should disable the “View Results Tree” Listener and choose something like “Aggregate Report”. Change now the settings of “Thread Group” do your likings and hammer your web server. 😉

If you are running a big load test, remember each Listener keeps a copy of the results in memory so you might be better running a Listener > Simple Data Writer instead which writes the results out to a file. You can then read the file in later into any of the reports.

Have fun hammering your web server 😉

ps: Always start with a smaller load, you better off finding and fixing a bug which occurs often under low load, than an obscure bug which occurs only under extreme load.

Powered by WordPress
Entries and comments feeds. Valid XHTML and CSS. 27 queries. 0.080 seconds.