Please have a look at those new examples and download the version 2 for tests.

If you followed the story, you may know this new version is more about a change in the inner logic than a set of new features.

However we think this new architecture will enable us to go further with the library.

The main changes are described here: Version 2 Release Notes. You will also find in the article a mini-guide to upgrade your templates still using PURE version 1.

In the coming weeks, the wiki will be updated with a refreshed documentation.

Any suggestion, ideas about how to structure it in a better way is highly welcome.

Heads & hands to write some parts too

Please have a look at the material above and send your feedback.

They use it for their Campfire application which is a web-based messaging/chatroom solution and the performances prove one more time that Erlang is a killer language when it comes to build stable and scalable back end systems.

You can read their full article here.

37Signals, Facebook,…

What are you waiting for? Start developing your own web application with Erlang now!

And Guess what? BeeBole is in!

Geek ‘n Rolla was a day long (April 21, 2009) conference for startups created by TechCrunch Europe. As part of the day we asked startups around Europe to celebrate with a little rocking out. This video was created by Bonney and Klein, conceived by Stradbroke Advisors. GeeknRolla was sponsored by Viadeo, and supported by UK Trade and Investment, as well as NESTA, School for Startups and Bootlaw.

GeeknRolla – The Movie from Mike Butcher on Vimeo.

On Behalve of BeeBole, I have to thank Bonney and Klein and Inma Martinez from Stradbroke Advisors for inviting us to participate to the video and of course TechCrunch Europe.

It feels good to be considered as a rocking start-up.

As he states:

It’s easy as pie to create a good looking and intuitive user experience when your solution only includes a few functional areas, but as you roll out further functionality all of a sudden that simplicity and intuitive feel starts to lose out to nested menus, complexity and options.

In my opinion, you have to solve two main issues:

1. How do you combine keeping it simple for users with simple needs with offering a complete solution to power users.
2. How do you display and browse your data, especially when the amount of features becomes huge.

Before going further, I encourage you to watch our first video about the BeeBole interface and features illustrating a few of the points discussed here.

How do you combine keeping it simple for users with simple needs with offering a complete solution to power users.

This issue is one of the core issues we wanted to solve with BeeBole.

We often look with envy at the US where you find a huge market with companies presenting similar needs.

But as a European start-up we knew from the beginning that we had to handle very different needs/languages/country specificity…

Add to that, the needs from different activity domains (a lawyer doesn’t require the same functionality than a web developer for example) and you end up with the following mantra: “Your Company Is Unique, Why Not Your Business Tools”.

The truth is that you can easily turn your application into a huge factory that allows the users to do everything they want, still, most of them will never benefit from more than half of your features when you get to that point.

It implies that half of your tool features become noise to them.

Personalized homepages like Netvibes or iGoogle were, in our opinion, a direct solution to that problem. Of course, you need to add some magic to the widgets/modules so they can exchange information in your screen, but the basis was there.

The idea is to offer as many features as you want in a solution that allows the user to determine which of these features he wants to see on his screen.

The screen would match each user’s country/job/language context as well as his/her personal way of working and not what the software provider has decided for him/her.

In other words, a perfect tune for your ears, without the unnecessary noise.

How do you display and browse information, especially when the amount of features becomes huge.

Most of the existing solutions will present their features gathered per functionality in tabs, sub-tabs and in the worst cases, sub-sub-tabs.

This system has advantages and disadvantages but it doesn’t reflect how most people work.

A few ideas:

• Everyday, you need to perform certain actions with your tool.
  Other actions have to be performed on a weekly, monthly basis or once a year…
  So, it would make sense to present your daily actions in your dashboard and to let you perform those in the very first screen.
  Actions you don’t need to perform regularly would be available in sub-screens.
• That list of actions might evolve during the year and might be different for certain groups of people.
  Here, it comes down to your tool’s flexibility. Again, we think that a module/widget approach is the best solution to solve this.
