cn=Directory Manager

cn=Directory Manager
All about Directory Server

All | Personal | Sun

« Previous day (Jan 7, 2006) | Main | Next day (Jan 8, 2006) »

Sunday January 08, 2006

What's happening with SLAMD?

If you are at all interested in performance testing Directory Server or other network applications, or if you have read much of my earlier posts, then you're aware of The SLAMD Distributed Load Generation Engine. You may also note that the last release of any kind was in June and that the SLAMD site doesn't change all that much. If you are subscribed to the SLAMD-Commit@SLAMD.com mailing list, then perhaps you've seen some of the stuff that's been going on since then. However, since it's sometimes hard to see the forest for the trees, and it's even harder to see stuff that hasn't been committed yet, then I thought I would give a brief overview of what's coming in the next release, which should be version 2.0.0.

The biggest change is the switch from a configuration directory to an embedded database, using the Berkeley DB Java Edition. Right now, SLAMD 1.x requires an LDAPv3 directory server, like the Sun Java System Directory Server or OpenLDAP, in order to store its configuration and all job information. For people that use SLAMD in order to test a Directory Server, or for testing something that requires a Directory Server like Access Manager or Portal Server, then this is no big deal. But if you're using it to test something else and you're not in the habit of using directory servers, then it can be more complex than some people want. By using an embedded database, the complexity can be almost completely hidden from the user. It also allows for better extensibility for the future, since using a Directory Server requires updates to the schema in order to support new attributes for new features, whereas this is not necessary for an embedded database.

The code for using the embedded database has actually already been implemented, and if you check out SLAMD from the CVS head, then you will be using that code. Note that the new database format is not backward compatible with the existing format, although there is a method to migrate data from a SLAMD 1.x configuration directory into the new SLAMD 2.x database. However, this is a one-way conversion so any jobs run with the SLAMD 2.x version of the code won't be accessible to SLAMD 1.x servers. Moving forward into the future, the design used for the database should be flexible enough to avoid the need for another big change like this.

The other major change between SLAMD 1.x and 2.x will be the protocol used to communicate between the SLAMD server and the various types of clients. Although the SLAMD 1.x protocol works quite well, it was not designed to be as extensible as necessary to add new features. Therefore, with a couple of exceptions that took quite a bit of work to implement, everything that a SLAMD 1.8.2 client can do could be done by a SLAMD 1.0 client (and in fact, quite a bit earlier than that). I've been able to come a long way just by implementing what have primarily been server-side enhancements, but it's time to be able to have new features on the client side as well, and to make it possible to have a much more extensible protocol so that another major redesign won't be necessary.

The code for the new protocol has mostly been written and checked into the repository. However, it's not actually in use because none of the client code has been updated to make use of it rather than the SLAMD 1.x protocol. I've spent a little time working on a new client to use the new protocol, but I've been a little distracted of late and therefore haven't been able to devote a whole lot of time to it. But once that work is done, then I'll probably release an alpha version of SLAMD 2.0 shortly thereafter.

All of the other changes that have been made so far are much less significant. The most interesting ones include:

I've made several minor updates to the UI to add niceties in a few places. For example, when a job is running, if the SLAMD server can figure out how much longer it thinks that a job will remain active, then it will display that, along with information about the clients and monitor clients that are being used to run it. Also, the status page now lists the five most recently completed jobs so you can quickly find them, which is handy if you have a server with lots of data in it.
I've added a "minimum percent improvement" feature to the provided optimization algorithms that can be used to indicate that a new iteration must be at least x% better than the previous best in order to be considered the new best. This can help avoid cases where optimizing jobs take a horribly long time to complete because new iterations make tiny, statistically-insignificant improvements over previous ones that cause new iterations to be scheduled.
I've made several minor changes and improvements in the area of resource monitors. I've improved the default configurations for several of the monitors so that they will be more likely what you want to see by default (or at least what I want to see). Also, I've added a new MPStat monitor that can measure CPU utilization on a per-CPU basis (Solaris only for now), and I've updated the IOStat monitor so that it can also include the percent busy information for the associated disks (also a Solaris-only improvement). I fixed a bug in the NetStat monitor that could cause it to come up with negative values whenever a counter rolled over.
I've added the ability to group resource monitor statistics by monitor class. This means that when graphing statistics for a job, you can see not only a "Graph all resource monitor statistics" checkbox, but also checkboxes like "Graph all IOStat statistics" and "Graph all VMStat statistics". Unfortunately, this depends on a feature in the new protocol and therefore its true potential has not yet been realized.
The HTTP client has been updated so that you can now configure it to automatically delete any cookie whose value is set to "LOGOUT". Although I can't find this in any official HTTP specification, apparently most browsers exhibit this behavior and some Web-based applications depend on it. This allows the SLAMD HTTP client to be more compatible with those applications. Also in the area of cookies, support has been added for the cookie comment and version fields, and for deleting cookies by name. Not related to cookies in any way, a socket timeout option has been added that makes it possible to require a response in a specified length of time, and also the local port to use for outbound sockets can be specified.
I've added better support for read-only mode such that information that the SLAMD server considers "sensitive" won't be displayed. This includes things like addresses of clients and resource monitor clients used to run a job and the e-mail addresses of users to notify when the job is complete. I've also updated the various types of parameters so that they can be declared sensitive and therefore the information they contain will not be displayed in this mode (password parameters are marked sensitive by default).

It's likely that most of the other improvements in SLAMD 2.0.0 will be pretty minor. I've still got some big ideas that will be coming in the future, but the flexibility of the new protocol will allow me to push them out to SLAMD 2.0.1 or SLAMD 2.1 without having to worry about backward compatibility as much as was necessary in the past.

As for the big question as to when SLAMD 2.x will be available, that's still to be determined, but the generic answer is "as soon as I'm comfortable with what's in it and it's gone through enough testing that I feel it's stable enough". Some of that uncertainty is simply because SLAMD is something that I work on in my spare time, and I don't usually have a whole lot of that. I will admit that I didn't get as much work done on it as I would have liked during the recent Christmas break, but writing the code for the new protocol took me quite a bit less time than I expected so that's at least a little bit of a trade-off. And of course if you want to see what's there now, it should be possible to build it for yourself from what's checked in, and if you find any bugs, then I'll do my best to fix them as quickly as possible. It may not have all the bells and whistles that I hope it will have in the not-too-distant future, but it should be functional and hopefully a little better than what's available in SLAMD 1.8.2. However, I'd still caution you that if you've got some big testing to do, then it might be safer to stick with what's officially released.

Posted by cn_equals_directory_manager ( Jan 08 2006, 11:57:53 PM CST ) Permalink Comments [2]