SLAMD For Linux

The SLAMD Distributed Load Generation Engine (SLAMD) is a Java-based application designed for stress testing and performance analysis of network-based applications. It was originally developed by Sun Microsystems, Inc., but it has been released as an open source application under the Sun Public License, which is an OSI-approved open source license.

The main site for obtaining information about SLAMD is http://www.slamd.com/, but it is also available as a java.net project.

SLAMD was originally developed for the purpose of benchmarking and analyzing the performance of LDAP directory servers, and it is the most powerful and flexible tool available for this task.

However, it is also well-suited for testing other kinds of network applications and has been used for things like Web servers and Web-based applications, relational databases, and mail servers. It can also be used for non-network based applications (and in fact, it is used for comparing things like CPU power and memory latency across a number of different kinds of systems), although its distributed nature makes it ideal for systems that can be accessed remotely.

SLAMD provides a Java-based API to make it possible to quickly develop custom workloads, and it also contains an embedded scripting engine that can make it easy to stress applications using protocols like LDAP, HTTP, SMTP, IMAP, and POP, or any database that can be accessed via JDBC.

It also includes tools for recording and playing back TCP traffic, and a utility for intercepting LDAP communication and writing it as a script that may be executed in the SLAMD scripting engine.

Here are some key features of "SLAMD":

� SLAMD is a distributed application. There is a central server used to coordinate the load generation process, but the actual work is performed by client applications. The clients can be installed on any number of systems, and if more load is needed, then additional client systems can be added. A resource monitor client application can be run on the load generation client(s) and/or the server(s) under load to measure things like CPU utilization, disk I/O, network load, etc.

� SLAMD can be used on any system capable of running Java 1.4 or higher. The administrative interface is a Java Web application that can be used in any standard servlet container (it is available with an embedded Tomcat engine), and the clients are standalone Java applications. Shell scripts are provided for starting the server and clients on Linux an UNIX systems, and batch files for Windows systems.

� The primary interface for accessing SLAMD is a Web application that works with any browser capable of rendering HTML 4.01. It does not require any client-side processing (e.g., JavaScript, applets, etc.), and can even be run in completely text-based browsers like Lynx. Tools are available that can be used to perform most tasks from the command line, including scheduling jobs, obtaining results, uploading configuration files, and adding new job classes.

� In order to be as widely-useful as possible, it is necessary to provide a means of generating load against a variety of network applications. SLAMD is provided with jobs for interacting with LDAP directories, Web servers and applications, messaging servers, and relational databases. If the jobs provided with SLAMD are not sufficient for your needs, then you can write your own using a Java-based API or the embedded scripting language. SLAMD is also provided with tools for capturing and replaying traffic (including special support for the LDAP protocol), so it is possible to generate load without writing any code at all.

� In most cases, the performance of a network application is higly-dependent upon the amount of client load that is hitting it. In order to find the best possible performance for the server, it may be necessary to run the same test many times with varying levels of load. SLAMD can automate this process through the use of optimizing jobs. The same workload will be run repeatedly, increasing the number of threads per client with each additional iteration, stopping automatically when the server believes that it has identified the optimal amount of load. The logic used to decide which iteration has the best performance is defined by the optimization algorithm used, and SLAMD is provided with several of them and also includes an API that makes it possible for the end user to develop new ones.