• No tabs.
  Reichenstein (head of user experience at Mozilla) argues, speaking about the future of Firefox on ReadWriteWeb, that:

  tabs were a good solution for an earlier age of the Internet, when users hardly ever had more than ten tabs open at any given time. Now, however, as browsers are slowly turning into operating systems, a new paradigm for organizing this information has become necessary.

  Well, the same remains true for web business apps.
  Tabs are like writing in stone the direct access to data you need at all time, where your real needs might change depending on what you are doing with the tool at a given time.

I believe our approach definitively brings something different and encourage all of you to give us your feedback about this.

1. The design has changed. If you can’t see those changes or if the design looks weird, just hit the refresh button of your web browser.
2. The re-design includes a lot of new features, mainly in the side bar: direct access to the recent posts, pictures, videos, … and at the end of each post you will find a list of all the related posts.
3. The URL has also changed. Instead of http://beebole.com/blog/, it is now http://beebole.com/en/blog/. The old URL being redirected to here, it shouldn’t be an issue for the old links you might have in your favorites.

Don’t hesitate to give us any feedback about the new design/features or to report bugs via the comments hereunder.

http://twitter.com/beebole

For some reasons, the account was deleted 6 months ago and the “undelete” feature of Twitter was not working for the last 3 months.

Watch it in full-screen mode, it’s in High Definition (The maximize button can be found at the bottom right of the screen).

First Video Tour of BeeBole from BeeBole.

The purpose of Tsung is to simulate users in order to test the scalability and performance of IP based client/server applications. You can use it to do load and stress testing of your servers.

(Definition coming from the Tsung website)

In this post, I will introduce the use of Tsung in order for you to stress test your web applications.

Why Tsung ?

Because it’s an Open-Source project and, to tell the truth, mainly because this application has been coded in Erlang which gives Tsung a little advantage on the other tools: it has the potential to simulate A LOT of concurrent requests … without crashing. That’s what we expect from a stress testing app, isn’t it?

Let’s start the installation

We will need the Perl Templating-Toolkit and the Gnu plotting utility in order to create nice HTML and graphical reports with the result data set.

So, back to your command prompt:

And now the configuration and installation of Tsung:

To properly remove Tsung from your system:

First test setup

Tsung is configured through the tsung.xml file located in ~/.tsung

update : You will find some configuration files in the extracted tsung tarball under the examples directory : ~/tsung-1.3.0/examples/ (Thanks Zak).

1) First, we setup the server IP/host address

2) Next, we define the load that we want our server to be exposed to.

Tsung simulates the user arrivals in the application. The example below describes 3 different phases (figures A and B).

The first one will last 15 minutes (the unit attribute can be set to ‘hour’, ‘minute’ or ’second’) during which 1 user/second will start his session.

This phase will be followed by a more aggressive 30 second long one simulating the arrival of 8 (1/0.125) new users each second.

We will end this test with a third phase simulating the arrival of 1 user/second for 25 minutes.

3) Finally, we create one or more HTTP sessions. The easiest way to populate ours is to record them.

To achieve that we must first tell our browser to pass through a proxy listening to port 8090 (Firefox preferences – Advanced – Network – Settings).

When done, we start the Tsung recorder, record our http session and stop the recorder :

We will end up with an xml representing the newly recorded session located in ~/.tsung/tsung_recorderyyyymmdd-HH:MM.xml.

Just copy-paste this session into the main tsung xml file under and set it’s usage probability:

For each session, we can adjust the think time (in seconds) to suit our needs as well as group some requests into a specific transaction in order to get particular stats about it (duration, etc …).

We are now ready to go

… and wait … until Tsung comes back to us specifying the location of the result log.

For your first tests, it’s a good idea to have an interactive Erlang console opened on the server displaying some io messages (i.e. number of processes, service name, …) in order to keep track of what is really going on.

Generate the html and graph report

Tsung is logging data in the ~/.tsung/log/yyyymmdd-HH:MM folder. In order to use these info, we launch the tsung_stats.pl script which will produce a nice html summary report.

The interpretation of results showed in the report.html page is more or less straightforward.

Just two remarks :

1) The most important indicators IMHO are the requests/sec and the total requests count. We reach the optimum load the system can handle when the number of requests begin to decline for the same amount of time.

So, basically, at first, it’s good to start setting up tests with slow arrival phases and incrementally increase the number of users in the system.

