Lighttz – a simple and fast web server

Update : A naive implementation of using Lua 5.1 to generate a dynamic response has been added. This loads Lua, loads a Lua script and executes it. Retrieves the string response and returns it to the browser. Take a look below for a new additional download link.

Cheers

There are many well written , fast web servers around with full features for CGI , FastCGI , proxying and dynamic language support such as Ruby, PHP and Python. So what is Lighttz ? It’s a small HTTP server written in C , benchmarked against the big guns. It is by no means a replacement for the big four, and is mainly a testing showcase. For the sake of brevity, the comparison of the first benchmarks will compare the following web servers:

• Apache/2.2.8-mpm-prefork
• lighttpd/1.4.19
• nginx/0.5.33
• userver-0.6.0 – compiled and run with epoll support
  
• lighttz/0.1 – libev epoll event model
  

Short summary and the configuration as tested is below. Please note that other event models such as select and poll are available under each server , but these were picked for the performance or wide use ( in case of Apache ) .

Apache – http://httpd.apache.org/

The usual pre-forking server most, widely used to power many websites.

Lighttpd – http://www.lighttpd.net/

Also a very popular server. Instead of a forking model, it utilizes a fast a very well performing epoll mechanism.

Nginx – http://sysoev.ru/en/

A little younger but equally fast server , which also utilizes epoll event model.

Userver – http://userver.uwaterloo.ca/index.php

A small, microwebserver that’s mostly used for tests and benchmarks. Project is maintained at University of Waterloo.

Lighttz –

A short C program that simulates an HTTP server and handles the requests using Libev and epoll.

Test platform

Ubuntu 8.04 , Kernel 2.6.24-16 SMP , 2GB RAM, Core2Duo 2.4GHz

Benchmarking Client Program

ApacheBench . Command used:

ab -c1000 -n1000000 <host:port> . The test document index.html is a 357 byte static file. Lighttz did not use the static file, it sent out the exact same contents as index.html contained in a char array.

The above simulated 1000 concurrent clients making 1000000 requests .

Results

Each result is an average of three runs with one pre-warming run to let each server utilize the cache.

Requests per second. Listed in order of fastest to slowest.

1. Lighttz – 14,719 ( Cpu usage: 40-50% , Memory: 188 KB , 1 process )
2. Lighttpd – 14,701 ( Cpu usage: 65-85%, Memory: 6.6 MB , 1 process )
3. Nginx – 14,378 (Cpu usage: 65-80%, Memory: 2.1 MB , 2 processes )
4. Userver – 13,221 ( Cpu usage: 75-90%, Memory: 1.2 MB, 1 process )
5. Apache – 9,512 ( Cpu Usage: 60-80%, Memory: 3.5 MB x 147 processes , 514 MB total )

Hardware used, other running servers and operating systems will reflect different results. The tests were not run to define maximum performance for all solutions. Each application will apply a different level of stress on the server.

Source code for Lighttz : http://zenebo.com/lighttz.c.tar.gz

Lua version: http://zenebo.com/lighttz_lua.tar.gz

Libev : http://software.schmorp.de/pkg/libev.html

Index.html file was taken from SuperJared.com article located here: http://superjared.com/entry/benching-lighttpd-vs-nginx-static-files/

Advertisements

GUI546 – Pong |. |

Assignment 2 for GUI546 at Seneca College in Graphical User Interface (GUI) Programming

Who doesn’t like Pong ? A breakout hit of epic proportions, Pong has traversed a long and arduous path into our hearts.

The program is written in C++.Net and utilizes basic Windows GDI features to simulate a game of Pong.

Login

Once the program runs, it requires the user to login. Login process creates a flat binary file in the same directory as the executable.

The archive below has one pre-registered user:

Login:demo

Password:demo1!

Implementation

Core of the program is based around learning graphical user interface programming using C++.Net , expanding concepts of threading and communicating a managed application with an unmanaged dynamic link library file. The program loads a previously created unmanaged Win32 .dll file from the ReleaseDll directory.

The program does not attempt to adhere to actual rules of Pong nor does it try to play with intelligence. I like to win , what can I say 🙂

Zip archive is located here: http://zenebo.com/gui546a2.zip

CSC209 – Location Server

Assignment 4 for CSC209 at University of Toronto in Software Tools and Systems Programming

Introduction

One of the interesting features of MSN Messenger is that you can see if a person is online and be able to look up their personal status . Some fields can be used to indicate a status such as : at work or at home

