Wednesday, July 11, 2012

Ruby and Memcached tricks

I love Ruby. It's a great language. I love almost everything about it (maybe besides the symbol syntax... but that's just me I guess).

Today I fell in love with the alias method :)
require 'memcached'
cache = Memcached.new "localhost:11211"
cache.set "message", "Hello, world!"
puts cache.get "message"
All is nice up to the get and set methods. Wouldn't it be nice to use the cache["message"] syntax?
class Memcached
  alias :"[]" :get
  alias :"[]=" :set
end
And then:
cache["message"] = "Hello"
puts cache["message"]

And live is good again :)

Error installing memcached gem

I've been struggling to install memcached gem on my Ubuntu 12.04 box. Some error came out when installing native extensions:
rlibmemcached_wrap.c: In function ‘Init_rlibmemcached’:
rlibmemcached_wrap.c:13736:3: error: implicit declaration of function ‘sasl_client_init’ [-Werror=implicit-function-declaration]
rlibmemcached_wrap.c:13736:33: error: ‘SASL_OK’ undeclared (first use in this function)
cc1: some warnings being treated as errors
make: *** [rlibmemcached_wrap.o] Error 1

A quick look at what uncle Google has to say about it didn't reveal anything at first glance. A deeper search gave me the following address:

https://github.com/evan/memcached/issues/17

Basically the problem is that one needs to install libsasl2-dev package for this to work.

And live is good again :)

Tuesday, July 10, 2012

Grails 2.1.0 performance

In this installment we'll be checking out the performance of the latest (2.1.0) version of Grails compared to 1.3.9 and 2.0.4. So without further due let's jump right into the code.

The HomeController
class HomeController {
  def index() {
    def date = new Date()
    redirect uri: date.format("/yyyy/MM")
  }

  def page() {
    def months = [ '', 'January', 'February', 'March', 'April', 'May', 'June', 
      'July', 'August', 'September', 'October', 'November', 'December' ]
    [ year: params?.year, month: params?.month, months: months ]
  }
}

So we see 2 actions here: one that checks the current date and does a redirect and one that spits out some data to view. So let's see the view then :)

The page.gsp:
<!doctype html>
<html>

<head>
  <title>Galery</title>
</head>

<body>
  <ul>
    <g:each in="${1..12}" var="i">
    <li class="${i == month ? 'current' : ''}"><a href="/${year}/${i}">${months[i]}</a></li>
    </g:each>
  </ul>
</body>

And now - time for benchmark results. All applications started this way:

grails prod run-war

and benchmarked using Apache Benchmark like this:

ab -n 1000 -c 10 http://localhost:8080/example/2012/03 up until the point when the figures became stable (usually between 20-30 executions with 5-10 seconds breaks in between).

Grails 1.3.9

Server Software:        Apache-Coyote/1.1
Server Hostname:        localhost
Server Port:            8080

Document Path:          /example139/2012/03
Document Length:        776 bytes

