Progress Report on SLAMD3

Once again, many days have passed between blog entries about the ongoing web application development and conversion of SLAMD: I have many other duties that I do not neglect, yet SLAMD is never far from my mind. In that time, some minor and major changes have been made to the SLAMD2 trunk, so anyone using SLAMD should download the newest version. The short version of the changes are: new version of the UnboundID LDAP SDK, rate limiting, some script fixes, and a very minor change to the HttpGetRate job. A full list of changes with comments is available at the SLAMD web site. Please download from that site, and join the mailing lists, and submit issues.

SLAMD2 is being converted to use a web framework, in this case Struts. This involves separating the HTML generation from the database access code, in short, conversion to MVC. It is a big task, but a fun one. When complete, SLAMD - tentatively called SLAMD3 since I am not very imaginative - will have its display (view) completely separate from the model and the controller. The virtues of this are profound: easy to change the view without mucking about in the database code, easy to localize (only Southern United States English so far, but a Klingon locale is coming), easy to change the model without affecting the view and vice-versa, and a host of other benefits.

Current progress: about 70% of the views are complete, that is, separated from the model (database code). By complete, I mean JavaServer Pages (JSPs) written, Actions written, validations written, resource bundles for United States English written, and all of that tested. Like I said: a big job. The most obvious changes since the last blog entry are that all the configuration screens are complete and one very big cosmetic change. I've recovered some space from the top of the screen by moving the header information to a smaller footer which displays the version, build number, and so forth. Here is a screenshot of the top-level configuration screen with the new screen layout and breadcrumbs (right-click for a larger image):

The breadcrumbs and the locale selector are most likely the highest value I've added to SLAMD from the outside. The inside is completely different from SLAMD2 administrative interface code, yet the database code remains unchanged except for converting what functioned as "globals" into instance variables injected by interceptors.

I've changed the layout of the configuration pages. Instead of seeing a page, then clicking on a link to change a value, everything is now on one page, with some helpful text about the nature of the parameter printed above the parameter. Since the text is separate from the code now, it will be straightforward to alter this text and make it even more helpful and complete, and in multiple locales. Struts is pretty cool about locales - it fetches the locale from the HTTP headers and makes it available throughout the web framework and on the ValueStack as:

public java.util.Locale getLocale()

Observant SLAMD aficionados may note and wonder why there are no "View Pending Jobs" and "View Running Jobs" links in the navigation sidebar. The reason is simple: there are no pending or running jobs. When the number of pending jobs is greater than zero, the "View Pending Jobs" link appears, likewise for 'View Running Jobs".

About SLAMD

The SLAMD Distributed Load Generation Engine (SLAMD) is a Java-based application designed for stress testing and performance analysis of network-based applications. Initial development of SLAMD was performed at Sun Microsystems, with recent development sponsored primarily by UnboundID Corp. Recent development work is by Terry Gardner and Neil Wilson.

SLAMD is available under the terms of the Sun Public License, which is an OSI-approved open source license. The main site for obtaining information about SLAMD is available at its home page, and it is 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.

SLAMD2 is being converted to use a web framework, in this case Struts. This involves separating the HTML generation from the database access code, in short, conversion to MVC. It is a big task, but a fun one. When complete, SLAMD - tentatively called SLAMD3 since I am not very imaginative - will have its display (view) completely separate from the model and the controller. The virtues of this are profound: easy to change the view without mucking about in the database code, easy to localize (only Southern United States English so far, but a Klingon locale is coming), easy to change the model without affecting the view and vice-versa, and a host of other benefits.

Posted at 09:27PM Apr 08, 2009 by tgardner in slamd  |  Comments[1]