Along with the total of active sessions, the ratio req/sec goes up which is perfectly fine. There are just more requests to process. Until the server starts to suffer and begins to slowdown the delivery, increasing the time needed to process each request.

2) Another cool indicator is the number of simultaneous users actually rolling their session (=/= concurrent requests).

Below is an example (figure A) where you can see a typical overload situation. Around the 1000th sec, the concurrent users (8 new users/sec starting their 100 requests session) simply exceeds the limit of what the system could handle (don’t know yet the exact point of failure.

At that point, I just lost contact with Mochiweb and was receiving a lot of Mnesia transaction Messages.

I will update this post after having reproduced the scenario … and this time logging the errors on disk …

The figures B shows the direct consequence of all this, a bunch of http error code 500 (internal server error) begun raise from that moment:

(old AMD dual core with 2Gig ram – 140 requests/session with a mean think time of 2 sec)

My dev load test

Here is the result of a load test I have run against our web app BeeBole (Erlang back-end) hosted by my dev machine

I have made it simple in order to have a relatively talking base of comparison.

The setup

• AMD 4000+ 2 Gig Ram desktop
• Ubuntu Ibex (Gnome, Htop and Erlang console running)
• Nginx + Mochiweb + Mnesia (db populated with +/- 70K records)
• 1 Erlang node – no load balancing
• Tsung was launched from my laptop connected on the same network (wired)
• +/- 100 dynamic requests/session (db CRUD, search based on pattern, …) with a mean think time between 2 requests of +/- 3 sec
• Total duration 1 hour divided in 5 arrival phases (get the xml code)

The result

3660 users run their session and a total of 506595 requests were processed successfully with a mean processing time of 15.52ms. Not bad!

Conclusion

Tsung is a rich and flexible stress tool with which you are free to build from very simple to quite complexe scenarios as well as simulate a ton of concurrent users.

You can do a lot more than described in this introductory article like playing with load balancing for example or simulating several different IP addresses and client agents (Mozilla, IE, Safari, …), even monitor your server.

The results I got so far, testing our Erlang back-end with different load config, just confirm what I already knew about the Nginx + Mochiweb + Mnesia stack : it’s just a fantastic first class services delivery machine.

Just try and test several arrival phases, compare the results and you will certainly have fun in stressing your web application.

Additional info

• The Tsung manual
• A tutorial video (Mickael Remond)
• A list of open-source testing tools

First of all, a big thanks to Robin Wauters and Veronique Pochet for the organization: it was a success!

Secondly, as I announced 3 weeks ago, BeeBole had been selected to do an elevator pitch of 2 min on stage.

You can watch it hereunder (It is not the same as the one appearing in the previous post) and find the slides on Slidehsare:

Plugg – BeeBole Elevator Pitch

We didn’t make it to the final but we’ve had wonderful feedback during the rest of the event and even got some press on TechCrunch.

Mic also held a small interview in Spanish for Ramón Suárez and his blog. (Thank you Ramón).

To end up, I would like to congratulate Mendeley and Myngle for winning the Start-Up Rally. Both have not only good products; they are also great people to meet.

You can find all the other videos, pictures and presentations of the conference here.

Excellent news from Robin Wauters, co-organizer of the Plugg event and editor at TechCrunch

Out of 133 European start-ups registered for the Plugg Rally, BeeBole made it to the top 20! Yay!

This means that on the 12th of March we will get a 2-minute pitch slot to present our Business Management Solution to an audience of internet specialists, investors and techno aficionados in Brussels.

If we make it to the top 3, we will get a final pitch slot of 10 minutes on the same day.

You can help us to get there by sending us your feedback on the 2 minute video pitch we made to introduce BeeBole when we registered for Plugg.

I already know how uptight I look in the video, so no need to insist on that

BeeBole – Pitch – 2 minutes (Plugg Preparation)

For the occasion, we also redesigned our website. Check it out at http://beebole.com

I’m repeating myself, but don’t hesitate to send us your feedback with regard to the new design and of course don’t hesitate to subscribe if you want to receive the latest news on the coming Beta.

See you in Brussels on the 12th of March!