Free pc benchmark software for linux

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

Cache::Benchmark is a Perl module that tests the quality and speed of a cache module to compare cachemodules and algorithms.

SYNOPSIS

use Cache::Benchmark();
use Cache::MemoryCache();
use Cache::SizeAwareMemoryCache();

my $cache_1 = new Cache::MemoryCache({
namespace => my,
default_expires_in => 1,
});
my $cache_2 = new Cache::SizeAwareMemoryCache({
namespace => my,
default_expires_in => 1,
max_size => 400,
});

my $test = new Cache::Benchmark();
$test->init( access_counter => 10_000 );

$test->run($cache_1);
print $test->get_printable_result();

$test->run($cache_2);
print $test->get_printable_result();

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

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.

Procbench is a multiplatform information tool and CPU benchmark for x86 processors. This application tests memory transfer and math capabilities of your x86 processor.
Main features:
- Identification of CPU by CPUID.
- Approximation of CPU MHz.
- Benchmarks.
Installation:
type:
make install
try:
./procbench -h
for information
Enhancements:
- DB of CPUs added.

PHPBench provides a benchmark suite for PHP.
It performs a large number of simple tests in order to bench various
aspects of the PHP interpreter.
PHPBench can be used to compare hardware, operating systems, PHP versions, PHP accelerators and caches, compiler options, etc.
Custom tests can be easily added to the suite.
In order to get accurate results, every test is evaluated more than once.
By defaut, tests are evaluated 100000 times, or multiples of that value for
some tests that are known to be CPU-expensive or other tests that are known to be very fast.
If you have slow hardware or very fast hardware, you can change the number
of iterations, with the -i switch:
./phpbench.php -i 5000
he score you get when the benchmark completes is a ratio between the number of iterations and the total time that was needed to perform all tests.
Thus, the score should be independant of the number of iterations, but the higher number you use, the more accuracy you will get.
Enhancements:
- The regression test of test_bitwise has been fixed for 64-bits CPUs.

dkftpbench application is an FTP benchmark program inspired by SPECweb99. The result of the benchmark is a number-of-simultaneous-users rating; after running the benchmark properly, you have a good idea how many simultaneous dialup clients a server can support. The target bandwidth per client is set at 28.8 kilobits/second to model dialup users; this is important for servers on the real Internet, which often serve thousands of clients on only 10 MBits/sec of bandwidth.
The final result of the benchmark is "the number of simultaneous 28.8 kilobits/second dialup users". To estimate this number, the benchmark starts up a new simulated user as soon as the last one has finished connecting. It stops increasing the number of users when one fails to connect, fails to maintain the desired bandwidth, or the limit specified by the -n option is reached. It runs the simulated users until the amount of time specified by the -t option has elapsed since the last simulated user birth or death; the final score is the number of users still alive at the end.
Main features:
- Compiles and runs on Linux, FreeBSD, and Solaris (or did, last I tried)
- fetches many files in parallel
- waits for each connect to finish (and then a bit) before starting next one; slows down to < 1 connect/second when it reaches 75% of desired number of users. This spreads out user activity more evenly.
- checks bandwidth continuously during each file fetch, stops adding users if any fetch too slow
- throttles each fetch to use only the specified bandwidth
- search for the max number of supported users
- Displays verbose error message when any user fails
- Aborts if it detects the client system running out of resources
- Aborts if connecting to the server takes > 5 seconds
- Aborts if it takes longer than 5 seconds to get first packet of a file
- Uses new Poller class for scalability; you can specify which Poller to use on the commandline
- Supports slow datarates (before, it only handles rates above 80kbits/sec on some systems)
- Lets you set how picky it is about datarates (before, its must be faster than threshold was fixed at 3/4 the target bandwidth)
- Supports alternative readiness notification methods like O_ASYNC and O_ONESIGFD
- Provided both as a standalone executable, and as a Corba object. (Thanks to http://corbaconf.kiev.ua/ for the Corba autoconf macros.
- Switches to BINARY mode after login. (The client API lets you choose; edit robouser.cc to skip the START_TYPE state if you want to use ASCII.)
Example:
After unpacking the sources, configure them for your system with the command
./configure
This will generate Makefile from Makefile.in.
To make sure the sources arrived intact and work properly on your system, type
make check
It will build all unit tests, and fail if any unit test fails. You must be connected to the Internet, as this will try to download a file from ftp.uu.net.
To build the system tuning tool dklimits, type
make dklimits
Run it on both the client and the server machine; make sure that the number of files it can open is about three times the desired number of users, and that the number of ports it can bind is higher than the desired number of users. You should not be running X Windows or any other programs on the client and server machines when running the benchmark.
To build the benchmark, type
make
This produces the executable dkftpbench, the tuning program dklimits, and a bunch of unit tests (executables with names ending in _test) that you can ignore for now.
Heres a simple use of dkftpbench:
./dkftpbench -n1 -hftp.uu.net -t15 -v
This tells bench to simulate one user fetching the default file from ftp.uu.net repeatedly, and stop after fifteen seconds. The program produces this output:
Option values:
-hftp.uu.net host name of ftp server
-P21 port number of ftp server
-n1 number of users
-t15 length of run (in seconds)
-b3600 desired bandwidth (in bytes per second)
-uanonymous user name
-probouser@ user password
-fusenet/rec.juggling/juggling.FAQ.Z file to fetch
-m1500 bytes per packet
-v1 verbosity
1 users
User0: fetching 22708 bytes took 6.530000 seconds, 3477 bytes per second
User0: fetching 22708 bytes took 6.530000 seconds, 3477 bytes per second
Test over. 1 users left standing.