The task in this assignment is to write a server and a client that allows user to register with the server and see which other registered users are on .

Specification

A user will run the heythere client and connect to a heythere-server . Every N seconds, the server will send to the client a list of users that are currently registered and their status.

Client

The client first sends the user name to the server. The second message the client sends to the server is the location of the client . Other messages can be sent to the server. User can change their user name, the location and it may add a message tag .

Every time interval in seconds, the server will send a complete list of the currently logged on users. The client will print these out to stdout .

Each message has a strict format described as following:

First 3 characters describe the type of message the client is sending followed by a space and then the content of the message .

Location: usr

Hostname: loc

Message: tag

Server

Server is written to support up to 30 clients at a time. It uses select to multiplex between different clients. If the command-line arguments -t <time interval> are not given, the default value for the number of seconds between printing to the clients is 10 seconds . Information will be written on line per client in the following format:

<user name> <location> <message tag>

To handle client data, the server collects the information from all connected clients.

Zip archive is located here: http://zenebo.com/csc209a4.zip

CSC209 – build . a simple make-like tool

Assignment 1 for CSC209 course at University of Toronto in Software Tools and Systems Programming

Build

In this assignment a student is required to write a program in Bourne shell that performs some of the same operations that make does . A simpler file format for a build file is specified , which does not follow all rules of the make program .

Build file format

There are 4 types of valid lines in a build file:

1. A blank line. I.e., a line containing nothing but whitespace.
2. A line whose first character is # which indicates that the remainder of the line is a comment.
3. A line whose first character is an @ followed by a space, and then followed by one or more words separated by a single space. This type of line marks the beginning of a build rule. The @ is ignored. The first word in the sequence is the target of the rule, and the remaining words, if any, are the prerequisites for the rule.
4. Other lines are considered action lines which should be executable statements.

In example:
#Comment line
@target prerequisite1 prerequisite2
action
action with arguments


Functionality and Implementation

build program will take one or two arguments. The first argument is the target that you want to build. The second argument is the name of the build file to the program will read. If the second argument is not present, the program will try to read a file in the current working directory called buildfile.

Steps:

1. Read the build file looking for the appropriate rule. If found:
2. Update prerequisites. (as with make, each prerequisite corresponds to a target in the buildfile, so we might need to execute another rule to ensure that a prerequisite is up to date.)
3. If the target is a file and has been modified more recently than all of its prerequisites, then the actions are not executed.
4. If the target is not a file, or any of the prerequisites are newer than the target, then the rule’s actions are executed.

Exceptions:

• If a rule has no prerequisites, then the rule will always be executed when it is encountered. Note that this differs from make where a rule with no prerequisites is only executed if it is called explicitly.
• You don’t need to handle recursive targets and prerequisites.

The build process will likely want to call the build program from within the build program. (Recursion comes in many forms.) The best way to do this is to make sure that build is in a directory in the PATH variable.

Testing

Another obvious use for shell scripts is to automate testing programs. We will also write a shell script called testbuild that will run several tests of the build program.

The testbuild program will run at least 3 different test cases that test different parts of the program. We will also need to include one or more build files and possibly some other files. The touch (see “man touch”) command will come in quite handy when we want to change a file’s modification time automatically.

Zip archive can be obtained here: http://zenebo.com/csc209a1.zip

DSA555 – Peg jump / solitaire solver

Assignment 1 in DSA555 at Seneca College in Data Structures and Algorithms in C++

Peg solitaire is a game where a set amount of pegs are filled in on a board with a set amount of pegs slots. To solve the Solitaire, a player consecutively jumps a peg over another peg , which in turn is emptied out. This process is repeated until there is only one peg on the board.

A C++ program that takes a file name as input . It expects the first line to be in this format:
,
where height and width are valid integers. Using these numbers, it processes the rest of the file using this format:
Character ‘O’ is an empty peg.
Character ‘X’ is a taken peg.

Once the board is parsed , if the board has a solution thus has only one peg left , it will print out the consecutive steps to solve it or it will print “No solution” if a solution can’t be found .

Instructions

Using command prompt: <executable> <test board>

Boards can be downloaded below the source code download link, or a new board can be created as long as it follows above format.

Zip archive is located here: http://zenebo.com/solitaire.zip

Test boards can be downloaded here : http://zenebo.com/solitaire_test_boards.zip

You've been served . Setting up a community game server

