Free what is benchmarking software for linux

Easy Benchmarking Suite is aimed at testing and benchmarking sites. Basically, the suite can:
- Issue requests to a URL. A benchmark typically consists of a given number of clients that concurrently issue a number of requests. A request can be any HTTP request (GET, POST, HEAD etc.) with all necessary HTTP header information (session cookies, basic authentication information, etc.);
- Get a quick overview of the results of a benchmark: how many trials succeeded, what are the average times for connecting and processing, what is the standard deviation of these times;
- Prepare a GnuPlot command file so that the obtained results can be plotted.
This document describes the suite. Furthermore, manual pages are provided for the separate parts of the suite: sitebench, sitecollect, and siteplot.

The Open CORBA Benchmarking Suite measures several basic performance aspects of various CORBA brokers.
The suite produces an XML output that can be submitted to a searchable database of broker performance data and browsed in a graphical form. The suite is portable to a number of platforms and brokers.
For C++ brokers
Enter the "C++" directory. Then enter the subdirectory of that directory that corresponds to the broker of your choice. Check the README file there for further instructions, usually you will use "make" to compile the benchmark.
For Java brokers
Enter the "Java" and then the "build" directory. Then enter the subdirectory of that directory that corresponds to the broker of your choice. Check the README file there for further instructions, usually you will use "ant" to compile the benchmark "ant run" to execute the benchmark.
Understanding results
The results do not get printed until the benchmark is finished, which can take from 2 to 4 hours depending on the platform. The best way to view the results is to capture them to a file and view them graphically at http://nenya.ms.mff.cuni.cz/~bench.
Enhancements:
- Support for system information on Linux 2.6 kernels.
- Slight extensions to the documentation.
- Support for some recent brokers on Solaris (VisiBroker 6.0, omniORB 4.0.5, JacORB 2.2.1).
- Support for some recent brokers on Linux (omniORB 4.0.5, JacORB 2.2.1, JDK 1.5.0, TAO 1.4.3).

Play What I Mean project allows a user to, from a single commandline or terminal, enter a string, or list of strings, that represent what he/she wishes to have played by whatsoever media player he chooses, the default being MPlayer, and then having that particular item be found and played.
What this essentially means is that if I were to have a sudden hankering to listen to a particular song or video, lets say Ice Pick by The Pillows, which happens to be the song to a particular music video that I enjoy watching. Under the traditional methods of video viewing I would be stuck with two potential courses of action for playing this particular file:
- Change directories several times to that one folder somewhere that I "know" its in, or
- Point and Click my mouse until I find that same directory and then search through what could be countless files to find it.
Each of these prospective choices have their own inherent difficulties and ire. Using the commandline often requires alot of typing to arrive at the desired directory, often times nestled deep within the tree.
Once there your problems only multiply by the number of files you actually store in your "media" folder, try ls | moreing through a heavily populated folder looking for the name of that file you wanted to play sometime, it isnt too fun and further is a waste of my valuable time.
You may be thinking at this point that the second option, the graphical one, must be easier since its exciting, full of pictures, and frankly novel, I disagree. I may not be the best judge on this matter, seeing as how I cant see out of my right eye however, I feel that scanning through a large folder, or folders, full of files is quite a strain on the vision, and more importantly an unnescesary burden on what should be a simple matter.
Main features:
- Nestable Playlist support
- Multi-string arguments
- Transparent command option passing
- Cache for faster access of frequently played files
- Graphical configure

Apache Hello World Benchmarks is a benchmarking tool that seeks to give a sense of Web application execution speed on various software platforms running under the Apache Web server.

Benchmarks can vary greatly from system to system, so this tool allows one to get numbers on ones own platform. Applications tested include mod_perl, mod_php, Tomcat, and Apache::ASP, with over 62 benchmarks in all.

Benchmark Descriptions:

Hello World 2000 ( 2000 )

The 2000 benchmark tries to emulate a heavy web page template. It is typically 3K+ in program length that results in output of over 20K. While this does not properly reflect any web applications speed of back end business logic execution, it does show a template heavy request with some application logic and loops, some HTTP parameter passing, and much variable interpolation in the output stream.

Hello World ( hello )

The Hello World benchmark merely prints "Hello World" and as such is a good test for the fastest a web page could ever run under the given web application environment. For historical reasons, the benchmarks are written to print "Hello" and then add to the output World as a raw string.

HelloDB ( hellodb )

The HelloDB benchmark merely queries the database for the string "Hello World", and as such represents the fastest a web application can process a request when talking to a database. This is a new benchmark with only MySQL supported for now, but more environments and databases will be added over time.

XSLT Big ( xsltbig )

This benchmark hits an XSLT rendering engine hard with 18K+ XML being transformed with a 1K+ XSL stylesheet for over 20K output. Though XSLT is generally slow, many applications will use XSLT caching to speed up response times. This benchmark should emulate well a real world XSLT usage scenario, with perhaps the XSL itself being too trivial.

Hello XSLT ( xslt )

