Benchmarking the Sun ONE Directory Server 5.2. with the SLAMD Distributed Load Generation Engine

Transcription

1 Benchmarking the Sun ONE Directory Server 5.2 with the SLAMD Distributed Load Generation Engine October 2004

2 Contents 1. Introduction Introduction to MakeLDIF...7 Using MakeLDIF...7 Template File Format...10 Template File Tags Introduction to the SLAMD Distributed Load Generation Engine...18 LDAP-Specific Jobs Provided with SLAMD...20 SLAMD Versus Other Load Generation Software Generating and Loading the Data...27 Configuring the Server for Import...33 Importing the LDIF...34 Backing Up the Database Configuring the Directory Server...36 Disk Configuration...36 Disk Layout...37 Cache Sizing...40 Database Tuning Parameters...43 Index Configuration...45 ALLIDs Threshold Configuration...47 The Referential Integrity Plugin...48 Number of Worker Threads Installing and Configuring the SLAMD Server...51 Installing and Configuring the SLAMD Configuration Directory...51 Installing and Configuring SLAMD Benchmarking the Sun ONE Directory Server 5.2 with the SLAMD Distributed Load Generation Engine

3 7. Installing and Configuring the SLAMD Clients Using SLAMD...59 Scheduling a Job for Processing...61 Viewing Job Execution Results...67 Viewing Results from Multiple Jobs...70 Working with Optimizing Jobs Priming the Directory Server...75 The SLAMD LDAP Prime Job...76 The SLAMD LDAP SearchRate Job...81 Partial Cache Priming...83 Verifying the Cache Priming Benchmarking Search Performance...87 The SLAMD LDAP SearchRate Job Class...87 Measuring Exact Search Performance...95 Using Weighted Searches...96 Measuring Substring Search Performance Benchmarking Authentication Performance The SLAMD LDAP AuthRate Job Class The SLAMD LDAP DIGEST-MD5 AuthRate Job Class Simulating Basic Authentications Simulating More Complex Authentications Benchmarking Modify Performance The SLAMD LDAP ModRate Job Measuring Modify Performance Benchmarking Add and Delete Performance The SLAMD LDAP Add and Delete Rate Job Measuring Add and Delete Performance Benchmarking Mixed Load Performance The SLAMD LDAP Load Generator Job Class Measuring Mixed Load Performance Measuring Replication Performance Controlling the Change Rate

4 Measuring Replication Latency Replication Performance Metrics The SLAMD Jobs that Measure Replication Latency Benchmarking by Simulating Real-World Applications Simulate the Application or Drive the Application? Understand the Access Patterns Use Parameters to Increase Flexibility Provide a Means of Constructing Values Provide for Weighted Accesses Provide for Warm-Up and Cool-Down Times Provide a Throttling Mechanism Using the GetFile Servlet Enabling and Configuring the GetFile Servlet Making the Files Available Accessing the GetFile Servlet Using System Information and Measurement Tools Using idsktune Obtaining Information about System Hardware Using vmstat Using prstat Using iostat SLAMD Resource Monitoring Installing the Resource Monitor Client Scheduling a Job to Use Resource Monitoring The VMStat Resource Monitor The IOStat Resource Monitor The NetStat Resource Monitor The Process Size Resource Monitor The Sun ONE Directory Server Resource Monitor The Replication Latency Resource Monitor The UDP Ping Resource Monitor SLAMD License Benchmarking the Sun ONE Directory Server 5.2 with the SLAMD Distributed Load Generation Engine

5 Introduction The Sun ONE Directory Server 5.2 is the most recent release of the premier LDAP directory server on the market, and it contains many enhancements and improvements over previous versions. Many of those improvements are in the areas of performance and scalability. However, rather than taking our word for it, you may want to verify this for yourself. There are a number of very good reasons for doing this: Performing your own benchmarking can allow you to confirm for yourself the claims made about the Directory Server. You may want to trust your own measurements more than those provided by the vendor or a vendor-sponsored study. Performing your own benchmarking can allow you to verify the performance of the Directory Server in your own environment. The type and arrangement of the data in the server, the kinds of applications that access the server, and the kind of hardware on which the server is running can all have a significant impact on performance. Performing your own benchmarking can teach you a great deal about the configuration and administration of the Directory Server. By examining and adjusting the configuration of the server, you can gain a better understanding of how the server works and how best to tune it. This document provides information and suggestions to allow you to perform your own benchmarks of the Sun ONE Directory Server. To achieve this, we will focus on two key tools. MakeLDIF will be used to generate the data to use in the benchmarking process, and SLAMD will be used to generate the load and measure the performance. These tools will be discussed in detail in subsequent chapters. The information provided in this document has been given under the assumption that the Directory Server will be running on a SPARC Solaris 9 system. The vast majority of the content deals with general concepts that can be applied just as well to a Directory Server running on other platforms (Solaris x86, Linux, HP- Introduction 5

6 UX, and AIX, as well as Windows to a lesser extent). In the case where systemspecific information is given (e.g., the section on monitoring system performance metrics), some of these utilities may not be available on all platforms, but there will likely be an equivalent utility. Consult your operating system documentation for more information about locating comparable tools. 6 Benchmarking the Sun ONE Directory Server 5.2 with the SLAMD Distributed Load Generation Engine

