I took a simple page with a table, some JavaScript and CSS in a separate file. I am running the tests using Apache JMeter.

Looking at the results it seems that in the beginning there is no big difference. The difference starts with bigger numbers where Nginx shows higher average numbers because it fails to respond or responds very late in some cases. Although the average numbers are high because of the reasons managed you can see that most calls are handled faster.

Nginx is supposed to use less resources so I used the “uptime” command before starting the test and right after the test, here are the results (measured only for test: 1000 users, 1000 times):

It clearly shows that Nginx uses less CPU than Apache for the same work, the difference is so big you can see it by just looking at the system monitor.

I like what I see from Nginx and I am definitely going to play more with it.

Prepare the build server

sudo apt-get install build-essential
cd ~/Downloads/

Download all the necessary files. Nginx needs pcre to be build.

wget http://nginx.org/download/nginx-1.4.1.tar.gz
wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.32.tar.gz

Unpack the compressed files

tar xvfz nginx-1.4.1.tar.gz
tar xvzf pcre-8.32.tar.gz

Build nginx where we tell it the pcre location, where we want to install it and we also tell it we don’t want to use gzip at the moment. To speed up the build you can use make -j 4 (or any other amount of threads)

cd nginx-1.4.1
./configure --prefix=/home/armin/nginx --with-pcre=/home/armin/Downloads/pcre-8.32 --without-http_gzip_module
make
make install

We can start nginx now

cd ~/nginx/sbin
sudo ./nginx

Nginx can be used to serve the pages now but it is not configured completely, it needs to be fine tuned.

For those who do not want to go trough all the steps them self here is a video showing how it’s done.

Prepare the build server

sudo apt-get install build-essential
cd ~/Downloads/

Download all the necessary files. Apache needs apr, apr-util and pcre to be build.

wget http://mirrors.supportex.net/apache//httpd/httpd-2.4.4.tar.gz
wget http://ftp.nluug.nl/internet/apache//apr/apr-1.4.6.tar.gz
wget http://ftp.nluug.nl/internet/apache//apr/apr-util-1.5.2.tar.gz
wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.32.tar.gz

Unpack the compressed files

tar xvfz httpd-2.4.4.tar.gz
tar xvfz apr-1.4.6.tar.gz
tar xvfz apr-util-1.5.2.tar.gz
tar xvzf pcre-8.32.tar.gz

Apr and apr-util do not have to be build separately they can be included in Apache.

mv apr-1.4.6 ~/Downloads/httpd-2.4.4/srclib/apr
mv apr-util-1.5.2 ~/Downloads/httpd-2.4.4/srclib/apr-util

Pcre needs to be build

cd pcre-8.32
./configure --prefix=/home/armin/pcre
make
make install

Now we can build Apache where we tell it that we have included apr, we tell it where the pcre is located and we also tell it where we want to install it. To speed up the build you can use make -j 4 (or any other amount of threads)

cd ~/Downloads/httpd-2.4.4
./configure --prefix=/home/armin/apache --with-included-apr --with-pcre=/home/armin/pcre
make
make install

We can start Apache now

cd ~/apache/bin
sudo ./apachectl

Apache is not completely ready now, it needs to be fine tuned. Like adding the user to run under, ip, port, etc..

For those who do not want to go trough all the steps them self here is a video showing how it’s done.

So what happened? I could have gone and bought an Nexus 7 but that is not my preferred screen, even if it is a great and cheap tablet. My other choice was some random Samsung or other known brand but they all lack high resolutions and I am not buying a tablet with less than full HD period. I intend to use this device for a lot of reading like I do on my Nexus and I want it to be crystal clear. So then the next option was the Asus Transformer Infinity, although this is a nice tablet it is not cheap at all and not very easy to find here. So what was my next option then? Maybe one of the not so famous brands with high resolution? Maybe but that is not really what I was looking for and I want some support from the community regarding the custom roms. So my next option then was the newly introduced Sony Xperia Tablet Z, this is a fine tablet but is not available at the moment, Q2 maybe? This brings me to my the last and my personal favorite option the Nexus 10. This is the perfect tablet for me and I would buy it without hesitation. I don’t really like the way it looks but this tablet packs a great screen with a fine price. But ooh wait this tablet is not available in the Netherlands and if you wish to buy it you will pay more than 600 euro. I love it but I am not nuts.

As you can read here above I really had no choice, there are some great tablets with value for money but they are not the ones I am looking for. I am looking for a tablet with a great screen and then the choices are very thin. Because I had no choice left in the Android camp I went and bought an iPad for the second time in my life, damn this really hurts

I wished the Android manufactures would start selling more tablets with high resolution and I also really would like to see Google sell their Nexus line here in the Netherlands. Until that time I am giving my money to Apple (not because I want to).

Although I have bought the iPad and I don’t regret the decision it is not a great device if you are an Android user, it lacks a lot of nice features that an Android user gets comfortable with. But never the less the screen makes me very happy when I look at it.

