Support Black March against SOPA and PIPA

Filed in /dev/random | Comment Now

Long time since last post…

So why not be a bit nerdy 😉

My desktop running awesome wm, conky and a couple of xterm’s with vim and mutt.

Filed in /dev/random | 2 Comments

What hardware do I need for my website?

Well it’s a quite common question a customer asks. Usually the information they supply with it is something like this… “it’s based on php and mysql.. and it will big quite big.. So what hardware do I need?”

Well that doesn’t really give much to go on and for the most time that will be all you have to guess from.

So I’ll thought that I write a post about a real world example to show that if you get a recommendation from that info (usually with a warning about it might fail during high traffic since then give info was very thin) it might not be the hardware it self that was the cause of the failed performance.

Without any knowledge about the application and how it preform under heavy load it is kind of a guessing game. And when the developers of the application doesn’t know how is a tech at a hosting company going to know it?

Without having done any load tests of the application it is a bit of a gamble.

Let’s take an example…

At 4pm a customer call saying that they have a banner going up in a online magazine. Since earlier experience from customers just ordering a shared web-hotel account putting their files up and letting it go live without a word we said that it had to be hosted on dedicated server since they otherwise can cause problems for other customers.

From the given information we knew that it was a flash banner that called a php script that fetched a row of data from a mysql database. They said that they would get about 400000 hits during 4 to 6 hours. From that they got a suggestion of hardware for a price (and they as we all didn’t want to pay more than necessary for hardware). And of course it was to go live the morning after.

The banner went live and the problems started to coming in.. in less then an hour they passed 1000000 hits on their php script and the cpu usage peaked at max.

So tweaking began as good as it could but it didn’t fix the whole problem.

One reason for the high amounts of hits was that it turned out that the banner called the php script every fifth second again so everyone seeing the banner didn’t just loaded data once.

And the real problem laid in the sql query that it made, it selected a random row from the database and send that data to the flash application.

This was done by using “SELECT * FROM table ORDER BY RAND() LIMIT 1”. A quite easy way to get a random row but devastating to performance on the database side. The application had worked fine then they tested it. Everything had run nice and quick so then it had to be the server causing it. And well to some extent it was since that question makes the database generate a random number for each row in the table and then sort them and pick out the row with the lowest number. That made the database question very cpu heavy and then then numer of request per second went up over 450 it couldn’t keep up (a bit higher than 28 requests/second said).

And the tuning that can be done to the database in that time can’t really make up for it. In this case their is two ways to go. Better and more expensive hardware or change the code (or a bit of both).

To show how different code can act on the same hardware I decided to make a little test.

This is done on hardware that has some years on the neck but it will still give a good point. I installed Apache, MySQL and PHP on a standard Arch Linux (left everything with their defaults). I installed the MySQL sample database “World”.

I wrote two php scripts.

index.php does “”SELECT * FROM City ORDER BY RAND() LIMIT 1” and prints out Name and CountryCode

index2.php first runs “SELECT COUNT(*) AS cnt FROM City” then $rand = rand(0, $row[“cnt”]-1); so that a random row number is generated by php and then “SELECT * FROM City LIMIT ” . $rand .”, 1″

Next I used Apache Benchmark to put some hits on them one at a time from a second computer.

I ran 100000 request with a concurrency level of 70.

During the time I watched the server with both top and the uptime command just to get a glance of how they would hit it.

index.php generated a load average over 70 and mysql made up for the most.

index2.php generated a load average around 30 and mysql was a lot happier.

So the point I want to make is that if possible alway test the application under load if not well don’t be too angry at the guy’s (or girl’s) hosting the application if there ain’t any knowledge of how it’s going to preform to be give to then 😉

Filed in Web | Comment Now

Why Java Sucks For Sysadmins??? Don’t think so ;)

Even thou I like Java I had a laught while reading this old blog post 😀

Much have been fixed since that time but Java can still be a complex platform for some 😉

Many times I been wishing for a stacktrace ala Java when lookig at failing php application..

and not to forget applictions coded in classic ASP… can’t someone make those go away 😉

Filed in /dev/random, Java | Comment Now


Where did my car go? 😉

Filed in /dev/random | Comment Now


Filed in Drawing | Comment Now


Played around with Munin (a tool to monitor your systems preformance), pretty nice tool.

Read more about it here:

Filed in /dev/random | Comment Now

Playing with Arduino, a Potentiometer and a LED

Got myself a Arduino Duemilanove a while ago, played around with it together with a potentiometer and a LED 😉

Filed in /dev/random | Comment Now



Filed in /dev/random | Comment Now

Internet Explorers odd behavior when reciving a 404

Got a question from a customer at work a while ago about why he couldn’t get his custom 404-page (page/resource not found) to work.

The simple answer was that the page worked… as long as you didn’t use Internet Explorer.

For some strange reason Microsoft decided that if the page that the server send to the browser (in case of a 404 or a 500) is less than 513 bytes it will use it’s own “Friendly HTTP Error Message” instead of the one from the server. This behavior can be turned of by changing the browsers settings but it’s turned on by default.

So to get around this behavior one must create a HTML comment in the page to pad it so that it gets larger than 513 bytes if it’s to show up in IE… can’t see why this behavior makes any sense but came to think of it when I wrote about how to create a custom 404-page for web applications in Tomcat.

If your interested in the custom 404-page in Tomcat howto you can read it at:

Filed in /dev/random, Java | 2 Comments