7 Introduction to MakeLDIF MakeLDIF is a powerful utility that can be used to generate LDIF files for importing into the Directory Server. It uses template files to describe the structure of the entries to create, and also to define the number and arrangement of the entries in the server. It can be used to generate LDIF files that closely resemble actual production data, but with some subtle changes that make it much easier for use in benchmarking. The benefits of using generated data instead of the actual production data will be discussed later in this document, but for now we will just discuss the features and usage of MakeLDIF. Using MakeLDIF MakeLDIF is a Java-based application and requires a Java runtime environment of version 1.2 or higher in order to run. Note, however, that more recent Java versions exhibit significantly better performance than the 1.2 version and therefore it is recommended that a Java runtime of at least version 1.4 is used. In order to run MakeLDIF, you should invoke the Java runtime with the JAR file and an appropriate set of arguments. For example, a minimal invocation of MakeLDIF could be: java -jar MakeLDIF.jar -t example.template -o example.ldif In this case, the "-t" argument specifies the path to the template file that describes the LDIF file to create, and the "-o" argument specifies the path to the output file that should be created with the LDIF data. These are the only arguments that are required for use with MakeLDIF, but there are a number of other optional arguments: -f {filename} -- Specifies the path to the file containing the list of first names to be used when generating the data. By default, MakeLDIF will use a file named first.names in the current working directory, although this option can Introduction to MakeLDIF 7

8 be used to specify a different file. If a different file is to be used, then it should contain one name per line and it should not contain any duplicates. -l {filename} -- Specifies the path to the file containing the list of last names to be used when generating the data. By default, MakeLDIF will use a file named last.names in the current working directory, although this option can be used to specify a different file. If a different file is to be used, then it should contain one name per line and it should not contain any duplicates. -d {filename} -- Specifies the path and name of a file into which the DNs of the entries generated will be written. This DN file can then be used in conjunction with other utilities like the SLAMD ModRate job that have the ability to operate on a list of entry DNs. If this option is not provided, then no DN file will be generated. -b {filename} -- Specifies the path and name of a file into which bind information for the generated entries will be written. Each line written to this file will be in the form {dn}{tab}{password}, where {dn} is the DN of the user entry, {tab} is the tab character, and {password} is the value of the userpassword attribute for the user entry. If this option is not provided, then no bind information file will be generated. -L {filename} -- Specifies the path and name of a file into which login information is to be written. Each line written to this file will be in the form {loginid}{tab}{password}, where {loginid} is the value of the login ID attribute, {tab} is the tab character, and {password} is the value of the userpassword attribute for the user entry. If this option is not provided, then no login information file will be generated. -i {attribute} -- Specifies the name of the attribute that should be used to hold the login ID for the user if the -L option is used. By default, the uid attribute is assumed to hold the login ID, although this option can be used to specify a different attribute. -F {filename} -- Specifies the path and name of a file into which filter information is to be written. If this option is used, then the -T option must also be used to specify the types of filters to create, and the information will be written with one filter per line. If this is used in conjunction with the -M option, then each filter file created will append the name of the attribute and index type to this base filename. -T {type} -- Specifies the attributes and index types that should be included in the filter file. The format of the filter type should be {attribute}:{type}, where {attribute} is the name of the attribute for which the filters are to be generated and {type} is the index type for which the filters are to be generated. The index types that may be specified are eq for equality indexes (each unique value of 8 Benchmarking the Sun ONE Directory Server 5.2 with the SLAMD Distributed Load Generation Engine

9 the attribute will be included in the filter list), subinitial (for substring filters containing the first three characters of a value followed by an asterisk), subany (for substring filters containing each unique three-character combination present in any of the values surrounded by asterisks), subfinal (for substring filters containing an asterisk followed by the last three characters in the filter list), and sub (which is a shorthand notation for including subinitial, subany, and subfinal filter types). It is possible to specify that multiple filter types should be used in the filter list by separating them with commas. For example, "-T cn:eq,subinitial" will generate both equality and subinitial filters based on values of the cn attribute. Multiple -T options can be provided on the same command line to indicate that filters should be generated for multiple attributes. -n {value} -- Specifies the number of characters that should be included in substring filters generated by MakeLDIF. This applies to all substring filter types (subinitial, subany, and subfinal). The default value is 3, but any positive integer value is allowed. -N {value} -- Specifies the minimum number of entries in the LDIF file that will be required to match a filter before it will be included in the filter file. This applies to all filter types (equality as well as all substring types). The default value is 1, but any positive integer value is allowed. -X {value} -- Specifies the maximum number of entries in the LDIF file that will be allowed to match a filter before it is excluded from the filter file. This applies to all filter types (equality as well as all substring types). By default, there is no limit, but specifying any positive value greater than or equal to the minimum number of entries to match (as specified with the -N option) will enforce a maximum limit. This can be very useful for directory servers that have an ALLIDs threshold or similar feature in which the server will not maintain an index key that matches more than a specified number of entries. -s {value} -- Specifies a numeric seed to use for the random number generator. By default, the random number generator will be seeded based on the current time, which means that every time the LDIF file is generated, the random values will be different. However, if a random seed is provided, then the LDIF file will consistently contain the same sequence of "random" values. That is, if the same template file is used and the same random seed is provided, then the LDIF files generated by MakeLDIF will be identical. Note that this may not be true if certain kinds of tags are used in the template that may use their own random number generator (e.g., the exec tag). -m {value} -- Specifies the maximum number of entries that should be written to a single LDIF file. By default, all entries generated will be written to a single LDIF file (the one specified using the -o argument), but if the -m argument is Introduction to MakeLDIF 9

