Eduardo Silva Pereira

I can not omit the huge impact that the NodeJS project is having as a server side solution with performance and features for new projects nowadays. As i wrote yesterday, i attended the Startechconf and at least two companies are putting their efforts to move to NodeJS as backend solution for their web infraestructure in a few projects: Yahoo and ForkHQ.

I did not know too much about NodeJS, so i dedicated some time to read the documentation and papers available, so being a web server side guy i would like to share my opinion, because i listen too much about that everybody must move to NodeJS.

The primary feature of NodeJS is that provides a framework  based in a language thats handled by thousands of people: Javascript, if you are a real web developer you know what is JavaScript and you know how to deal with it, so you can jump directly from the client to the server side and write your own implementation, based on an event driven infrastructure with reduced I/O and better performance than dynamic content generators available such as Ruby, Python or PHP.  It’s pretty interesting as technology which expose new possibilities to improve backend sides, but you must know when and where to use it.

The good thing is that Node abstract you from the dirty low level concepts of a web server like threading, shared memory, asynchronous sockets, reduced I/O, etc. But this have a cost, this is not magic, is just cool, because it works and have demonstrated to perform very well and have a level of trust as is written on top of V8 JavaScript engine supported by Google. The cost of an event driven solution is that if for some reason the program have an exception, the whole service will block or even crash depending of the case, so you must be aware because if something similar happen. As an example, if some Apache context fails, it will kill the process or thread and start a new one, which is not the case of a common event driven web server. What happen if you have 1000 connections transferring data and the program fail ?, it will be critical, and this things happens when working in high production environment, if you have 50 requests per day you are safe and you can stop reading now

Node fills fine if you have thousands of incoming connections and your computing time is reduced, but if you will work with some complexity querying a database, doing some memcache or similar, you should start considering different options.

From now i start talking about solutions for really higher performance, Node is fast, but you cannot compare it with Apache, because Apache is the slowest web server available, compare it with NginX or Monkey. I will do a test now using the Apache Benchmark Utility comparing the NodeJS hello world example against Monkey which will serve a file which contains the Hello World message, the benchmark utility will perform 100.000 requests through 5000 concurrent connections.

NodeJS Benchmark

edsiper@monotop:/home/edsiper/# ab -n 100000 -c 5000 http://localhost:8888/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient)

Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Completed 100000 requests
Finished 100000 requests

Server Software:
Server Hostname:        localhost
Server Port:            8888
Document Path:          /
Document Length:        11 bytes

Concurrency Level: 5000
Time taken for tests: 9.403 seconds
Complete requests: 99747
Failed requests: 0
Write errors: 0
Total transferred: 7481025 bytes
HTML transferred: 1097217 bytes
Requests per second: 10608.48 [#/sec] (mean)
Time per request: 471.321 [ms] (mean)
Time per request: 0.094 [ms] (mean, across all concurrent requests)
Transfer rate: 776.99 [Kbytes/sec] received

 

The NodeJS server was capable to serve 10608 requests per second and took 9 seconds to serve the 100.000 requests. Now let’s see how Monkey did…

Monkey HTTP Daemon Benchmark

edsiper@monotop:/home/edsiper/# ab -n 100000 -c 5000 http://localhost:2001/h.txt
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient)

Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Completed 100000 requests
Finished 100000 requests