Like the Hello World benchmark, the XSLT version just outputs "Hello World", or the closest we can get when doing XSLT, so it too demonstrates the fastest an application can render a page with XSLT. Benchmarks should be similarly configured between xsltbig and xslt, so a slow caching layer that benefits the former might slow down this benchmark.

GliBench is a Gui based benchmarking tool to check your computers CPU and hard disk performance. The software is based on the benchmarks I developed for CliBench Mk III SMP a SMP enabled benchmark program for Win32.
There were several tries to port it to other architectures than Win32, but this was not that easy. So I decided to to a Linux port, based on the GTK toolkit with Gnome support, as Linux runs on almost every hardware around and GTK is quite easy to port to other OSs.
The CPU tests are all ported to ANSI C. They run fully multithreaded using posix threads. You can already use the program for benchmarking your hardware.
Enhancements:
- The application was completely rewritten for GTK+ 2.x and Glib 2.x.
- New stress tests and threaded I/O tests for benchmarking hard drives are available.
- Both console and GUI interfaces are available.

Web Bench is very simple tool for benchmarking WWW or proxy servers. Uses fork() for simulating multiple clients and can use HTTP/0.9-HTTP/1.1 requests.
This benchmark is not very realistic, but it can test if your HTTPD can realy handle that many clients at once (try to run some CGIs) without taking your machine down.
Displays pages/min and bytes/sec. Can be used in more aggressive mode with -f switch.
Enhancements:
- allow building with both Gnu and BSD make

HTTPD::Bench::ApacheBench is a Perl API for Apache benchmarking and regression testing.

SYNOPSIS

use HTTPD::Bench::ApacheBench;

my $b = HTTPD::Bench::ApacheBench->new;

# global configuration
$b->concurrency(5);
$b->priority("run_priority");

# add HTTP request sequences (aka: runs)
my $run1 = HTTPD::Bench::ApacheBench::Run->new
({ urls => ["http://localhost/one", "http://localhost/two"] });
$b->add_run($run1);

my $run2 = HTTPD::Bench::ApacheBench::Run->new
({ urls => ["http://localhost/three", "http://localhost/four"],
cookies => ["Login_Cookie=b3dcc9bac34b7e60;"],
order => "depth_first",
repeat => 10,
memory => 2 });
$b->add_run($run2);

# send HTTP request sequences to server and time responses
my $ro = $b->execute;

# calculate hits/sec
print ((1000*$b->total_requests/$b->total_time)." req/secn");

# show request times (in ms) for $run1, 1st repetition
print join(, , @{$run1->request_times}) . "n";

# show response times (in ms) for $run2, 7th repetition
print join(, , @{$run2->iteration(6)->response_times}) . "n";

# dump the entire regression object (WARNING, this could be a LOT OF DATA)
use Data::Dumper;
my $d = Data::Dumper->new([$ro]);
print $d->Dumpxs;

GOALS

This project is meant to be the foundation of a complete benchmarking and regression testing suite for an advanced, transaction-based mod_perl site. We need to be able to stress our server to its limit while also having a way to verify the HTTP responses for correctness. Since our site is transaction-based (as opposed to content-based), we needed to extend the single-URL ab model to a multiple-URL sequence model.

ApacheBench is based on the Apache 1.3.12 ab code (src/support/ab.c).

Note: although this tool was designed to be used on an Apache mod_perl site, it is generally applicable to any HTTP-compliant server. Beware, however, that it sends a high volume of HTTP requests in a very short period of time, which may overwhelm some weaker HTTP server implementations like NT/IIS.

ApacheBench sends sequences of HTTP requests to an HTTP server and keeps track of the time taken to receive a response, the data that was returned, the size of the data that was returned, and various other bits of information.
Since it is implemented in C, it sends HTTP requests in a tight loop which can stress your server to 100% capacity, especially if invoked in multiple concurrent instances. It gives accurate time measurements down to the millisecond for each HTTP request-response interval.

Included is a simplified re-implementation of ab using the ApacheBench Perl API. This should help get you started with ApacheBench.

Interbench is benchmark application is designed to benchmark interactivity in Linux.
Interbench is designed to measure the effect of changes in Linux kernel design or system configuration changes such as I/O scheduler, cpu and filesystem changes and options. With careful benchmarking, different hardware can be compared.
What does it do?
It is designed to emulate the cpu scheduling behaviour of interactive tasks and measure their scheduling latency and jitter. It does this with the tasks on their own and then in the presence of various background loads, both with configurable nice levels and the benchmarked tasks can be real time.
How does it work?
First it benchmarks how best to reproduce a fixed percentage of cpu usage on the machine currently being used for the benchmark. It saves this to a file and then uses this for all subsequent runs to keep the emulation of cpu usage constant.
It runs a real time high priority timing thread that wakes up the thread or threads of the simulated interactive tasks and then measures the latency in the time taken to schedule. As there is no accurate timer driven scheduling in linux the timing thread sleeps as accurately as linux kernel supports, and latency is considered as the time from this sleep till the simulated task gets scheduled.
Each benchmarked simulation runs as a separate process with its own threads, and the background load (if any) also runs as a separate process.
Enhancements:
- This release adds options to select benchmarked loads, manpages, and documentation updates.