10 provided, then at most {value} entries will be written to any single file. This can be useful if there is a possibility that the LDIF data will need to be accessed by a utility that does not provide large file support. -x {value} -- Specifies the maximum number of entries that should be created for each template under each branch. This may be used to produce a small version of the LDIF file that can be used to validate that the template has been defined properly to produce the desired result. -w -- Specifies that long lines in the LDIF output should be wrapped at a column length of 75 characters. By default, no wrapping is performed. -M -- Specifies that a different filter file should be created for each index type of each attribute specified using the -T argument. By default, all filters will be written to the same filter file (the file specified by the -F option), but this argument will cause each the filter list for each attribute and index type to be written to a separate file. The name of each filter file will be the base filter file name followed by a period, the attribute name, another period, and the index type. -S -- Specifies that MakeLDIF should skip branch entries when generating the LDIF output. That is, only template entries will be written to the LDIF file but not the parent entry for those template entries. By default, the LDIF file generated will contain both branch and template entries. -D -- Specifies that MakeLDIF should operate in debug mode, which will cause it to provide additional debugging information for some errors that may occur while using MakeLDIF. -H -- Specifies that MakeLDIF should print usage information and exit without performing any other action. If this argument is provided, then no other options are required. -V -- Specifies that MakeLDIF should print version information and exit without performing any other action. If this argument is provided, then no other options are required. Template File Format MakeLDIF uses template files to describe the data that should be generated. The template file format is discussed in detail in the MakeLDIF Usage Guide and will 10 Benchmarking the Sun ONE Directory Server 5.2 with the SLAMD Distributed Load Generation Engine

11 therefore not be repeated here. However, this section does provide a cursory overview of what may be included in a template file. The first section in the template file is the global replacement variable definitions. These are very similar to preprocessor macros in programming languages in that references to global replacement variables are replaced with the values assigned to those variables before any other processing is done with the template files. A global replacement variable is defined with the keyword "define" followed by the name of the replacement variable, an equal sign, and the value to use for that variable. For example: define suffix=dc=example,dc=com defines a global replacement variable named "suffix" with a value of "dc=example,dc=com". Once a global replacement variable has been defined, it can be referenced later in the template file by placing the name of that variable in square brackets (e.g., "[suffix]"). After the global replacement variable definitions come the branch definitions. Branch definitions define the hierarchical structure for the LDIF file -- they specify the entries that should exist at the top of the hierarchy and the number of entries that should exist beneath them. At minimum, a branch definition should specify the DN to use for that entry, and optionally the number and types of subordinate entries that should exist beneath that branch. For example: branch: ou=people,[suffix] subordinatetemplate: person:1000 defines a branch entry with a DN of "ou=people,dc=example,dc=com" (assuming the previous value we assigned to the "[suffix]" global replacement variable), and then 1000 entries below that based on the "person" template. The final section of a template file is the actual template definitions. They specify the content of the entries that should be generated beneath branch entries. A template definition should specify the RDN attribute to use for entries generated with that template and the set of attributes and objectclasses that should be contained in those entries. The template definition can contain a number of tags used to customize the way in which the entries are created, which are described later in this section. However, a sample template definition is as follows: template: person rdnattr: uid objectclass: top objectclass: person objectclass: organizationalperson objectclass: inetorgperson givenname: <first> Introduction to MakeLDIF 11