Server Software:        Monkey/0.30.0
Server Hostname:        localhost
Server Port:            2001
Document Path:          /h.txt
Document Length:        13 bytes
Concurrency Level:      5000
Time taken for tests:   5.718 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      20300000 bytes
HTML transferred:       1300000 bytes
Requests per second:    17489.54 [#/sec] (mean)
Time per request:       285.885 [ms] (mean)
Time per request:       0.057 [ms] (mean, across all concurrent requests)
Transfer rate:          3467.16 [Kbytes/sec] received

Monkey did 17.489 requests per second and took 5.7 seconds to serve the 100.000 requests. Ooops!

The impressive results are even better, because Monkey performed 100.000 I/O to retrieve a file from the hard disk and also send a couple of extra bytes one each response (Monkey does not cache file contents or metadata). Serve a file is a slow process due to I/O, so i will do a test later with the same case serving some fixed content through a plugin (something similar to what Node is doing in the test example).

What am trying to say here, is that depending of what are you trying to accomplish and the complexity of your backend., NodeJS can be the solution for your environment as well you could need something even more scalable like Monkey, but the learning curve of NodeJS is short and the learning curve of Monkey is a little high, but this last one  provides a better performance because all is well written in C, as well any extension through the C API interface requires some knowledge which in NodeJS are hidden, you have to balance between goals, knowledge, learning curve and deadlines.

[UPDATE]:

• Joe provide me a new code to launch Node with multiple workers, so Node increase the performance, the new values were updated.

Monkey Project team is looking for companies and individuals who requires a really fast and lightweight HTTP server for their products. Our solution is based in open source technologies delivering a high quality product supported by our community as well the main core developers.

Monkey provides an extensible HTTP framework for your needs, we are very careful about performance and low resources usage. On every release we perform a strong QA and different tests to assure backward compatibility.

Here is a list of a few reasons about why Monkey is the right choice:

• Binary size is 55KB
• Event driven oriented (asynchronous with fixed threads)
• HTTP/1.1 compliant
• Built on top of Linux 2.6 features (specific Linux syscalls dependent)
• Plugins support: fully modular, extensible through the C API
• Indented configuration mode (configuration for human beings)
• CGI supported through our Palm protocol server implementation

Monkey has been tested in the following devices:

• Gumstix boards
• Beagleboard
• Android based phones/tablets
• Laptop/PC

If you need to integrate a strong and lightweight web server in your Linux Software stack, evaluate Monkey and let us know about it, we are able to help you out in the process.

One thing is clear: you can improve everything!. We have been doing some cool improvements in Monkey internals, our next release will rock more than usual, 0.14.0 is very promising in terms of speed and low resources usage.

I would like to put here just a simple example, after analyzing each HTTP cycle of our server, we found a couple of parts of the architecture where some functions were not so fast as we though (that’s the problem.. we though ), so after put our hands on we have some results. The following new improvement case take place in one function which perform string search with string limits, let’s take a close look to the original diagram:

Diagram generated with valgrind + kcachegrind,
5000 request performed with apache benchmark (ab)

If you click in the image, you will realize that function mk_string_search_n() used to be 64.91% of parent function mk_http_init(), so there was something wrong, after analyze the code we decide to rewrite the old function and do some magic with string limits, after a while here is the result:

So we have improved the function performance, decreasing it’s computing time from 64.91% to 7.11%, obviously this means less CPU usage + more requests per second = better performance. If you are curious, you can find the patch here.

This is not all, also we have also merged new patches to decrease memory allocation per request, better hostname matching and small internal changes… as I said.. Monkey 0.14.0 will rock!

Source
http://blog.monkey-project.com/2011/04/08/more-performance-improvements-underway/

I’ve started to write a simple plugin for Monkey HTTP Daemon which will perform the HTTP Basic Authentication, i had to deal finding simple functions to perform Base64 and SHA1 encryption without use external dependencies such as OpenSSL or similars. Finally after waste my time with some buggy SHA1 functions,  i got the implementation written by Linus Torvalds for GIT project.

My test cases are working as expected, so i’m placing a tarball with the code and examples, feel free to to use it in your open projects:

http://monkey-project.com/~edsiper/misc/sha1_b64.tar.gz

• download the tarball
• tar zxfv sha1_b64.tar.gz
• cd sha1_b64/
• make
• ./example
• php example.php

happy encryption

Monkey HTTP Daemon is a very Fast and Lightweight Web Server for Linux. It has been designed to be very scalable with low memory and CPU consumption, the perfect solution for embedded and high production environments.

The project was started in 2001, internally it used to work with forking and threading networking models to attend clients, now, our current branch 0.11 is the second major milestone, we have a new web server working in asynchronous mode, fixed threads, stable API, indented configuration mode and with an excellent performance.

What is new ?

• Indented Configuration mode
• Cheetah! Plugin: New ‘config’ command
• New MaxRequestSize configuration variable
• Plugin API Interface improved: new functions available
• Add RPM spec file (Welcome Fedora!)
• Palm Server
• Palm Plugin
• Liana Plugin: Base networking plugin interface
• Logger Plugin: the logger has been dropped from the core and moved to a plugin
• Dirlisting Plugin: Allows to list the content of a directory in HTML format
• Performance improvements
• Minor fixes

Contributors

We would like to thanks to the following person who have been involved doing code and bug fixes contributions on this release:

• Jonathan Gonzalez (Zeus)

Also thanks for take some time to help the project being sysadmin and maintaining our new server.

Join us!

We want to hear about you, our community is growing and you can be part of it!, you can met us in:

This week we will release Monkey HTTP Daemon v0.11.0,  stay tuned to our updates in :

• Twitter: http://www.twitter.com/monkeywebserver
• Identi.ca: http://identi.ca/group/monkey
• LinkedIn: http://www.linkedin.com/groups?gid=3211216
• Mailing List: http://lists.monkey-project.com

In some previous post about Monkey HTTP Daemon project, i have been describing some parts of the new architecture and goals that we are trying to accomplish. Now we have a faster asynchronous web server, very lightweight and with a good designed API to extend the features through plugins.

I have received some questions about dynamic content generation support, specifically questions like “what about CGI and PHP support ?”, so now is time to describe more in detail how we are handle this through our Palm Protocol.

Palm Protocol, aims to provide a simple CGI applications server which work over TCP. Is pretty much similar to FastCGI or SimpleCGI, but still more simple , basically is a TCP server listening in different ports to serve different dynamic content in a pre-forked model. To explain it better take a look to the following diagram:

Server Side

Palm server create specific handlers per configuration, for example, it can be configured to serve PHP and Python scripts, each handler contains information about how many child process will be available, the executable interpreter and optional arguments for it, for example, in order to define a handler for PHP we could add this entry in palm.conf:

[PHP]
Port = 2010
Exec = /usr/bin/php-cgi
Arguments = -f
Childs = 5

That entry specify that the handler will be listening in TCP port 2010, it will create 5 child process and each request will be server by the php-cgi program, adding the -f argument before the script to be called.

Each handler created is called a ‘Palm’, you can configure as many Palms as you want.

Client Side

In the client side, the Palm Plugin for Monkey HTTP Daemon will be listening for specific file extension on each HTTP request, so it can be configured to handle files with .php extension and connect to the right Palm. Here’s a simple configuration line for PHP in the client side, this configuration take place in the plugins/palm/palm.conf file:

Palm   php   application/x-httpd-php    127.0.0.1     2010

Each row in the configuration file represents a Palm entry, the fields required are: protocol, file extension, mime type, palm server address and palm server port. This configuration must match the Palm server configuration. So every time that a PHP file is requested, the Palm client will connect to the Palm server to the specific port, send the request and wait for a response.

Protocol details

The protocol as mentioned before, is very basic, is composed by the following:

absolute_script_path + CRLF    (mandatory)
cgi_header = value + CRLF      (optional)
CRLFCRLF                                (mandatory)

a text example could be:

/home/foo/monkeyd/htdocs/info.php\r\n
SERVER_SOFTWARE=Monkey/0.11.0-dev\r\n
SERVER_PROTOCOL=HTTP/1.1\r\n
HTTP_HOST=localhost\r\n
QUERY_STRING=a=1&b=2&c=3\r\n
\r\n\r\n

The first mandatory row indicates the absolute script path to be interpreted or executed, the second optional row represent the CGI/1.1 headers used by the interpreters, you can add N cgi headers as required, and the final mandatory row indicates the end of the request.

If any error occurred in the server side, the Palm server must return a formatted plain text or HTML error to the client side, Palm Protocol does not handle error codes.

Monkey Development team is proud to announce our major milestone: Monkey 0.10.0 !!!

Introduction

Monkey HTTP Daemon is a very Fast and Lightweight Web Server for Linux. It  has been designed to be very scalable with low memory and CPU consumption, the perfect solution for embedded and high production environments.

The project was started in 2001, internally it used to work with forking and threading networking models to attend clients, now, our current release 0.10.0 is one of our major milestone, we have a new web server working in asyncronous mode, fixed threads and with an excellent performance.

This version has been in development for the last two years, we have rewritten almost 85% of the old code and we have met our goals in a very
stable product

What’s new ?

• Asynchronous Server: No more blocking calls.
• New Pipelining request support
• New ‘Listen’ configuration directive: allow to restrict incoming
  connection to a determinated network interface
• QA Packages: We have added a quallity assurance package which help us to
  determinate if the server is working properly as expected, it has different
  type of request and expect specific responses, also it checks the log files
  for every QA request made
• Plugins Support: Now Monkey support Plugins, we have created a new API
  which provides a very easy way to extend the behavior and features of the
  server.
• Cheetah! Shell Plugin: This plugin add a command line interface (shell) to
  Monkey!, it has been writen for debugging purposes, check workers status and
  others.
• Security Plugin : It adds optional security rules to restrict the access
  to the server
• Worker logger: A new worker is in charge to register the log entries, it
  helps to reduce the I/O
• Configuration Files: The configuration structure has changed, now we have
  a more organized configuration for global variables and virtual hosts
  directives.
• A lot of minor bug fixes

Contributors

We would like recognize the contribution and help provided by the following
volunteers:

• Carlos Ghan
• Thorsten Schmale
• Niedobryjasiu
• Jonathan Gonzalez
• GreenFox
• Felipe Astroza

Join us!

We want to hear about you, our community is growing and you can be part of
it!, you can met us in:

• Mailing list: http://groups.google.com/group/monkeyd
• IRC: irc.freenode.net #monkeyd

Official Announcement: http://www.monkey-project.com/Announcements/v0.10.0

I would like to introduce a new plugin in Monkey 0.10.0 called Cheetah! . Cheetah is a shell for Monkey HTTP Daemon, it runs on demand if the plugin is specified in the plugins.load configuration file, please take a look to this simple screenshot:

So let’s see what it is and the current status:

• Aims to work like a plugin for Monkey HTTP Daemon loaded on demand
• Provides useful information about the configuration used for the server and virtual hosts defined
• Provides details about the workers running. At the moment just the OS PID assigned
• List plugins loaded and stages where each one is working or taking some action
• Show server uptime

Planned features for Monkey 0.11.0

• Show memory usage per worker thread
• Show basic statistics about current clients connected
• Reconfigure Monkey on fly, no more server restart when configuration files are modified
• Unload/Load plugins on fly
• Print reports for debugging purposes
• Work over unix pipe instead of Monkey STDIN

Today i’ve been summarizing  how many different task are involved when you start an open source project, let’s see:

1. Choose project name: for some people this task can take days!
2. Choose project website URL: nowadays is difficult to find a short and cool domain name available
3. Get a hosting, maybe sourceforge.net ? well, the right place to start
4. Design your project logo and web site: you can install a CMS, but you need to spent time configuring and deciding contents that will be available
5. Create a control version system repository: oh! svn or git ?, if so, where ? hmm
6. Create a mailing list: you want to keep informed “someone” in the future!
7. Create documentation: you know everything about your program, but what about others ?, not all end users are developers!
8. Create a chat room: maybe the most easy step, don’t forget to set the topic if is an IRC channel and “save” the channel
9. Register your project on a news site like freshmeat.net: the world must know about your project! not just your 2 friends!
10. Invite people to participate: most of the successful projects are growing thanks to the community! you need people involved! (including fanboys!), if your project is interesting more than one will want to take part on it…
11. Coding

Are you sure that you will handle the whole stuff by your own ?, an open project is not just the license attached, is about to let people collaborate and hear their ideas, they can contribute a lot…