ingo() -> tech. % Ingo Schramm - Erlang

Google Wave On Your Knees

nospam@example.com (Ingo) — Tue, 06 Oct 2009 19:54:00 +0200

Installing Google Wave on a laptop ist relatively easy and straightforward. You just have to follow the instructions here: wave-protocol installation. If you have any problems with Openfire such as non working admin passwords you may switch to the famous ejabberd which is a XMPP server written in Erlang. An installation instruction for this setup you may find here: using google wave reference implementation with ejabberd.

After you have a XMPP server running you create the certificates as described here: wave-protocol certificates. You just copy the *.cert and *.key file into your wave-protocol root directory.

Next you edit the ./run-config.sh and assign the proper values of your setup to the variables. Hint: don't forget to comment or remove the line at the top saying

echo "You must configure the run-config.sh script" ; exit 1

When all this has been done you may start the server:

./run-server.sh

If all gone well you find some INFO logging in your terminal. Next you open two additional terminal windows and start one wave client per window, each with a different username:

./run-client-console.sh mr-foo

and in the other terminal:

./run-client-console.sh mr-bar

Now you are ready to initiate a conversation between Mr. Foo and Mr. Bar. In Mr. Foo's window type "/new". This will create a new wave. Then type "/add mr-bar@your-domain". This adds Mr. Bar to the wave. In the other window you should see the wave appear. Then you may type something like "Hello Mr. Foo" there. Pressing enter will make the greeting appear in Mr. Foo's window. You've done a Wave communication in your laptop!

Below you find a list of the available commands in the console client. Just type a slash and the name and arguments of the command, then enter.



connect   user@domain server port  connect to 

                                   server:port as user@domain

open      entry                    open a wave given an inbox 

                                   entry

new                                create a new wave

add       user@domain              add a user to a wave

remove    user@domain              remove a user from a wave

read                               set all waves as read

undo      [user@domain]            undo last line by a user, 

                                   defaulting to current user

scroll    lines                    set the number of lines to 

                                   scroll by with { and }

view      mode                     change view mode for the open 

                                   wavelet (normal, xml)

log                                dump the log to the screen

dumplog   file                     dump the log to a file

clearlog                           clear the log

quit                               quit the client

What Erlang/OTP is good for and what it is not

nospam@example.com (Ingo) — Wed, 27 May 2009 16:56:28 +0200

Erlang/OTP is without any doubt a powerful tool. But as with any technology it's not good for any use case imaginable. It has a lot of strengths but some weaknesses too. Erlang glances in everything related to distribution and reliability. If you want to write software to be arbitrarily distributed over multiple instances, CPU cores, mashines or even data centers without having to change the programming paradigm for any particular case you probably have the perfect tool with Erlang. To benefit from Erlang you should have a problem best solved with a distributed solution. This may be reliable message passing or rock solid in memory storage but it is probably not web page generation and delivery.

In the Internet world, Erlang is perfect for middle ware or backend systems like caches, message queues and exchanges, databases or storage abstractions. But it is probably not the right tool to write web applications. Sure, you may add a HTTP endpoint to your message middle ware or database but should you use Erlang in a way one usually uses JSP or PHP or Ruby? Probably not. Web applications have a very short life cycle. The business rules are in a constant flow and have to be changed over and over again. To define such rules in Erlang may turn out to be a very hard job. Despite of its expressiveness Erlang is not the language to be used as an embedded language as for Yaws dynamic content or in ehtml. It works - but it is comparably hard to maintain and not that fast in terms of execution time.

It's not that Erlang is a functional language but it's a functional language with a special syntax. There are all those commas, semicolons and dots and a pretty verbose notation for associative arrays, the records. The benefits of the syntax as for example how you deal with binary data is of little use when programming the business rules of a web application. It's simply not designed for such a use case. It's designed for writing reliable software dealing with network communication and related stuff. But it's not made to express complex rules in a domain specific language.

On the other hand, the Erlang VM is highly optimized to spawn and execute a huge number of small processes but it's probably not optimized to execute a thread in the shortest possible time ever. Modern Java implementations may beat current Erlang easily. Sure, the maintainers of the Erlang VM do a lot of work improving both performance and SMP scalability but all those optimizations a not yet at the end. High performance is not the domain of the OTP.

When you ever think about using Erlang, the first question to ask should be whether your problem deals with either redundancy, scalability or distribution. Second is whether you not have to deal with high performance as well, and you should not have to deal with the low lifetime of business rules. If you answer these questions with yes you get a highly optimized and convenient tool for the job.

Erlang Release R13B Preview Benchmark

nospam@example.com (Ingo) — Mon, 06 Apr 2009 14:43:13 +0200

At the end of the month a new Erlang release will be available for production: R13B. What I know so far is very promising. A lot of work has been done to improve SMP performance and flexibility. Beside of remarkable internal optimizations as for example the multiple run-queues a number of switches are added to have better control on the SMP behavior. Now you can bind schedulers to logical processors or change the number of active schedulers on runtime, just to name a few. Another goodie is added unicode support.

To check out the effect of the new run queues I was running a little benchmark with R13A. The program creates a ring of 5000 processes and executes a simple leader election algorithm with O(n^2) communication complexity. The mashine was a 4 Opteron 1.8GHz with 64bit Linux 2.6.18. Kernel polling was active. As you may see in the picture below the program has not been well written in the sense of good asynchrony since it performs almost always better on a single core. That's perfect for the benchmark and it really challenges the SMP implementation. The multiple run queues have a remarkable benefit in both performance and scalability and this may even be better for an increasing number of cores.

Investment in Erlang is investment in the future. With every new release the inventors of the OTP runtime will add more and better SMP features. The focus of the runtime is still more on distribution and reliability but the performance and scalability will soon reach those of other technologies.

UPDATE 1

The same test running on a 8 core Intel Xeon 3 GHz with a 64bit 2.6.9 Linux:

UPDATE 2

Sources: ring_leader_erlb.tar.gz