Java Management Extensions:
http://javaboutique.internet.com/tutorials/JavaManagementExtensions/
Introduction:
Imagine a system that has pluggable modules included into it, that you could expand on as needed. Add to that the capability of integrating seamlessly with existing applications and leveraging on their power. All the ideas above and much more form the gist of what JMX or Java Management Extensions wishes to bring to the Java world.
In technical terms the Java Management Extensions provides an architecture and API for application management and network management using the Java programming language. It allows Integrators to integrate independent Java agent modules into existing systems.
Architecture
The two most important components of the JMX specifications are the Instrument Level and the Agent Level. The instrumentation level is a specification that defines the implementation of JMX manageable resources. A JMX manageable resource can be an application, a service or a device. The only condition is that the resource needs to be written in Java or should have a Java wrapper. It also should have been instrumented so that it can be managed by JMX complaint applications. The instrumentation is provided by Managed beans or MBeans. The instrumentation layer creates resources so that they can be managed by Management agents. The MBeans are designed to be generic, flexible and easy to implement. They do not require the user to know the JMX agents they would operate on. Apart from these, the instrumentation specification provides a mechanism to notify events, this allows MBeans to generate and notify other components of events.
The agent level defines the specification for implementing Management agents. Management agents or MBeans control the resources and make them available to the other applications. This level acts as an interface to the instrumentation layer by providing a standardized agent to manage the JMX resources. An agent consists of an MBean server and a set of services to handle MBeans. JMX agents provide the infrastructure and API for developers to use MBeans or resources provided by the MBean server. They need not know about the internal implementation of these resources or MBeans. The instrumentation specification and the agent specification are discussed in more detail below.
Instrumentation Layer:
The main components of the instrumentation layer are the MBeans, the Notification model and the MBean metadata classes.
MBeans: An MBean is a concrete Java class that includes the implementation of its own MBean interface or an implementation of the DynamicMBean interface. It can also optionally implement the NotificationBroadcaster interface.
A class that implements its own MBean interface is referred to as a standard MBean. This is the simplest type of instrumentation available when developing new JMX manageable resources. An MBean that implements the DynamicMBean interface is known as a dynamic MBean, because certain elements of its instrumentation can be controlled at runtime. The type of MBean determines how the MBean is deployed on the MBean Server but it has no effect on how the bean is managed. JMX agents are designed to shield the type of MBean and provide a standard interface. The end user is transparent to the type of bean.
A standard MBean consists of attributes and operations. The attributes can be accessed using getter and setter methods. The operations are static methods in the MBean interface and are visible to JMX agents using introspection. The Dynamic MBean allows manipulations on its methods through generic invocation methods. The method could take the name of the attribute or the operation as a parameter.
Notification Model: Usually management applications need to react to state changes or to specific conditions when they occur in an underlying resource. The Notification Model defines a model that allows MBeans to broadcast such management events, called notifications. Management applications and other objects register as listeners with the broadcaster MBean. The MBean Notification Model of JMX enables a listener to register only once and still receive all the different events that might occur in the broadcaster.
The JMX Notification Model uses a generic class called Notification to define an event type. This class may be sub- classed to represent specific types of events. The generic event type allows a single listener to receive numerous notifications from different types of notification types. Objects desiring to receive notifications sent by MBeans must implement the NotificationListener interface. MBeans that want to broadcast notifications have to implement the NotificationBroadcaster interface, so that it can allow listeners to register themselves with the MBean to receive notifications. Any type of MBean, standard or dynamic, can be either a notification broadcaster, a notification listener, or both at the same time.
MBean Metadata Classes: The MBean metadata defines the classes that describe an MBean. These classes are used both for the introspection of standard MBeans and for the self description of all dynamic MBeans. These classes describe the management interface of an MBean in terms of its attributes, operations, constructors and notifications. The JMX agent exposes all its MBeans, regardless of their type, through the MBean metadata classes. All clients, whether management applications or other local MBeans viewing the management interface of an MBean, need to be able to interpret these objects and their constructs.
Important MBean Metadata classes are described below:
MBeanInfo class: This class is used to fully describe an MBean: its attributes, operations, constructors, and the notification types it can send. It describes the MBean's overall purpose or functionality.
MBeanFeatureinfo class: This class is the parent of all the other component metadata classes. It contains two methods getName() and getDescription() which return the name and a readable string description of the component.
MBeanAttributeInfo class: The MBeanAttributeInfo class describes an attribute in the MBean's management interface. An attribute is characterized by its type and how it is accessed. This type of an attribute is the Java class that is used to represent it when calling its getter or setter methods. The getType() method returns a string containing the fully qualified name of this class.
MBeanOperationInfo class: The MBeanOperationInfo class describes an individual operation of an MBean. An operation is defined by its signature, return type, and its impact.
MBeanParameterInfo class: The MBeanParameterInfo class is used to describe a parameter of an operation or a constructor.
MBeanNotificationInfo class: The MBeanNotificationInfo class is used to describe the notifications that are sent by an MBean. The getNotifTypes method returns an array of strings containing the notification types that the MBean can emit.
Agent Layer:
A JMX agent is a management entity that runs in a Java Virtual Machine (JVM) and acts as the bridge between the MBeans and the management application. A JMX agent is composed of an MBean server, a set of MBeans representing managed resources, a minimum number of agent services implemented as MBeans, and typically at least one protocol adaptor or connector.
The key components in the JMX agent architecture can be further defined as follows: The MBean server and Agent services can either be components defined in this specification or services developed by third parties.
The agent service MBeans defined by the JMX specification further provide dynamic loading services that allow the agent to instantiate MBeans using Java classes and native libraries dynamically downloaded from the network. These include monitoring capabilities for attribute values in MBeans, a timer service that can send notifications at predetermined intervals and act as a scheduler, and a relation service that defines associations between MBeans and maintains the consistency of the relation
MBean Server: The Managed Bean server, or MBean server is the core component of the Java Management Extensions (JMX) agent infrastructure. The MBean server is a registry for MBeans in the agent. The MBean server is the component that provides the services for manipulating MBeans. All management operations performed on the MBeans are done through the MBeanServer interface.
In general the MBean server registers MBeans that represent resources used for management purposes or Mbeans that add management functionality to the agent. Some components of the infrastructure, such as the connector clients and protocol adaptors, can be implemented as MBeans. This allows such components to benefit from the dynamic management infrastructure.
A JMX agent has a factory class for finding or creating an MBean server through the factory's static methods. This allows more flexible agent applications and possibly more than one MBean server in an agent.
MBeans can be registered either by the agent application, or by other MBeans. The interface of the MBeanServer class allows two different kinds of registration. The first one is the instantiation of a new MBean and registration of this MBean in a single operation. The second is the registration of an already existing MBean instance.
Agent Services:
Advanced Dynamic Loading: Dynamic loading is usually performed by the management applet (m-let) service that is used to instantiate MBeans. These MBeans are obtained from a remote URL on the network. The Java Management Extensions (JMX) specification also defines lower-level mechanisms for class loading. These allow developers to extend the functionality of the m-let service or to load classes without it.
The m-let service allows you to instantiate and register one or more MBeans from a remote URL, in the MBean server. The m-let service does this by loading an m-let text file, that specifies information on the MBeans to be obtained. The information on each MBean is specified in a tag similar to those used in XML, called the MLET tag. The location of the m-let text file is specified by a URL. When an m-let text file is loaded, all classes specified in MLET tags are downloaded, and an instance of each MBean specified in the file is created and registered.
The m-let service is itself implemented as an MBean and registered in the MBean server. This way it can be used by other MBeans, by the agent application, or by remote management applications.
Monitoring :
The JMX specification allows using a monitoring service to monitor the observed attribute of one or more other MBeans at intervals specified by the granularity period. For each observed MBean, the monitor derives a value from this observation, called the derived gauge. This derived gauge is either the exact value of the observed attribute, or optionally, the difference between two consecutive observed values of a numeric attribute.
A specific notification type is sent by each of the monitoring services when the value of the derived gauge satisfies one of a set of conditions. The conditions are specified when the monitor is initialized, or dynamically through the monitor MBean's management interface. Monitors can also send notifications when certain error cases are encountered while monitoring an attribute value.
Timer Service:
The timer service triggers notifications at specific dates and times. It can also trigger notifications repeatedly at a constant interval. The notifications are sent to all objects registered to receive notifications emitted by the timer. The timer service is an MBean that can be managed, allowing applications to set up a configurable scheduler.
Conceptually, the Timer class manages a list of dated notifications that are sent when their date and time arrives. Methods of this class are provided to add and remove notifications from the list. In fact, the notification type is provided by the user, along with the date and optionally a period and the number of repetitions. The timer service always sends the notification instances of its specific TimerNotification class.
Relation Service:
As part of the agent specification, the Java Management Extensions (JMX) specification also defines a model for relations between MBeans. A relation is a user defined, n-ary association between MBeans in named roles. The JMX specification defines the classes that are used to construct an object representing a relation. It also defines the relation service that centralizes all operations on relations in an agent. All relations are defined by a relation type that provides information about the roles it contains, such as their multiplicity, and the class name of MBeans that satisfy the role. Through the relation service, users create new types and then create, update, or remove relations that satisfy these types. The relation service also performs queries among all relations to find related MBeans.
The relation service maintains the consistency of relations, checking all operations and all MBean deregistrations to ensure that a relation always conforms to its relation type. If a relation is no longer valid, it is removed from the relation service, though its member MBeans continue to exist otherwise.
Conclusion
Most application servers in the market today either implement the JMX specification or have them on their agenda. However the specification has not been in popular use. It might take some time for the developer community to embrace JMX and use them for real time applications. This article should have introduced the reader to the basic concept of JMX and the important aspects of it. For more information please refer to the JMX 1.2 Specification found on the Java site and the accompanying reference implementation.
References:
The JMX Specification
Sunday, July 5, 2009
Java MBean - JVM Monitoring and Management
http://java.sun.com/j2se/1.5.0/docs/guide/management/overview.html
Monitoring and Management Using JMX:
Java Management Extensions (JMX):
http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html
Monitoring and Management APIs
The java.lang.management package provides the interface for monitoring and managing the JVM.
The API provides access to information such as:
Number of classes loaded and threads running
Virtual machine uptime, system properties, and JVM input arguments
Thread state, thread contention statistics, and stack trace of live threads
Memory consumption
Garbage collection statistics
Low memory detection
On-demand deadlock detection
Operating system information
What are MBeans?
MBeans are managed beans, Java objects that represent resources to be managed. An MBean has a management interface consisting of:
Named and typed attributes that can be read and written
Named and typed operations that can be invoked
Typed notifications that can be emitted by the MBean
For example, an MBean representing an application's configuration could have attributes representing the different configuration parameters, such as a cache size. Reading the CacheSize attribute would return the current size of the cache. Writing CacheSize would update the size of the cache, potentially changing the behavior of the running application. An operation such as save could store the current configuration persistently. The MBean could send a notification such as ConfigurationChangedNotification when the configuration changes.
MBeans can be standard or dynamic. Standard MBeans are Java objects that conform to design patterns derived from the JavaBeans component model. Dynamic MBeans define their management interface at runtime.
A standard MBean exposes the resource to be managed directly through its attributes and operations. Attributes are exposed through "getter" and "setter" methods. Operations are the other methods of the class that are available to managers. All these methods are defined statically in the MBean interface and are visible to a JMX agent through introspection. This is the most straightforward way of making a new resource manageable.
A dynamic MBean is an MBean that defines its management interface at runtime. For example, a configuration MBean could determine the names and types of the attributes it exposes by parsing an XML file.
Monitoring and Management Using JMX:
Java Management Extensions (JMX):
http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html
Monitoring and Management APIs
The java.lang.management package provides the interface for monitoring and managing the JVM.
The API provides access to information such as:
Number of classes loaded and threads running
Virtual machine uptime, system properties, and JVM input arguments
Thread state, thread contention statistics, and stack trace of live threads
Memory consumption
Garbage collection statistics
Low memory detection
On-demand deadlock detection
Operating system information
What are MBeans?
MBeans are managed beans, Java objects that represent resources to be managed. An MBean has a management interface consisting of:
Named and typed attributes that can be read and written
Named and typed operations that can be invoked
Typed notifications that can be emitted by the MBean
For example, an MBean representing an application's configuration could have attributes representing the different configuration parameters, such as a cache size. Reading the CacheSize attribute would return the current size of the cache. Writing CacheSize would update the size of the cache, potentially changing the behavior of the running application. An operation such as save could store the current configuration persistently. The MBean could send a notification such as ConfigurationChangedNotification when the configuration changes.
MBeans can be standard or dynamic. Standard MBeans are Java objects that conform to design patterns derived from the JavaBeans component model. Dynamic MBeans define their management interface at runtime.
A standard MBean exposes the resource to be managed directly through its attributes and operations. Attributes are exposed through "getter" and "setter" methods. Operations are the other methods of the class that are available to managers. All these methods are defined statically in the MBean interface and are visible to a JMX agent through introspection. This is the most straightforward way of making a new resource manageable.
A dynamic MBean is an MBean that defines its management interface at runtime. For example, a configuration MBean could determine the names and types of the attributes it exposes by parsing an XML file.
Jython - Scripting Language
http://wiki.python.org/jython/JythonFaq/GeneralInfo
http://wiki.python.org/jython/UserGuide
What is JPython?
JPython is an implementation of the Python programming language which is designed to run on the Java(tm) Platform. It consists of a compiler to compile Python source code down to Java bytecodes which can run directly on a JVM, a set of support libraries which are used by the compiled Java bytecodes, and extra support to make it trivial to use Java packages from within JPython. JPython has been renamed and superseded by Jython.
What is Jython?
Jython is the successor to JPython. The Jython project was created in accordance with the CNRI JPython 1.1.x license, in order to ensure the continued existence and development of this important piece of Python software. The intent is to manage this project with the same open policies that are serving CPython so well.
Mailing lists, CVS and all current information on the Jython project is available at SourceForge, at http://sourceforge.net/projects/jython
http://wiki.python.org/jython/UserGuide
What is JPython?
JPython is an implementation of the Python programming language which is designed to run on the Java(tm) Platform. It consists of a compiler to compile Python source code down to Java bytecodes which can run directly on a JVM, a set of support libraries which are used by the compiled Java bytecodes, and extra support to make it trivial to use Java packages from within JPython. JPython has been renamed and superseded by Jython.
What is Jython?
Jython is the successor to JPython. The Jython project was created in accordance with the CNRI JPython 1.1.x license, in order to ensure the continued existence and development of this important piece of Python software. The intent is to manage this project with the same open policies that are serving CPython so well.
Mailing lists, CVS and all current information on the Jython project is available at SourceForge, at http://sourceforge.net/projects/jython
The grinder - open source load testing framework
http://grinder.sourceforge.net/g3/tutorial-perks.html
http://www.oreillynet.com/xml/blog/2005/03/load_testing_web_services_with.html
http://grinder.sourceforge.net/g3/tutorial-perks.pdf
http://www.anticlue.net/archives/000395.htm
http://pierrerebours.com/blog/load-testing-using-grinder
The grinder is an open source load testing framework. I went very out of character and utilized the Beta version, grinder 3, because it uses Jython to write scripts. With the grinder 3, you can load test anything; databases, messaging services, web apps, web services, etc. I?m hoping to utilize the grinder 3 to load test Quovadx/Cloverleaf Interface Engine, the Siemens Soarian Clinical Access, Crystal Enterprise 10, 3M?s Encoder, and several other applications.
Installing the Grinder 3
1. First ensure java is installed on the machine where you will be running the scripts. If not, please download from here.
2. Download and unzip the grinder 3 from here.
3. Download the jython2.1 class file.
4. Add the grinder.jar to your CLASSPATH variable.
- Set CLASSPATH=%CLASSPATH%;c:\grinder-3.0-beta23\lib\grinder.jar
5. Install the jython2.1 class file.
- Java jython2-1
Aside: Remember the directory and set it in the grinder.properties file
To get into the Grinder console, run java net.grinder.Console. You can find more about the console here. I'm not very big on the GUI, but it does its job.
Recording Web App test scripts
Hand coding the test scripts would get to be very trying in a very short time. In order to maintain one?s sanity, exploit the TCPProxy httpplugin to record scripts.
1. First, set up IE to temporarily use a proxy server.
- Menu -> Tools -> Internet Options -> Connections tab
- Click on Lan Settings button
- Check the use a proxy server for your lan setting
- Click on Advanced button
- Set the http proxy address to use to be localhost, port 8001
- Set the secure proxy address to use to be localhost, port 8001
2. Fire off the TCPProxy within grinder.
- java net.grinder.TCPProxy ?console ?httpplugin
3. Surf away with the IE session, and you will have all actions recorded.
4. Click Stop Recording on the TCPProxy Window, when you are done.
5. Remove the changes to the IE Browser, unchecking using a proxy server.
6. You will notice within the directory there is a httpscript.py and a httpscript_tests.py file. These are your test scripts.
A quick aside point is that if you don?t want to switch setting, one could always leave ie in the record mode and surf the web with firefox.
Running the test scripts
A key thing to remember when you are running your test scripts, set up multiple grinder sessions on multiple machines. This way everyone isn?t using the same network interface.
1. Set up resource monitoring with performance monitor on the server, and client machine.
2. To run the grinder test scripts;
- In the same directory have a grinder.properties, this file contains the configuration settings
- Also within that directory, have the script you would like to run. For our example, find the httpscript.py and httpscript_tests.py files.
- run java net.grinder.Grinder, from that directory.
http://www.oreillynet.com/xml/blog/2005/03/load_testing_web_services_with.html
http://grinder.sourceforge.net/g3/tutorial-perks.pdf
http://www.anticlue.net/archives/000395.htm
http://pierrerebours.com/blog/load-testing-using-grinder
The grinder is an open source load testing framework. I went very out of character and utilized the Beta version, grinder 3, because it uses Jython to write scripts. With the grinder 3, you can load test anything; databases, messaging services, web apps, web services, etc. I?m hoping to utilize the grinder 3 to load test Quovadx/Cloverleaf Interface Engine, the Siemens Soarian Clinical Access, Crystal Enterprise 10, 3M?s Encoder, and several other applications.
Installing the Grinder 3
1. First ensure java is installed on the machine where you will be running the scripts. If not, please download from here.
2. Download and unzip the grinder 3 from here.
3. Download the jython2.1 class file.
4. Add the grinder.jar to your CLASSPATH variable.
- Set CLASSPATH=%CLASSPATH%;c:\grinder-3.0-beta23\lib\grinder.jar
5. Install the jython2.1 class file.
- Java jython2-1
Aside: Remember the directory and set it in the grinder.properties file
To get into the Grinder console, run java net.grinder.Console. You can find more about the console here. I'm not very big on the GUI, but it does its job.
Recording Web App test scripts
Hand coding the test scripts would get to be very trying in a very short time. In order to maintain one?s sanity, exploit the TCPProxy httpplugin to record scripts.
1. First, set up IE to temporarily use a proxy server.
- Menu -> Tools -> Internet Options -> Connections tab
- Click on Lan Settings button
- Check the use a proxy server for your lan setting
- Click on Advanced button
- Set the http proxy address to use to be localhost, port 8001
- Set the secure proxy address to use to be localhost, port 8001
2. Fire off the TCPProxy within grinder.
- java net.grinder.TCPProxy ?console ?httpplugin
3. Surf away with the IE session, and you will have all actions recorded.
4. Click Stop Recording on the TCPProxy Window, when you are done.
5. Remove the changes to the IE Browser, unchecking using a proxy server.
6. You will notice within the directory there is a httpscript.py and a httpscript_tests.py file. These are your test scripts.
A quick aside point is that if you don?t want to switch setting, one could always leave ie in the record mode and surf the web with firefox.
Running the test scripts
A key thing to remember when you are running your test scripts, set up multiple grinder sessions on multiple machines. This way everyone isn?t using the same network interface.
1. Set up resource monitoring with performance monitor on the server, and client machine.
2. To run the grinder test scripts;
- In the same directory have a grinder.properties, this file contains the configuration settings
- Also within that directory, have the script you would like to run. For our example, find the httpscript.py and httpscript_tests.py files.
- run java net.grinder.Grinder, from that directory.
Load Runner
http://en.wikipedia.org/wiki/LoadRunner
LoadRunner is a performance and load testing product by Hewlett-Packard (since it acquired Mercury Interactive in November 2006) for examining system behaviour and performance, while generating actual load. LoadRunner can emulate hundreds or thousands of concurrent users to put the application through the rigors of real-life user loads, while collecting information from key infrastructure components (Web servers, database servers etc). The results can then be analysed in detail, to explore the reasons for particular behaviour.
Consider the client-side application for an automated teller machine (ATM). Although each client is connected to a server, in total there may be hundreds of ATMs open to the public. There may be some peak times — such as 10 a.m. Monday, the start of the work week — during which the load is much higher than normal. In order to test such situations, it is not practical to have a testbed of hundreds of ATMs. So, given an ATM simulator and a computer system with LoadRunner, one can simulate a large number of users accessing the server simultaneously. Once activities have been defined, they are repeatable. After debugging a problem in the application, managers can check whether the problem persists by reproducing the same situation, with the same type of user interaction.
Working in LoadRunner involves using three different tools which are part of LoadRunner. They are Virtual User Generator (VuGen), Controller and Analysis.
LoadRunner is a performance and load testing product by Hewlett-Packard (since it acquired Mercury Interactive in November 2006) for examining system behaviour and performance, while generating actual load. LoadRunner can emulate hundreds or thousands of concurrent users to put the application through the rigors of real-life user loads, while collecting information from key infrastructure components (Web servers, database servers etc). The results can then be analysed in detail, to explore the reasons for particular behaviour.
Consider the client-side application for an automated teller machine (ATM). Although each client is connected to a server, in total there may be hundreds of ATMs open to the public. There may be some peak times — such as 10 a.m. Monday, the start of the work week — during which the load is much higher than normal. In order to test such situations, it is not practical to have a testbed of hundreds of ATMs. So, given an ATM simulator and a computer system with LoadRunner, one can simulate a large number of users accessing the server simultaneously. Once activities have been defined, they are repeatable. After debugging a problem in the application, managers can check whether the problem persists by reproducing the same situation, with the same type of user interaction.
Working in LoadRunner involves using three different tools which are part of LoadRunner. They are Virtual User Generator (VuGen), Controller and Analysis.
Load Testing Online Video Tutorial
Load Testing with the Web Performance Suite: Quick Start
http://www.youtube.com/watch?v=8ihQJkTvElQ
http://www.webperformanceinc.com/
Apache JMeter
http://www.youtube.com/watch?v=eAksSWSDCP8&feature=related&pos=0
http://www.youtube.com/watch?v=KI6u5pclYIw&NR=1
http://www.youtube.com/watch?v=8ihQJkTvElQ
http://www.webperformanceinc.com/
Apache JMeter
http://www.youtube.com/watch?v=eAksSWSDCP8&feature=related&pos=0
http://www.youtube.com/watch?v=KI6u5pclYIw&NR=1
Load Testing Tools
http://www.opensourcetesting.org/performance.php
Apache JMeter
http://jakarta.apache.org/jmeter/
Description:
Apache JMeter is a 100% pure Java desktop application designed to load test functional behavior and measure performance. It was originally designed for testing Web Applications but has since expanded to other test functions. Apache JMeter may be used to test performance both on static and dynamic resources (files, Servlets, Perl scripts, Java Objects, Data Bases and Queries, FTP Servers and more). It can be used to simulate a heavy load on a server, network or object to test its strength or to analyze overall performance under different load types. You can use it to make a graphical analysis of performance or to test your server/script/object behavior under heavy concurrent load.
Requirement:
Solaris, Linux, Windows (98, NT, 2000). JDK1.4 (or higher).
Download data:
No data feed available
-------------------------------------------------------------
Grinder
http://grinder.sourceforge.net/
Description:
The Grinder is a Java load-testing framework making it easy to orchestrate the activities of a test script in many processes across many machines, using a graphical console application.
Requirement:
OS Independent
Download data:
Downloadable files: 201699 total downloads to date
Apache JMeter
http://jakarta.apache.org/jmeter/
Description:
Apache JMeter is a 100% pure Java desktop application designed to load test functional behavior and measure performance. It was originally designed for testing Web Applications but has since expanded to other test functions. Apache JMeter may be used to test performance both on static and dynamic resources (files, Servlets, Perl scripts, Java Objects, Data Bases and Queries, FTP Servers and more). It can be used to simulate a heavy load on a server, network or object to test its strength or to analyze overall performance under different load types. You can use it to make a graphical analysis of performance or to test your server/script/object behavior under heavy concurrent load.
Requirement:
Solaris, Linux, Windows (98, NT, 2000). JDK1.4 (or higher).
Download data:
No data feed available
-------------------------------------------------------------
Grinder
http://grinder.sourceforge.net/
Description:
The Grinder is a Java load-testing framework making it easy to orchestrate the activities of a test script in many processes across many machines, using a graphical console application.
Requirement:
OS Independent
Download data:
Downloadable files: 201699 total downloads to date
Subscribe to:
Posts (Atom)