Concurrency Level:      10
Time taken for tests:   0.526 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      942000 bytes
HTML transferred:       776000 bytes
Requests per second:    1902.84 [#/sec] (mean)
Time per request:       5.255 [ms] (mean)
Time per request:       0.526 [ms] (mean, across all concurrent requests)
Transfer rate:          1750.47 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       2
Processing:     1    5   3.5      4      41
Waiting:        1    5   3.5      4      41
Total:          1    5   3.6      4      41

Percentage of the requests served within a certain time (ms)
  50%      4
  66%      6
  75%      6
  80%      7
  90%     10
  95%     12
  98%     14
  99%     17
 100%     41 (longest request)

Grails 2.0.4

Server Software:        Apache-Coyote/1.1
Server Hostname:        localhost
Server Port:            8080

Document Path:          /example204/2012/03
Document Length:        776 bytes

Concurrency Level:      10
Time taken for tests:   0.235 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      942000 bytes
HTML transferred:       776000 bytes
Requests per second:    4254.25 [#/sec] (mean)
Time per request:       2.351 [ms] (mean)
Time per request:       0.235 [ms] (mean, across all concurrent requests)
Transfer rate:          3913.58 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.3      0       5
Processing:     1    2   1.5      2      16
Waiting:        0    2   1.5      2      16
Total:          1    2   1.6      2      16

Percentage of the requests served within a certain time (ms)
  50%      2
  66%      2
  75%      3
  80%      3
  90%      4
  95%      5
  98%      7
  99%     10
 100%     16 (longest request)

As we can see there's quite a performance gain between 1.3.9 and 2.0.4. Good!

Grails 2.1.0

Server Software:        Apache-Coyote/1.1
Server Hostname:        localhost
Server Port:            8080

Document Path:          /example/2012/03
Document Length:        776 bytes

Concurrency Level:      10
Time taken for tests:   0.333 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      942000 bytes
HTML transferred:       776000 bytes
Requests per second:    3002.16 [#/sec] (mean)
Time per request:       3.331 [ms] (mean)
Time per request:       0.333 [ms] (mean, across all concurrent requests)
Transfer rate:          2761.76 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.2      0       3
Processing:     1    3   3.0      2      29
Waiting:        0    3   2.9      2      29
Total:          1    3   3.0      2      29

Percentage of the requests served within a certain time (ms)
  50%      2
  66%      3
  75%      4
  80%      4
  90%      6
  95%      9
  98%     12
  99%     17
 100%     29 (longest request)

It looks like 2.1.0 is a little bit (actually 1/4th) slower in this case than 2.0.4. Interesting...

Rails 3.2.6


For comparison I've done a similar experiment translating the the same routing, controller and view to Rails (just out of curiosity).

We'll start the application under Unicorn with 4 workers (that's how many cores my notebook has)

unicorn -E production -p 9393 -c config.rb

And the config.rb
worker_processes 4

Server Software:        
Server Hostname:        localhost
Server Port:            9393

Document Path:          /2012/03
Document Length:        728 bytes

Concurrency Level:      10
Time taken for tests:   1.109 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Non-2xx responses:      1000
Total transferred:      983000 bytes
HTML transferred:       728000 bytes
Requests per second:    901.84 [#/sec] (mean)
Time per request:       11.088 [ms] (mean)
Time per request:       1.109 [ms] (mean, across all concurrent requests)
Transfer rate:          865.73 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     6   11   5.9     10      64
Waiting:        6   11   5.9     10      64
Total:          7   11   5.9     10      64

Percentage of the requests served within a certain time (ms)
  50%     10
  66%     11
  75%     11
  80%     12
  90%     14
  95%     15
  98%     19
  99%     55
 100%     64 (longest request)

Sinatra


Now let's take a look at how a similar case will handle a Ruby framework, Sinatra.
require 'rubygems'
require 'sinatra'
require 'slim'

disable :logging

get '/' do
  date = Time.now
  redirect "/#{date.year}/#{date.month}"
end

get '/:year/:month' do
  @current = Time.new(params[:year], params[:month])
  @months  = [ '', 'January', 'February', 'March', 'April', 'May', 'June', 'July', 'August', 'September', 'October', 'November', 'December' ]
  slim :index
end

__END__

@@ index
doctype html
html
  head
    title Galery
  body
    ul 
      - (1..12).each do |month|
        li class="#{@current.month == month ? "month current" : "month"}"
          a href="/#{@current.year}/#{month}" #{@months[month]}

We're using sinatra with slim templating engine (my favorite!). We'll start the application the same way as the Rails app above.

Now for the actual results:
Server Software:        
Server Hostname:        localhost
Server Port:            9393

Document Path:          /2012/03
Document Length:        709 bytes

Concurrency Level:      10
Time taken for tests:   0.449 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      922000 bytes
HTML transferred:       709000 bytes
Requests per second:    2227.71 [#/sec] (mean)
Time per request:       4.489 [ms] (mean)
Time per request:       0.449 [ms] (mean, across all concurrent requests)
Transfer rate:          2005.81 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       1
Processing:     1    4   2.8      4      29
Waiting:        0    4   2.8      4      29
Total:          1    4   2.8      4      29

Percentage of the requests served within a certain time (ms)
  50%      4
  66%      4
  75%      5
  80%      5
  90%      6
  95%      7
  98%     12
  99%     22
 100%     29 (longest request)

Ok, now you can really see the difference in count of bytes sent over the wire. That's due to the differences in view technology (slim is very compact in the actual output)

At the end of the day the performance of both Grails and Sinatra (even though not very comparable) is similar with a clear performance winner :) Rails lacks a bit in performance.

There is however a difference in startup time and memory usage:

FrameworkMemoryStartup time
Grails 1.3.9485.1MB21.95s user 0.76s system 109% cpu 20.656 total
Grails 2.0.4699.3MB53.51s user 1.38s system 152% cpu 35.942 total
Grails 2.1.0713.1MB30.19s user 1.30s system 106% cpu 29.609 total
Rails 3.2.6169.8MB9.64s user 0.68s system 259% cpu 3.977 total
Sinatra on Unicorn82.1MB1.46s user 0.18s system 55% cpu 2.963 total

Have fun!

Friday, June 29, 2012

Groovy 2.0 is there - but useless...

As much as I waited for the 2.0 release of my favorite programming language I'm grumpy about the quality of the release - or rather the lack of it. Here's why:

One of the most important (for me) things that have been added to 1.8 (I guess it was), the annotations to decoratively add logging facilities to classes is broken.

https://jira.codehaus.org/browse/GROOVY-5557
@groovy.util.logging.Slf4j
class Test {
    Test() { log.debug "Here" }
}
But the best thing is the error message:
Caught: BUG!
Until that's fixed I recommend sticking to the stable version.

Not a nice day,... unfortunately...

Tuesday, June 5, 2012

Syntax highlighting in less

I've been looking for this way to long not to make a note on my blog.

Syntax highlighting in less - Big thanks for the author of this blog post for making the contribution!

So what you do is:

a) you install the highlighter
apt-get install source-highlight
b) you enable less to use it by adding the following lines to your ~/.profile
export LESSOPEN="| /usr/share/source-highlight/src-hilite-lesspipe.sh %s"
export LESS=' -R '
And believe me: life is really good again :)

