|
SLAMD Distributed Load Generation Engine |
Version 2.0.0-alpha1 |
Frequently Asked Questions
General SLAMD Questions
1.1 What does SLAMD stand for?
1.2 What is the history of SLAMD?
1.3 What platforms does SLAMD run on?
1.4 What are the future plans for SLAMD?
1.5 How can I learn more about SLAMD?
Using SLAMD
2.1 Do I really need a directory server to use SLAMD?
2.2 Why don't my jobs start running when they are supposed to?
2.3 Why don't my jobs complete properly?
2.4 Why does viewing job information take so long?
Open Source FAQ
3.1 Why did you open source SLAMD?
3.2 Does this mean that Sun is abandoning SLAMD?
3.3 How can I get the source code to SLAMD?
3.4 How can I contribute to the development of SLAMD?
3.5 How can I keep track of new developments?
General SLAMD Questions
1.1 What does SLAMD stand for?
First, it is important to point out that the full official name for this project is "SLAMD Distributed Load Generation Engine", although it is commonly called "SLAMD" for short. The term "SLAMD" doesn't really stand for anything. Originally, SLAMD was designed for stress testing LDAP directory servers, which frequently use a process name containing "slapd" (Standalone LDAP Daemon) and the name "SLAMD" was a play on that. However, as SLAMD is now much more flexible and can be used to test a wider range of network applications, the directory-specific name is no longer as pertinent, but we have no intention of changing it.
1.2 What is the history of SLAMD?
The SLAMD Distributed Load Generation Engine as been under development as a side project within Sun Microsystems since early 2002. It was originally designed for benchmarking Sun's LDAP directory server, but was written in a very flexible and extensible manner so that it can be used for testing virtually any kind of network application. Many groups within Sun use it for their own testing, and a number of customers use it as well. With the open source release, we hope to make it even more widespread so that others may find it helpful.
1.3 What platforms does SLAMD run on?
With the exception of shell scripts and batch files that are used to start the various components, SLAMD is written entirely in Java. As such, it should be possible to use on any system that is able to run Java 1.4 or higher (including Java 5.0). Note, however, that there may be some features that do not work on all platforms. For example, the client manager depends on the UNIX exec command in order to function properly, and Windows systems do not appear to offer an equivalent (i.e., a batch command that can call another program under the same process ID and terminate once that child process has completed). Similarly, some of the system resource monitors depend on command-line utilities (e.g., vmstat, iostat, etc.) that may not be available on all platforms.
1.4 What are the future plans for SLAMD?
Although we believe that SLAMD is currently very full-featured, we do have ideas about ways that it can be made even more powerful and easier to use in the future. See this page for more information on features that we are considering for future releases.
1.5 How can I learn more about SLAMD?
The first place to look is the documentation. In particular, the Quick Start Guide should provide all the information you need to help you get SLAMD up and running quickly, and the Administration and Usage Guide can provide more complete details on using SLAMD. Next, you can join one or more of the mailing lists and either observe the discussions or get involved in them yourself. And of course you can always check out the source code and look through it to see exactly how it is all put together.
Using SLAMD
2.1 Do I really need a directory server to use SLAMD?
At the present time, yes you do. SLAMD stores its configuration and job data in an LDAP directory server, and needs this to function. Note that although SLAMD has been primarily used and tested with the Sun ONE Directory Server, it should work with any compliant LDAPv3 directory, and it has been tested and confirmed to work with OpenLDAP. See the Quick Start Guide for instructions on using SLAMD with OpenLDAP or another directory server. Also note that we do intend to eliminate this dependency on an external directory server by replacing it with an embedded database (most likley, the Berkeley DB Java Edition).
2.2 Why don't my jobs start running when they are supposed to?
There could be a number of reasons for this. In most cases, when a job has been scheduled but has not yet started, it will include a pending reason field that will tell you why it might not have started running yet. The most common reasons for this include:
- If the start time that you specified when scheduling the job has not yet arrived.
- There are not enough clients available to process the job, or if you requested that a specific set of clients be used then one or more of them may not be available.
- If you requested any specific resource monitor clients to use with the job and they are not available.
- If you scheduled the job with a dependency on another job, and that job has not yet completed.
- If the job has been disabled, then it will not be able to start running until it is enabled.
2.3 Why don't my jobs complete properly?
If your jobs do start running, but they don't appear to stop properly, then there could be a number of reasons, including:
- If you did not specify a maximum duration or a specific stop time when scheduling the job, then it will run until it completes its processing or until it is cancelled by an administrator, and many jobs are configured to loop forever.
- If you did try to cancel the job but that didn't seem to work, then try clicking the cancel button again. The first time you click the cancel button, the job will interpret that as a request to stop gracefully at its earliest possible convenience. If the job receives additional cancel requests, then it will attempt to stop it in a more forceful manner.
- If there was a problem on the client side (e.g., if the client ran out of memory because the job collected large amounts of data), then the client might not be able to tell the server that it is done processing the job. In such cases, the only possibility may be to disconnect that client, and if there are other clients that did complete properly then you may be able to see results from them.
- If the job collected a very large amount of data, then then the attempt to store it all in the configuration directory may fail (e.g., if the max BER size has been exceeded in the Sun ONE Directory). See the SLAMD Administration and Usage Guide for information on directory server tuning and troubleshooting.
2.4 Why does viewing job information take so long?
If it appears that SLAMD is taking a long time to display job results, especially if it had been much faster in the past, then the most likely reason is that the proper set of indexes have not been defined in the server. See the SLAMD Administration and Usage Guide for information on the indexes that should be defined in the directory server to allow SLAMD to find the information it needs quickly. If the correct indexes have been defined, then try to increase the amount of memory that the directory server can use for caching, increase the amount of memory that the SLAMD server can use, and/or increase the SLAMD job cache size.
Open Source FAQ
3.1 Why did you open source SLAMD?
There are a number of reasons for this, but one of the biggest is that we would like to see it become more widely used in the community for performance testing. We think that many of the features that it offers can help individuals perform more realistic and meaningful benchmarks, so that they can better understand the performance of the software they are testing and how it might compare with competing products. We would also like to see it become the de facto standard for performance testing and benchmarking in certain areas, particularly for LDAP directory servers, and we believe that making it open source may help in this because it is easy to see that there are no special optimizations for any particular product or vendor that could produce unrealistically favorable results in a benchmark that wouldn't be seen in real-world use.
3.2 Does this mean that Sun is abandoning SLAMD?
Absolutely not. SLAMD is still under active development. In fact, we hope that releasing it under an open source license will spur development even further, and may encourage external developers to contribute code (e.g., jobs that they have written). Further, now that SLAMD is available under an OSI-approved Open Source license, we are more free to make use of other open source libraries that might enhance its functionality.
3.3 How can I get the source code to SLAMD?
You can obtain the full source code to SLAMD, as well as all the supporting files and necessary build scripts, by checking it out from the CVS repository hosted on java.net. See this page for information on obtaining the source code from CVS.
3.4 How can I contribute to the development of SLAMD?
In the short term, we expect to be making some pretty significant changes that touch a lot of the core code in the SLAMD server, so for the time being, we would prefer to limit the set of changes that we will accept in that area. However, we are very happy to accept contributed code based on external APIs, since we do not intend to change them. This includes new job classes, job scripts, resource monitors, optimization algorithms, and report generators. If you have developed such code and would like to share it with other users, then see this page for details.
3.5 How can I keep track of new developments?
There are several ways to do this, but perhaps the best way is to join one or more of the mailing lists. The SLAMD-Announce list should be very low traffic and will include only announcements about new releases and other significant news, and messages from this list will only be allowed from a limited set of individuals. The SLAMD-Discuss list is a much more general-purpose list intended for questions, feature requests, comments, and general discussion, and we will often provide updates whenever smaller features are added that don't warrant a more widespread announcement. The SLAMD-Commit list will be used to provide details about every commit performed in the CVS repository, which will include everything from the addition of new features to bugfixes to correcting typos in the documentation.