Free benchmarking espa ol software for linux

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).

Objective of this project to provide benchmarking toolset for all available multiplatform C/C++ (and some Java) XML parsers.
Main features:
Currently following parsers are supported:
- LibXML2 + GDome + LibXSLT + XML Security
- Apache Xerces for C + Apache Xalan for C + Apacge XML Security for C
- IBM XML4C + IBM Lotus XSL
- Expat + CenterPoint XML + Sablotron + Arabica
- RXP Parser
- Oracle XDK for C/C++
- Oracle XDK for Java
- QT XML Module
- Sun Crismon + Java WebServices Developer Pack 1.2 + Apache XML Security
Following separate benchmarks provided:
- Non-Validating Parsing with Native,SAX,DOM Engines Benchmark
- Creating + Serializing DOM treee Benchmark
- Schema Validation Benchmark
- XSL Transformation Benchmark
- XML Security (Signature, Encryption) Benchmark
Following XML sources supported:
- Any valid XML file (with optional XSL, XSD companions)
- Auto-generated random simple XML file (variable size)
- Auto-generated random XML OPC-DA message sequence (variable size and length
Enhancements:
- Support Apache XML Security for C++, Version: CVS 08.02.2004
- Experemental support for XML Encryption Benchmark for Apache XML Security for C++ from CVS tree.
- Tested againist latest libraries

The Bioinformatics Benchmark System is an attempt to build a reasonable testing framework, tests, and data, to enable end users and vendors to probe the performance of their systems.

What we are trying to do is to create a framework for testing, and a core set of tests that all may download and use to probe specific elements of systems performance.

Moreover, the source to these tests are available under GPL, and are hosted on Bioinformatics.org and Scalable Informatics LLC The idea is to enable end users, consumers, systems developers, and others to easily build and use meaningful tests for measurement and tuning reasons.

Joe Landman from Scalable Informatics LLC conceived the idea and wrote the original codes. We are looking for additional benchmark code suggestions, tests, data sets, etc.

Current baseline tests are several NCBI BLAST runs, several HMMer runs, and a variety of others. We plan to include ClustalW, X!Tandem, various chemistry, dynamics, and related tests, as well as several others.

Tests such as LINPACK or HPL simply do not provide meaningful performance indicators or predictive models for high performance informatics. Unfortunately, nor do a number of more recent and focused tests.

This is a problem as LINPACK and HPL specifically test the performance on various matrix operations, where you have effectively regular memory access patterns, and specific mathematical operations.

These codes are most useful for comparison to codes with heavy floating point operations, and interleaved memory traffic. These codes were not designed for comprehensive systems benchmarking, where disk I/O, memory latency, and other factors all contribute to the performance issues.

The best tests are the ones that are most similar to the codes you will run on the machine. The tests themselves should be reasonable approximations to a real execution of your code, using real data. You may need to pare it back in order to get realistic run times.

You should have a reasonable subset of data sizes. A single test does not tell you how your system scales, and one of the reasons for the existance of this test is specifically to allow you to test the performance while you increase various aspects of the workload.

You rarely get a quiescent system in a cluster, so we would recommend that you try to run in as realistic an operating environment as possible. A baseline in a quiescent system is fine, but it may set your expectations unreasonably.
top

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.

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.

OpenLink ODBC Bench is an open-source ODBC Benchmarking tool providing real-time comparative benchmarking for ODBC Drivers, Database Engines, and Operating Systems combinations.

The Benchmarks in this application are loosely based on the TPC-A and TPC-C standard benchmarks, with modifications to specifically test the performance of an ODBC Driver and/or Database Engine in a client/server environment.

The benchmark results can be automatically stored to an ODBC Datasource or XML file for further analysis and comparisons to be made.

ODBC-Bench is licensed under the terms of the GNU General Public License version 2.