Tuesday, May 29, 2012

Turning to the dark side

It's been over 15 years since I've tried switching to Linux for the first time. I distinctly remember the first experience I've had that day when "to install" really meant "to compile the kernel". It was awful, bad and completely not approachable by mare mortals. That's how I met Linux.

The astounding thing about it though was that it kept nagging me over and over again. The sole idea of having an operating system for free and be able to customize it to your liking (although excruciatingly painful) stayed with me since that day. I was sold to the idea of using free software and some years later to give back something in return.

Some years later I've learned that there's nothing like a good Linux server and bought into the idea that as far as I am concerned Linux is The Operating System for servers but as far as Desktop is concerned it just doesn't measure up to the competition.

It's years later now, the new millennium, and I can finally enjoy a Linux distro prepared truly in a way that can compete with what I've already knew. It's Ubuntu 12.04 LTS - the first Linux I feel is worth using at all on a desktop.

So here's what I value the most and why I think you should just switch to Ubuntu 12.04 and never look back again:

  • Unity: User Interface that rocks! The first ever successful attempt to create a good looking and usable alternative to Windows
  • Memory consumption that doesn't eat all you have for breakfast
  • Hardware support that blows your mind
  • It's Linux inside all this meaning you can do whatever you please to it

My advise to you is: If you have not tasted it yet go ahead and try it out! It'll blow your mind how much space you can get in almost every aspect of your PC, starting with hardware requirements and ending with available screen space. It is truly astonishing!

Have a nice day!

Wednesday, May 16, 2012

Making Groovy scripts maintainable

Writing Groovy code is cool. Fixing them some time later can be hard as they tend to grow out off control pretty soon. Finding an install.gsh that has 100+ lines is not hard. And since Groovy is a very expressive language those 100 lines are not making the compiler happy - it's actually stuff to be done.

I have a bad feeling about this

In Java we're pretty much used to either creation of big, ugly, monolithic classes or going the completely opposite direction with Spring or some other dependency injection framework. In scripts we tend to rather go the first way which makes them unmaintainable and hard to understand. Why? Because historically shell scripts were created this way and we tend to think in this way. It's a script, isn't it?

These are not the droids you're looking for...

In fact Groovy scripts are not scripts at all. They are classes, that will have a main method. The only difference is that they are automatically compiled when needed. This means we can use all the good Java stuff when writing Groovy scripts: classes, external libraries through @Grab annotation and so on.

Here's an example:

Configuration.groovy:
class Configuration {
    String path
}
install.gsh:
#!/usr/bin/groovy

println new Configuration(path: "/tmp")

Since all the classes are in the default package (inaccessible from pure Java!) you don't need to import them manually. Should it make sense to split them into folders you can always do that:

org/example/Configuration.groovy:
package org.example

class Configuration {
    String path
}
install.gsh:
#!/usr/bin/groovy

import org.example.Configuration

println new Configuration(path: "/tmp")

Further more you can write tests for your classes, make sure they always work even if some mad cow enters the arena and goes Hulk on your code :)

May all your scripts be maintainable forever and for always!