12 sn: <last> cn: {givenname} {sn} initials: {givenname:1}{sn:1} uid: user.<sequential:1> mail: userpassword: password telephonenumber: <random:telephone> homephone: <random:telephone> pager: <random:telephone> mobile: <random:telephone> employeenumber: <sequential:1> street: <random:numeric:5> <file:streets> Street l: <file:cities> st: <file:states> postalcode: <random:numeric:5> postaladdress: {cn}${street}${l}, {st} {postalcode} description: This is the description for {cn}. Template File Tags The way that MakeLDIF can create realistic-looking entries that accurately simulate a wide variety of production data is through the use of tags that are parsed and replaced with the values generated by evaluating those tags. There are a number of standard tags provided that can be used in template files, including: <presence:{percent}> -- Indicates how likely the associated attribute value is to be included in any given entry generated from this template. The value specified for {percent} should be an integer between 0 and 100, inclusive. This should only be used with attributes that are not required by the objectclasses used in the entry, and there should be something else included in the value of the attribute that will be present in entries that are chosen to include this attribute value. The presence tag itself is replaced with an empty string. <ifpresent:{attribute}> -- Indicates that this attribute value is to be included in an entry only if the entry contains one or more values for attribute {attribute}. Note that if this feature is used, then {attribute} must be assigned a value in the template before the line that checks for its presence. The ifpresent tag itself is replaced with an empty string. <ifpresent:{attribute}:{value}> -- Indicates that this attribute value is to be included in an entry only if the entry contains attribute {attribute} with a value of {value}. Note that if this feature is used, then {attribute} must be assigned a value in the template before the line that checks for its presence. The ifpresent tag itself is replaced with an empty string. 12 Benchmarking the Sun ONE Directory Server 5.2 with the SLAMD Distributed Load Generation Engine

13 <ifabsent:{attribute}> -- Indicates that this attribute value is to be included in an entry only if the entry does not contain any values for attribute {attribute}. Note that if this feature is used, then {attribute} must be assigned a value in the template before the line that checks for its presence. The ifabsent tag itself is replaced with an empty string. <ifabsent:{attribute}:{value}> -- Indicates that this attribute value is to be included in an entry only if the entry does not contain attribute {attribute} with a value of {value}. Note that if this feature is used, then {attribute} must be assigned a value in the template before the line that checks for its presence. The ifabsent tag itself is replaced with an empty string. <first> -- Replaces the tag with a value from the first name file. If both a first name and a last name are included in an entry, then the combination of the first and last name is guaranteed to be unique. This is, no two entries in the same LDIF file will have the same combination of first and last name values. Note that in order to guarantee this, it is necessary to ensure that the first name file does not contain any duplicate values, the last name file does not contain any duplicate values, and the first and last name values are used in their entirety (i.e., you cannot use the substring feature of the attribute value replacements of the form {givenname:5} discussed below). <last> -- Replaces the tag with a value from the last name file. If both a first name and a last name are included in an entry, then the combination of the first and last name is guaranteed to be unique. This is, no two entries in the same LDIF file will have the same combination of first and last name values. Note that in order to guarantee this, it is necessary to ensure that the first name file does not contain any duplicate values, the last name file does not contain any duplicate values, and the first and last name values are used in their entirety (i.e., you cannot use the substring feature of the attribute value replacements of the form {sn:5} discussed below). <dn> -- Replaces the tag with the distinguished name (DN) of the current entry. Note that in order for this to work properly, the RDN attribute for the entry must be assigned a value on an earlier line of the template. <parentdn> -- Replaces the tag with the DN of the parent entry. <ancestordn:{depth}> -- Replaces the tag with the DN of the entry's ancestor at the specified depth. A depth of 1 will return the DN of the entry's immediate parent, a depth of 2 will return the DN of the entry's grandparent, and so on. If the entry does not have an ancestor at the specified depth, then the "<ancestordn:{depth}>" tag will be replaced with an empty string. <parent:{attr}> -- Replaces the tag with the value of the specified attribute from the parent entry, provided that the parent entry was generated using a template Introduction to MakeLDIF 13

14 rather than a branch. If the parent does not have any values for the specified attribute, or if information about the contents of the parent entry are not available, then this tag will be replaced with an empty string. If there are multiple values for the specified attribute, then the first value will be used. <exec:{command}> -- Replaces the tag with the information sent to standard output when the command {command} is executed on the system. Note that because this requires a separate process to be invoked for each entry created using this template, using this tag can make the LDIF generation process proceed much more slowly than if the exec tag is not used. <exec:{command},{arg1},{arg2},...,{argn}> -- Replaces the tag with the information sent to standard output when the command {command} is executed on the system with the provided set of arguments. Note that because this requires a separate process to be invoked for each entry created using this template, using this tag can make the LDIF generation process proceed much more slowly than if the exec tag is not used. <random:chars:{characters}:{length}> -- Replaces the tag with {length} characters from the character set {characters}. The character set {characters} can contain any character other than the colon. <random:chars:{characters}:{minlength}:{maxlength}> -- Replaces the tag with between {minlength} and {maxlength} (inclusive) characters from the character set {characters}. The character set {characters} can contain any character other than the colon. <random:alpha:{length}> -- Replaces the tag with a string of {length} randomlychosen alphabetic characters. <random:alpha:{minlength}:{maxlength}> -- Replaces the tag with a string of between {minlength} and {maxlength} (inclusive) randomly-chosen alphabetic characters. <random:numeric:{length}> -- Replaces the tag with a string of {length} randomlychosen numeric digits. <random:numeric:{minvalue}:{maxvalue}> -- Replaces the tag with an integer value between {minvalue} and {maxvalue} (inclusive). Note that the integer value will not be padded with leading zeroes, so if that is desired then the "<random:numeric:{minvalue}:{maxvalue}:{minlength}>" tag should be used. <random:numeric:{minvalue}:{maxvalue}:{minlength}> -- Replaces the tag with an integer value between {minvalue} and {maxvalue} (inclusive). If the integer value chosen contains less than {minlength} digits, then it will be padded with leading zeroes to the required minimum length. 14 Benchmarking the Sun ONE Directory Server 5.2 with the SLAMD Distributed Load Generation Engine