Some of the things I hate on the iPad:

• Switching between apps when you go from one to another by clicking a link or something, the back button is so nice in Android.
• Android keyboard and keyboards are a blessing compared to the iPad’s keyboard.
• Sharing between apps is so much easier with the Android than on the iPad.
• Not having an folder access makes all the apps in iPad implement a stupid web share I am suppose to access to get to my files.

My own Desktop

AMD Phenom II X6 1090T @ 3.20GHz (6 Cores), Memory: 8192MB, Disk: In Raid 0 = 250GB Seagate ST3250410AS + 250GB HDS722525VLSA80, Graphics: AMD Radeon HD 6800 1024MB

My old Laptop

Intel Core 2 Duo P8700, Memory: 4096MB, Disk: 120GB Intel SSD, Intel Mobile 4 IGP

My NEW Laptop

Intel Core i7-3840QM, Memory: 24GB, Disk: 120GB Intel SSD, Graphics: NVIDIA Quadro K2000M

I am using Phoronix Test Suite for testing and i am running the “workstation” suite.

The results:

My new lap seems to perform very well

The settings for this test are the same as for VirtualBox.

The results:

Overall KVM gives better performance than VirtualBox and VMware, i find it strange that the memory is the one that is slower. KVM gives better performance when looking at the rough power but when it comes to desktop (graphics) it really is behind the other two. There are options to speed it up but it is still not great. I would say use KVM for headless instances.

I was to lazy to retest VirtualBox with 4 cores so i am comparing VMware Player with 4 cores against VirtualBox with 6 cores on the same machine. The settings for VMware are the same as for the VirtualBox.

The results:

Looking at the results i think the conclusion is that VMware Player gives better performance than VirtualBox. Because of the 4 cores in VMware in stead of 6 in VirtualBox it looses almost all of the cpu tests.

VMware player lacks some of the features VirtualBox has but if you don’t need those maybe it is a better choice?

The machine I am running this test on is:

AMD Phenom II X6 1090T @ 3.20GHz (6 Cores), Memory: 8192MB, Disk: In Raid 0 = 250GB Seagate ST3250410AS + 250GB HDS722525VLSA80, Graphics: AMD Radeon HD 6800 1024MB

The VirtualBox:

AMD Phenom II X6 1090T @ 3.19GHz (6 Cores), Memory: 5120MB, Disk: 21GB VBOX HDD (on the raid disks), Graphics: InnoTek VirtualBox

I am using Phoronix Test Suite for testing and i am running the “workstation” suite.

The results:

Looking at the table i find the performance penalty very high actually, memory is the only part where the performance differences can be ignored. Does this mean i shouldn’t use VirtualBox, NO. It just means that if i am going to have any really heavy long running tasks i better not run them in an VM if i want speed. If you are running small tasks or daily stuff the performance drops are manageable and not always in the way.

There are many reasons why sprint planning sessions don’t go the way you want them to. Here is my short list of the things that I have seen breaking the sprint planning sessions the most.

1. No Product Owner or not available

Not having a Product Owner available in sprint planning is a bad idea. Even if your user stories are written well there are always questions or decisions that need to be made regarding the functionality or the priority. A solution is to have one other team member be the substitute Product Owner as long as he/she collaborates with the Product Owner and is allowed to make decisions.

2. Discussions are too technical or go in to too much detail

Most of the teams are very technically oriented, this means that they often tend to dive into discussions about the technical solution because that is their expertise. This is not a bad thing per se but these discussion often tend to be long, they don’t contribute anything to the sprint planning and can be done later when needed. Solution to this is not to allow technical discussions or have them on a high level instead of talking about all the details.

3. Vague user stories

Having vague user stories is one of the worst things you can have in a sprint planning. These user stories don’t allow the team to focus on planning but lets them wonder about what is meant and always bring up discussion where in the end the product owner needs to explain what is needed. In this process a lot will be said but most of the time this information eventually gets lost and is a waste of time. Creating well written stories that have a summarized self explanatory title and a clear scope with explicit points of functionality explaining what is expected and what not helps avoiding these discussions.

4. Team members not understanding planning poker

There tend to be two problems here, one is about not understanding how planning poker works and can be fixed by practicing. The second problem is where people don’t know what to take in to account when voting. These people tend to use different criteria when voting and making the planning variate a lot. Possible solution to this problem is creating a short list of criteria points to think about when voting.

5. No decisions are made

Having discussions is a good thing but having endless discussions is a bad thing. Sometimes teams keep talking without deciding what to do or how to do it because there is no one to make a decision or wanting to take the responsibility. To fix this problem have the Product Owner make decisions directly when talking about functionality, the priority and the goal. For making technically related decisions point one of the team members as Technical Lead and give them the right to make an decision when needed.

Although the upper list shows the things I have seen go bad in sprint planning I have also seen the same things work very well in some teams. Bear in mind that this is a list of common mistakes but that everything depends of the context and the way you work.