� When performing benchmarking or performance analysis, it is often useful to have information about the overall state of the system(s) under load. It can also be beneficial to understand how the clients are performing, to ensure that they do not become a bottleneck and produce inaccurate results. To address this, SLAMD includes a number of resource monitors that can measure sytstem properties like CPU utilization, free memory and process size, disk I/O, and network load. This can also be used to obtain application-specific metrics (e.g., retrieving statistics from a directory server's monitor entries or measuring replication latency). There is also an API for developing custom resource monitors that can perform virtually any other kind of monitoring.

� In order to generate load against a network application, it is necessary to schedule a job that defines how that processing should be conducted. The job can be scheduled to start either immediately or at some point in the future, and dependencies can be defined so that one job will not be eligible to start until another job or set of jobs has completed. When a job is scheduled, a number of general properties can be specified, including how long it should run, the number of client systems to use and the number of threads on each client, and any user(s) that should be notified when the job has completed. There can also be a number of parameters specific to the type of job being executed.

� By default, whenever a job is running, there is little to no communication between the SLAMD server and the clients used to process the job so that the clients will be able to focus their efforts purely on load generation. However, in some cases (particularly for jobs that may be scheduled to run for hours or days), it may be desirable to know information about the state of the job while it is still running. In such cases, the clients can be configured to periodically report their results back to the SLAMD server so that they can be viewed in the administrative interface. This is also available for resource monitor clients. In this way, if it appears that the job is not performing as well as expected, or if a problem has occurred, it can be detected early in the process rather than having to wait until the job has completed.

� SLAMD stores all job data in an LDAP directory server (although there are plans to replace this with an embedded Berkeley DB Java Edition database in the near future). This means that all results are available at any point in the future. Any previous job executed can be easily cloned to repeat the same test (with or without any modifications), and the results of that processing can be viewed either numerically or graphically. The resuls from multiple jobs can be compared, also numerically or graphically. Job data may also be exported to tab-delimited text files for use in other applications, or written out as a report in plain text, HTML, or PDF form (or any other form that is added using a Java-based API for developing custom report generators). Information in the configuration directory may be organized into folders so that the results may be found more easily, and other files (e.g., configuration files or external documents) can be uploaded into those folders to provide additional information about the tests conducted, the results, obtained, or the environment configuration.

� By default, SLAMD is configured to be accessible by anyone for convenience and ease of use. However, if it is to be run in a network that is accessible by many people, then it may be desirable to restrict access to the individuals that can use it. SLAMD offers a number of capabilities in this area. All communication can be encrypted using SSL, including both the access to the administration interface and the communication between the SLAMD server and the clients and/or resource monitor clients. It is also possible to require the clients to authenticate themselves to the SLAMD server, as well as users authenticating themselves to be able to access the administrative interface. If authentication is enabled, then it is possible to restrict access to certain features on a per-user basis (e.g., so some users may only view job results, while others can view and schedule jobs, while others can make configuration changes). There is also a read-only mode that makes it possible to provide minimal access to users for being able to view job information without requring authentication, and it is even possible to configure the server in this mode to only show information about a specified subset of the jobs in the server.

� SLAMD includes nearly 700 pages of documentation that covers virtually all aspects of its use. The Administration and Usage Guide provides general instructions on installing, configuring, and using SLAMD. The Job Reference Guide documents the set of jobs that are included with SLAMD. The Job Developer's Guide, Resource Monitor Developer's Guide, Optimization Algorithm Developer's Guide, and Report Generator Developer's Guide all provide instructions for using Java-based APIs to write custom code for use with SLAMD, and the Scripting Language Guide provides information on using and extending the embedded scripting language. There is also a document included that discusses techniques and methodologies for benchmarking LDAP directory servers, although many of the topcis covered in that document may also be applicable to general use for other applications.

� Because SLAMD was originally designed for use with LDAP directory servers (and because its primary author continues to use it for this purpose on a nearly daily basis), it includes a lot of special tools and capabilities that can provide additional value when using it to test directory servers. One tool provided for this purpose is MakeLDIF, an extremely powerful template-based utility for generating LDIF data files. Another is the LDAPDecoder, which can operate as either a simple LDAP proxy or analyze tcpdump and snoop capture files to decode LDAP communication in human-readable form or even automatically generate SLAMD scripts based on the captured data so that the same communication can be automatically replayed or customized to simulate real-world directory-enabled applications. There are a number of jobs specifically designed for testing LDAP directory servers, the scripting language includes LDAP support, and several of the resource monitors are intended for use with directory servers. The document "Benchmarking the Sun ONE Directory Server with the SLAMD Distributed Load Generation Engine" provides a thourough description of the activities and methodologies involved in performing an accurate and reproducible benchmark against LDAP directories.

� Web-based applications have dramatically increased in popularity in recent years, and as a result, so has the need to be able to perform stress testing and load generation against them. To help with this, SLAMD includes a rather flexible HTTP client implementation that makes it possible to interact with these kinds of applications in a manner that can simulate many common browser behaviors, and the scripting engine makes use of this HTTP client to provide this support as well. A future release will include an HTTP proxy that can be used to record traffic from clients and write a SLAMD script that makes it possible to easily automate this testing, much like the LDAPDecoder tool does for LDAP clients.

� Because of the highly extensible manner in which it has been developed, SLAMD can be used to test virtually any kind of network application. Besides LDAP and HTTP-based capabilities already discussed, jobs are provided for interacting with mail servers via POP, IMAP, and SMTP, and with relational databases using JDBC. All of these protocols are also supported by the embedded scripting engine. Beyond them, the job development API makes it possible to use Java to develop custom jobs or even to extend the scriping language. Further, The TCP record and playback tools can be used to capture requests from clients and replay them against a server to simulate many kinds of network load without writing any code at all.