15 <random:alphanumeric:{length}> -- Replaces the tag with {length} randomlychosen alphanumeric characters. <random:alphanumeric:{minlength}:{maxlength}> -- Replaces the tag with between {minlength} and {maxlength} (inclusive) randomly-chosen alphanumeric characters. <random:hex:{length}> -- Replaces the tag with {length} randomly-chosen hexadecimal digits. <random:hex:{minlength}:{maxlength}> -- Replaces the tag with between {minlength} and {maxlength} (inclusive) randomly-chosen hexadecimal digits. <random:base64:{length}> -- Replaces the tag with {length} randomly-chosen characters from the base64 character set. Note that if {length} is not a multiple of 4, then the generated value will be padded with equal signs so that the total length is a multiple of 4 as per the base64 specification. <random:base64:{minlength}:{maxlength}> -- Replaces the tag with between {minlength} and {maxlength} (inclusive) randomly-chosen characters from the base64 character set. Note that if the selected length is not a multiple of 4, then the generated value will be padded with equal signs so that the total length is a multiple of 4 as per the base64 specification. <random:telephone> -- Replaces the tag with a string of randomly-chosen numeric digits in the form " ". This uses a US-style telephone number, but it is possible to generate telephone numbers in other formats by combining other kinds of tags (e.g., to generate a telephone number in the UK format, you could use "+44 <random:numeric:4> <random:numeric:6>". <random:month> -- Replaces the tag with the name of a randomly-chosen month. <random:month:{length}> -- Replaces the tag with the first {length} characters from the name of a randomly-chosen month. <guid> -- Replaces the tag with a GUID (globally-unique identifier) value containing hexadecimal digits in the form " ab-cdef abcdef". GUID values should be unique within the same LDIF file. <sequential> -- Replaces the tag with a sequentially-increasing numeric value. The first entry generated using this tag will have a value of 0, the second a value of 1, and so on. Note that sequential counters are maintained on a perattribute and per-template basis, so it is possible to use multiple sequential counters in different attributes of the same entry without impacting each other, Introduction to MakeLDIF 15

16 and it is also possible to use sequential counters for the same attribute in different templates without impacting each other. However, it is not possible to use multiple sequential counters for the same attribute in the same template without them impacting each other. <sequential:{initial}> -- Replaces the tag with a sequentially-increasing numeric value, starting at specified initial value {initial}. The first entry generated using this tag will have a value of {initial}, the second a value of {initial}+1, and so on. Note that sequential counters are maintained on a perattribute and per-template basis, so it is possible to use multiple sequential counters in different attributes of the same entry without impacting each other, and it is also possible to use sequential counters for the same attribute in different templates without impacting each other. However, it is not possible to use multiple sequential counters for the same attribute in the same template without them impacting each other. <list:{value1},{value2},...,{valuen}> -- Replaces the tag with a randomly-chosen value from the provided comma-delimited list. Each value in the list provided will have an equal chance of being selected. <list:{value1}:{weight1},{value2}:{weight2},...,{valuen}:{weightn}> -- Replaces the tag with a randomly-chosen value from the provided comma-delimited weighted list. The weight associated with each list item determines how likely that value is to be chosen. A list item with a weight of 2 is twice as likely to be chosen as an item with a weight of 1. The weights specified must be positive integers. <file:{filename}> -- Replaces the tag with a randomly-chosen value from the specified file. There should be one value per line of the file. It is not possible to assign weights to the values in the file, but a value can be weighted artificially by including it in the file multiple times. For example, a value that appears in the file three times will be three times as likely to be chosen as a value that appears only once. <base64:{value}> -- Replaces the tag with the base64-encoded representation of {value}. The value {value} will be converted into a byte array using the UTF-8 character set, and then that byte array will be base64 encoded. <base64:{charset}:{value}> -- Replaces the tag with the base64-encoded representation of {value}. The value {value} will be converted into a byte array using the rules of the Java character set {charset}, and then that byte array will be base64-encoded. See the Java API documentation to determine the names of the character sets that may be used. <loop:{lowerbound}:{upperbound}> -- Creates ({upperbound} - {lowerbound} + 1) copies of this line with this tag replaced in each copy with a sequentially- 16 Benchmarking the Sun ONE Directory Server 5.2 with the SLAMD Distributed Load Generation Engine

17 incrementing number starting at {lowerbound} in the first copy, ({lowerbound} + 1) in the second copy, and so on, so that in the last copy this tag will be replaced with {upperbound}. Note that it is possible to include multiple loop tags on the same line (even with different {lowerbound} values), but only the first tag will be used to determine the number of copies to create. <custom:{class}> -- Replaces the tag with the value generated by invoking the custom tag whose implementation is provided in the class {class}. The provided class name {class} must be fully-qualified (i.e., including the package name if applicable), and that class must exist in the classpath used to run MakeLDIF. <custom:{class}:{arg1},{arg2},...,{argn}> -- Replaces the tag with the value generated by invoking the custom tag whose implementation is provided in the class {class} with the specified argument list. The provided class name {class} must be fully-qualified (i.e., including the package name if applicable), and that class must exist in the classpath used to run MakeLDIF. In addition to the tags listed above, it is also possible to reference the value of one attribute in the value of another. This is done by specifying the attribute name in curly braces, like: uid: {givenname}.{sn} This indicates that the value of the uid attribute should contain the value of the givenname attribute followed by a period and the value of the sn attribute. Further, you can follow the name of the attribute with a colon and a number to indicate that at most the specified number of characters should be taken from the value. For example, initials: {givenname:1}{sn:1} will set the value of the initials attribute to be the concatenation of the first character in the value of the givenname attribute and the first character in the value of the sn attribute. Introduction to MakeLDIF 17

18 Introduction to the SLAMD Distributed Load Generation Engine The SLAMD Distributed Load Generation Engine (SLAMD) is a Java-based application designed for stress testing and performance analysis of network-based applications. It is a highly extensible framework for that can be used for benchmarking a wide variety of applications. It has a number of benefits that make it a very powerful tool for load generation and benchmarking: It is a distributed benchmarking tool, which means that it can run the load generation process on multiple client systems at the same time. This makes it possible to generate higher levels of load than can be achieved using only a single client system, and it can also be used to more accurately simulate a production environment that may need to deal with large numbers of clients. It is very easy to use. All operations can be performed through a simple HTML interface (which should work flawlessly on any browser that supports HTML 4.01, including text-based browsers like lynx). There is no need to remember the correct set of command-line options to specify all of the customizable parameters. It is very extensible. The tasks that it performs to generate load are called jobs, and the set of jobs that can be run by SLAMD is completely customizable. A number of jobs are provided with SLAMD and are available for use as soon as it is installed, and it has a Java API to allow end users to easily define their own jobs for execution. It can be used for testing virtually any network-based application that can communicate using TCP or UDP. Although it was initially used primarily for performance analysis of LDAP directory servers (and therefore is provided with a number of jobs for performing such testing), it has also been used to interact with servers using the HTTP, POP, IMAP, and SMTP protocols, and it has been tested with the Sun ONE Directory Server, Web Server, Messaging Server, Calendar Server, Portal Server, and Identity Server. 18 Benchmarking the Sun ONE Directory Server 5.2 with the SLAMD Distributed Load Generation Engine

19 SLAMD contains a scheduler, which allows a user to either run a job as soon as possible or at a specified time in the future. In addition, it contains a mechanism to define dependencies between jobs so that a number of jobs can be scheduled ahead of time and will run one after another in a predetermined order. This makes it possible for benchmarking to continue around the clock without the need for administrative interaction, allowing you to get more work done in less time. All job data is automatically stored in a configuration directory server. Whenever a job is scheduled, details about that job are stored in the directory server. When a job completes, the statistics collected while it was running will be added to the directory as well. Therefore, the information is automatically preserved, and it is easy to retrieve information about jobs that have been completed in the past. The statistics collected while a job was running can be accessed in many different ways. By default, SLAMD summarizes this information for the entire job, but it is possible to display the data collected at different points in the job's execution, and the performance of each client, and even each thread on each client can be examined individually if it is so desired. SLAMD can generate graphs of the data, which makes it possible to visually examine performance characteristics about the job, and you can even export the data in tab-delimited text form for use in other applications. SLAMD makes it very easy to compare statistics collected by multiple jobs, both numerically and graphically. This can be very useful for "before and after" kinds of analysis in which you want to determine the performance impact associated with changing a configuration option. It can also be useful for monitoring performance over time, for example to make comparisons between daily builds of a product to see what kind of impact changes made between the two builds might have had on performance. SLAMD consists of two main components. The first and simplest is the client. The client is an application that establishes a connection with the SLAMD server and announces that it is available to process jobs. Upon receiving a job request from the server, it will execute the requested job and return the results to the server. Multiple instances of the client can be run on the same system, and clients can connect to the SLAMD server from a number of different systems. The other component is the SLAMD server. The server actually consists of a number of components in itself, including one that interacts with clients, another that manages the jobs that have been scheduled, and a third that handles all interaction with the end user through the administrative interface. Introduction to the SLAMD Distributed Load Generation Engine 19

20 LDAP-Specific Jobs Provided with SLAMD As mentioned above, SLAMD can be used for load testing and performance analysis of virtually any kind of network server that communicates using TCP or UDP, and it is provided by default with jobs for interacting with a variety of protocols. However, to this point it has been used most extensively for conducting benchmarks of LDAP directory servers, and as such it is provided with a number of jobs that can be used to measure the performance of such servers, and those include the following jobs: SearchRate -- This job is used to generate search load against the Directory Server. It is very similar to the searchrate command-line utility in the Directory Server Resource Kit, but it does have a number of distinct advantages, including the ability to use SSL, the ability to follow referrals, and the ability to insert a delay between searches in an attempt to generate a specific, consistent degree of load against the server. Weighted SearchRate -- This job is very similar to the SearchRate job, but it makes it possible to specify two different filters and the frequency with which each will be used. This can be very useful when trying to simulate real-world search load against the directory server, in which the majority of the searches are against a relatively small subset of the entries (e.g., 80% of the searches are targeted at 20% of the entries in the directory). This is particularly useful when the data set is larger than will fit in the Directory Server's entry cache because real-world searches that occur in this type of pattern are more likely to be in the cache than searches on infrequently-accessed entries. ModRate -- This job is used to generate modify load against the Directory Server. It is very similar to the modrate command-line utility in the Directory Server Resource Kit, but it does have a number of distinct advantages, including the ability to use SSL and the ability to insert a delay between searches in an attempt to generate a specific, consistent degree of load against the server. Weighted ModRate -- This job is very similar to the ModRate job, but it makes it possible to specify two different entry DNs (or more appropriately DN patterns) that can be used to target different sets of entries with different frequencies. ModRate with Replica Latency -- This job is very similar to the ModRate job, but it has the added benefit of being able to measure replication latency. That is, while in the process of making modifications to a specified set of entries in the Directory Server, this job will also periodically make changes to a special entry that it is monitoring on the consumer system using a persistent 20 Benchmarking the Sun ONE Directory Server 5.2 with the SLAMD Distributed Load Generation Engine

21 search, measuring the time between the change on the master and the detection of that change on the replica. Weighted ModRate with Replica Latency -- This job is a combination of the Weighted ModRate and the ModRate with Replica Latency jobs. That is, it can perform modifications against two different sets of entries with different frequencies, and at the same time can measure the replication latency associated with those changes. Search and Modify Load Generator -- This job provides a combination of the SearchRate and ModRate job classes in that it allows the user to provide a set of search criteria that will be used to locate entries, and then will modify each entry returned from processing the search. This provides a rough means of generating both read and write load on the server using the same job to measure the impact that they have on each other. AddRate -- This job provides a means of measuring the performance of the Directory Server while processing add requests. It is somewhat similar to the infadd utility in the Directory Server Resource Kit, with the exception that it also provides the ability to use SSL, the ability to customize (on a somewhat limited basis) the kinds of entries that are added, and the ability to insert a delay between adds in an attempt to generate a specific, consistent degree of load against the server. The entries will be added with a sequentiallyincreasing numeric value in the DN, and this job is designed to work well with the DelRate job. Template-Based AddRate -- This job is very similar to the AddRate job, with the exception that the entry to add is generated based on a template (very similar to that used by MakeLDIF). This makes it possible to simulate entries that more accurately reflect the data in the actual directory environment. AddRate with Replica Latency -- This job is very similar to the AddRate job, but it also provides the ability to measure the latency associated with replicating the new entries to another server. It measures this replication latency using the same process as the ModRate with replica latency. DelRate -- This job provides a means of measuring the performance of the Directory Server while processing delete requests. It will delete entries with a sequentially-increasing numeric value in the DN, and it is designed to work with entries created using the AddRate job. DelRate with Replica Latency -- This job is very similar to the DelRate job, but it also provides the ability to measure the latency associated with replicating the deletes to another server. It measures this replication latency using the same process as the ModRate with replica latency. Introduction to the SLAMD Distributed Load Generation Engine 21

22 Add and Delete Rate -- This job combines the work performed by the AddRate and the DelRate jobs into a single unit that adds a specified number of entries, waits for a specific period of time, and then deletes them. Since the net result of this job should be a directory that is the same as before it started, this job can be run repeatedly without causing failures or requiring cleanup between iterations. This means that it can be used in an optimizing job whereas the standalone AddRate and DelRate jobs cannot. Template-Based Add and Delete Rate -- This job is very similar to the Add and Delete Rate job with the exception that the entries to add to the server are generated using a provided template rather than in a hard-coded format. CompRate -- This job provides a means of measuring the performance of the Directory Server while performing LDAP compare operations. It has features similar to other kinds of jobs, including the ability to issue the requests over SSL and the ability to define a delay between requests in an attempt to impose a fixed load against the directory server. AuthRate -- This job provides a means of measuring the performance of the Directory Server while performing authentications. This is very different from the authrate command-line utility provided in the Directory Server Resource Kit because it does much more than just binding to the server, and it does not drop the connection between authentications. Rather, this job simulates the queries that an application might issue to the directory server if it were trying to authenticate a user. Specifically, it will first perform a search to find that user's entry and will then attempt to bind as that user. It will also optionally perform the additional work of determining whether the user is a member of a specified static group, dynamic group, or role in the Directory Server. Digest-MD5 AuthRate -- This job is very similar to the AuthRate job in that it simulates the process of authenticating users to the Directory Server. However, instead of using simple authentication, this job performs a SASL bind with the DIGEST-MD5 mechanism. This provides a means of using password-based authentication without actually exposing the password in clear text in the bind request, and it may be desired in some environments that want to use password based authentication without SSL but do not want the risk of exposing passwords to clients that might have access to capture traffic sent over the network. Weighted AuthRate -- This job is very similar to the AuthRate job in that it simulates the process of authenticating users to the Directory Server. However, it allows for the possibility of specifying two different sets of users to use in the authentication, and also the frequency with which each type of user is to be chosen. 22 Benchmarking the Sun ONE Directory Server 5.2 with the SLAMD Distributed Load Generation Engine

23 LDAP SiteMinder Load Simulator -- This job simulates the load that Netegrity SiteMinder places on the Directory Server whenever it is configured to authenticate users with password services enabled. For environments in which SiteMinder is used, this job provides a means of generating load against the Directory Server so that it can be optimally tuned for that kind of usage. Note that this job communicates directly with the Directory Server itself and does not include any additional processing that SiteMinder may perform in the process of authenticating a user. Therefore, the authentication rate that this job is able to achieve may not accurately reflect the authentication rate of SiteMinder itself. LDAP Weighted SiteMinder Load Simulator -- This job is very similar to the LDAP SiteMinder Load Simulator job, but also adds the ability to use a weighted access pattern when choosing the users to authenticate. Solaris LDAP AuthRate -- This job simulates the load that Solaris 9 clients place on the Directory Server when they are configured to authenticate users with pam_ldap. For environments that do use pam_ldap, this job provides a means of generating load against the Directory Server so that it can be optimally tuned for that kind of usage. Note that it may not be possible to simulate all the ways in which pam_ldap may access the Directory Server, although it is configurable to allow you to choose the credential level and authentication mechanism. LDAP Load Generator -- This job provides the ability to perform a number of different kinds of operations against the directory server. In particular, you can specify the frequencies with which add, compare, delete, modify, modify RDN, and search operations are processed. It can be useful for simulating the performance of the server under various kinds of mixed load, although it does not attempt to simulate the behavior of any specific real-world client. LDAP Weighted Load Generator -- This job is very similar to the LDAP Load Generator job, but also adds the ability to use a weighted access pattern when choosing the DNs of the entries to target for modify and compare operations, and also when choosing the filters to use for search operations. LDAP Load Generator with Multiple Searches -- This job is very similar to the LDAP Load Generator with the exception that it makes it possible to perform multiple kinds of searches rather than just one type. This makes it possible, for example, to include a large number of equality searches on a unique attribute while also issuing a smaller number of substring searches. LDAP Prime Job -- This job provides a means of priming the Directory Server's entry cache by retrieving an indexed attribute whose value is a Introduction to the SLAMD Distributed Load Generation Engine 23

24 sequentially incrementing number. This can be much faster than a simple "(objectclass=*)" query because it can be multithreaded and because all the searches are indexed. While this job is not itself really intended to be used for measuring the performance of the server, it is very helpful in priming the Directory Server before running other jobs. SLAMD Versus Other Load Generation Software Although SLAMD is a very powerful utility for benchmarking directory servers and other network-based applications, is is not the only such utility. When working specifically with LDAP directory servers, there are two other relatively well-known utilities that can be used for such work. Those utilities are DirectoryMark and the Sun ONE Directory Server Resource Kit. DirectoryMark DirectoryMark is a utility developed by Mindcraft and Netscape Communications that has an ability to perform some basic load generation and performance analysis against the directory server. In general, it attempts to simulate the load placed on the directory server as it is used in a messaging environment. The two primary tests that it offers are intended to simulate messaging clients (clients that perform equality searches on a unique attribute) and address book clients (clients that perform substring searches). DirectoryMark is essentially a collection of Perl scripts. One script, dbgen.pl, is a utility for generating LDIF files. Unlike MakeLDIF, dbgen.pl is rather inflexible and there are only a few configurable options. The hierarchy that it generates is not representative of what is used in most real-world deployments, and the set of attributes included in those entries cannot be easily modified. Another Perl script, scriptgen.pl, is a tool that parses the LDIF file created by dbgen.pl and generates other Perl scripts that will interact with those entries in the directory in a predefined manner. SLAMD offers a number of advantages over DirectoryMark: SLAMD is much more user friendly than DirectoryMark. It offers an HTML interface that does not require the user to remember any command-line arguments. SLAMD is much more flexible than DirectoryMark. DirectoryMark offers two primary test modes (messaging and address book), and it cannot easily be 24 Benchmarking the Sun ONE Directory Server 5.2 with the SLAMD Distributed Load Generation Engine