On October 9 , 2007 , Valve Software released a long awaited collection of games under an umbrella name called The Orange Box . Titles included in the package are: Half-Life 2, an expansion standalone release named Half-Life 2: Episode One, a continuation of the series titled Half-Life 2: Episode Two, a single-player first-person action/puzzle gem of a game called Portal and Team Fortress 2 .

As the article name suggests, there is a variety of ways to enjoy the sheer goodness that these games have to offer. A frequent course of action is to set-up an online community. An organized , group centric approach offers many rewards to the players as well as to game publishers alike . It cultivates fan created content, fosters online discussions, allows for inter-clan or casual leagues to form and most of all keeps the players connected and organized in an otherwise distant field of online gaming.

The Orange Box exploded into a present form of an online juggernaut . Fueled by constant improvements to the underlying Steam platform, players gain ability to form groups , connect with their friends and merge into distinct groups. Outside of Steam platform, a separate world exists and caters to extend the experience. The dedicated online server communities are the main attraction to more serious gamers . The following paragraphs explain the experience and steps taken to build one of them : The Last Gunslingers , tagged by [TLGS] .

Server Types

An administrator can choose a pre-installed or a self managed solution . The self managed solution is more flexible, usually more expensive and often more hardware specific to its use. Important things to look for are:

• Bandwidth
• RAM
• CPU
• Operating System
• Network Throughput

There could be other factors that can affect the overall performance of the servers , but these are a good start. Let’s look at a general overview of the above.

Bandwidth

A game server needs to be able send and receive packets with the least amount of latency. A data center provided 10 Mbit connection can handle one or multiple server instances running on the same physical machine. A Team Fortress 2 server handling 32 connected players will require similar numbers to the ones below . Server variables that dictate how the server operates may change these dramatically , but overall it is about hitting that performance to price sweet spot .

Rate of data flowing to clients from the server:

2.7 – 3.0 Mbps

This translates to roughly 2.0 – 2.5 Gigabytes of data being sent by the server per hour .

Rate of data flowing to the server from clients:

0.6 – 0.9 Mbps

This translates to roughly 250 Megabytes of data received by the server per hour . These are minimum requirements for a quality sustained connection. A safe practice is to not over saturate the line and leave at least 20% of connection cap free. This will help to eliminate network choke , otherwise known as a network lag .

Summing up possible requirements can be attained by calculating per player / slot network liability .

One player will require on average : 100 Kbps download and 18 Kbps upload .

A common limiting factor is monthly bandwidth allowance . One full server operating 24 hours a day will push about 900 Gigabytes of traffic per month. Most common server carriers will be able to sustain these transfer speeds as well as data transfers.

Above network usage is based on these server variables:

sv_minrate 13000
sv_maxrate 25000
sv_minupdaterate 10
sv_maxupdaterate 33
sv_mincmdrate 10
sv_maxcmdrate 33

Next we’ll look at the other requirements in the equation such as the CPU and RAM , etc.

Main website located at http://orange.half-life2.com contains more information on the Orange Box compilation.

Wikipedia page is located at http://en.wikipedia.org/wiki/The_Orange_Box.

OrangeStats – Team Fortress 2 log file parser

Orange Stats is a Python script that will parse Team Fortress 2 server log files in order to aggregate the data for later use. Regular expressions capture events as written to the log file by the game server. Each event has a corresponding structure containing various information such as : date , time, victim, aggressor, weapon type, event type and other event specific information. Team Fortress 2 adds a vast array of new gameplay and class specific events which extend the Half-Life 2 log file structure. More information can be obtained from Valve Developer Community here.

Orange Stats will insert extracted data into a database for later use by a web front-end or a Team Fortress 2 in-game plugin. The table schema is a bare bones implementation that supports CP map style gameplay. Design requirements focused on simplicity and light weight code implementation. Following game events are captured and categorized :

• Connect
• Disconnect
• Map load
• Join Team
• Point Capture
• Point Capture Block
• Pick Character Class
• Player Death
• Player Assist
• Revenge
• Built Object
• Destroy Object
• Domination
• Steam user events ( user ticket validation )

Character class specific data extraction works for events such as:

• Sapper events, Uber charge events, Engineer object events

A web front-end will be uploaded along with the database schema as soon as possible. Orange Stats working demo can be viewed here . Web front-end features a slight AJAX touch through PrototypeJS .

Back end runs a light PHP script.

Python script is located here .