SLAMD Logo
 
» Home
 
» Key Features
 
» News and Announcements
 
» Downloads
 
» Frequently Asked Questions
 
» Documentation
 
» Mailing Lists
 
» Screenshots
 
» Subversion Repository
 
» Building SLAMD
 
» Future Plans
 
» Third-Party Components
 
» License
 
SLAMD Distributed
Load Generation Engine 		Version 2.0.0-alpha1

Future Plans for SLAMD

Some enhancements planned for future versions of SLAMD are listed below. If you have ideas for other features that could be added, then send them to the SLAMD-Discuss@SLAMD.com mailing list (see this page for information on subscribing to the SLAMD mailing lists) or use the java.net issue tracking system.

  • Replace the Directory Backend

    SLAMD currently uses an LDAP directory server (e.g., the Sun ONE Directory) as its backend for storing all configuration and job data. However, this requires someone using SLAMD to have a directory server installed and configured and to have at least a basic knowledge of how to interact with it. It would be nice to replace the backend with an embedded database (e.g., Berkeley DB Java Edition) that does not need to be installed or configured outside of SLAMD and that requires little to no interaction by the SLAMD administrator.


  • Comparing Different Job Types

    At the present time, it is only possible to make comparisons between jobs of the same type. In the future, there should be a way to make comparisons between related statistics of different job types. Such an implementation would require a means of establishing a mapping between related parameters in different job types so that they may be compared.


  • More Flexible Access Control

    SLAMD currently offers a number of access control features that can be used to customize the features that users can access through the administrative interface. However, those access control features apply to the server as a whole. The server does not offer an ability to restrict access to features at a more granular level (e.g., a user can only delete or move the jobs that he or she has scheduled). A more powerful and flexible access control model could make this possible.


  • Nested Job Folders

    Currently, all job folders defined in the SLAMD server are considered peers. In many cases it would be beneficial to nest job folders so that they can be more appropriately organized.


  • Job Groups

    If SLAMD is used to perform a sequence of tests at regular intervals (e.g., tracking performance of daily builds of a network application), it could be beneficial to define that sequence of jobs as a job group that could be scheduled and managed as a single entity.


  • Chroot Mode for Shared Servers

    If a single SLAMD server is to be shared by many people, it would be nice to provide a chroot mode in which each user only sees his or her own jobs. This is dependent upon the rewrite of the access control mechanism in the server.


  • Job Versioning

    Currently, the SLAMD server offers the ability to transfer job classes to clients if they do not have a copy of a scheduled job, but unfortunately it does not have the ability to re-transfer the job class whenever a new version is installed on the server. It would be nice if a job class could include version information so that the client could determine if it needs to get a new version from the server.


  • Transfer of Non-Job Classes

    While the SLAMD server does offer the ability to transfer job class files to clients, it does not provide the ability to transfer other classes that may be needed to run jobs. This would be a nice complement to the ability to transfer job classes.


  • Job-Specific Control of In-Progress Reporting

    Whether a client will report in-progress statistics for a given job currently depends upon two factors: whether the client has been configured to enable in-progress statistics reporting and whether the job being executed has been configured to support this capability. However, there are times in which it would be useful to enable in-progress reporting on a per-job basis without the need to reconfigure the client between jobs. This could be done by adding the ability for the user scheduling the job to indicate whether in-progress reporting should be used.


  • Job-Specific Resource Monitors

    Whenever a job requests that a particular resource monitor client be used, that client will collect data for all resource statistics that have been enabled on that client. However, in some cases it may be desirable to only capture and report certain resource statistics for a job. It would be useful to be able to choose which statistics to include when requesting the resource monitor client.


  • Allow a Job to Report Resource Statistics

    At the present time, only a resource monitor client has the ability to collect and report system resource statistics to the SLAMD server. However, there are cases in which it would be useful for a job to be able to collect and report this information as well, especially for jobs that obtain information from external sources (e.g., the Directory Server Model job, which runs in a simulated system that cannot be monitored via traditional methods).


  • Cron-Like Capabilities

    It would be very useful to have the capability to periodically execute code within the SLAMD server itself to perform various administrative tasks. This could, for example, be used to schedule recurring jobs, perform regular backups, clean up old job data that may no longer be useful, etc. It would also be useful to attach this capability to certain events that may occur (e.g., execute x whenever job y completes).






If you wish to submit a request for a future enhancement, please consider the following criteria:
  • No new feature will be added that will restrict the kinds of network applications that SLAMD may be used to test. Although its primary use to date has been load generation and performance analysis of LDAP directory servers, it should be possible to write jobs to test any kind of network application that communicates using TCP or UDP. No change will be allowed that could limit this ability.

  • No change will be considered that requires native code. SLAMD is written entirely in Java, and no feature that requires code other than Java will be allowed.

  • No change will be considered that will restrict the ability to access the adminstrative interface through any kind of Web browser, including text-based browsers like lynx. Absolutely no JavaScript or any other kind of client-side scripting will be allowed. No HTML will be allowed that is not in complaince with the HTML 4.01 specification.

  • Changes that could break backward compatibility will generally be considered only for major version (i.e., 1.x.x to 2.x.x) upgrades. They will be avoided where possible, but some highly-desirable features (e.g., time skew detection) require updates to the client-server protocol, and others (e.g., replacing the directory backend) will require a data format change. For cases in which data format changes may be required, an upgrade mechanism should be made available.