Server classes are used within Akamai CloudTest to template Server Instances that will be deployed and then torn down in the cloud at test runtime.
Akamai CloudTest provides default server classes for the Test Server, Results Service, and Monitor services.
In most cases, it is not necessary to define new server classes. However, new classes are easily defined based on the default classes. In customization cases, it is recommended to create a new server class, rather than to modify the default classes. Each class accepts new attributes via an Add button.
For Amazon EC2, CloudTest interacts with the standard instance types include: Large Instance, and Extra Large Instance. CloudTest doesn’t use the EC2 Small Instance type. Additionally, CloudTest provides complete support for instances of the EC2 High Performance Computing cloud and all other AWS instance types, including Cluster Compute Quadruple XL, High-CPU XL, High-Memory Double XL, High-Memory Quadruple XL, and High-Memory XL.
All of the above items have corresponding out-of-the-box server classes accessible within CloudTest via the Central > Server Classes list.
Creating a New Server Class
Note: Akamai recommends that you create a new server class for different instance types, rather than modify the default classes.
To get started, select Central list > Server Classes, and then click New. When you do so, the New Server Class dialog box appears.
You can use the InstanceType Setting to define large and extra-large Test Server and Results Server instances. The physical limits of these instances varies by the cloud provider.
Once a server class is defined, it is available for selection in the Grid Manager on the Server Instances screen's Server Class drop-down.
To specify a different instance type for an existing server class
To use a server class in a grid
To use a server class in server instances
The Known Settings for the given service are displayed.
The following table lists Known Settings by service:
|Test Server (Maestro)|
|HTTP.MaxReceiveContentLength||The maximum number of bytes of an HTTP "message body" that will be received. Bytes past this amount will be received and counted, but then discarded. A negative value means no limit.||-1 INT|
|InterServerComm.RetryCount||Number of times to retry on failure of Test Server-to-Test Server communications.||10 INT|
|InterServerComm.SocketTimeout.Test Server||Socket timeout, in milliseconds, for Test Server-to-Test Server communications.||60000 INT|
|InterServerComm.SocketTimeout.Monitoring||Socket timeout, in milliseconds, for Test Server-to-Monitor-Service communications.||60000 INT|
|InterServerComm.SocketTimeout.Repository||Socket timeout, in milliseconds, for Test Server-to-Repository communications.||60000 INT|
|InterServerComm.SocketTimeout.Results||Socket timeout, in milliseconds, for Test Server-to-Results-Service communications.||60000 INT|
|Loader.ThreadsPerCompositionMax||The maximum number of threads to allocate to loading of objects from the Repository, per Composition being loaded. Only the number actually needed (up to this maximum) will be used, and it changes dynamically over time as required. These threads are allocated from the Thread Pool.||20 INT|
|Pool.MaxAdvanceScheduleTime||The farthest amount of time (in milliseconds) in the future a task will be assigned to a thread in the pool. This value should be set far enough in the future such that a thread will likely be already ready and waiting when a task's scheduled time comes up, but not so far in advance that threads are held in a wait state (and using up system resources) unnecessarily.||5000 INT|
|Pool.MaxWorkerCount||The maximum number of concurrent threads in the pool.||4096 INT|
|Pool.MaxWorkerIdleTime||The amount of idle time (in milliseconds) after which a thread will terminate itself and be removed from the pool. This allows the pool to shrink down after peak loads. This value should be set high enough to prevent unreasonable thread turnover thrashing, but not so high that idle threads with nothing to do are kept around unreasonably (and using up system resources).||10000 INT|
|Pool.WorkerRedirectThreshold||The smallest amount of time (in milliseconds) in the future a thread's current task can be and have it get pre-empted and assigned to a sooner task. For example, 500 means that if there is a thread assigned to a task scheduled to execute more than 500 ms in the future, it will be pre-empted and assigned to a sooner task if there are no more threads available for that sooner task.||500 INT|
|Result.WriteThreadsPerCompositionMax||The maximum number of threads to allocate to writing of information to the Results Service, per playing Composition. Only the number actually needed (up to this maximum) will be used, and it changes dynamically over time as required. These threads are allocated from the Thread Pool.||10 INT|
|PrivateKey.FilePath||The path of the file on the server that contains the Monitor Service private key. There cannot be hard-coded defaults for this setting, which is determined at runtime using the current OS user's home directory.||NONE|
|PublicKey.FilePath||The path of the file on the server that contains the Monitor Service public key. There cannot be hard-coded defaults for this setting, which is determined at runtime using the current OS user's home directory.||NONE|
|Batching.bAsyncBatchInserts||Enter 1 to have the Results Service perform asynchronous batch inserts (e.g. a memory based queue and a thread pool). Default is synchronous.||0 INT|
|Batching.counterUpdateFrequency||The number of seconds between updates of high-level counters such as virtual user count or number of messages. Short times can lead to contention, especially with multiple Results Services.||10 INT|
|Export.Result.ChunkSize.Excel||Returns the number of objects that will be included in a chunk being exported for spreadsheet format.||2000 INT|
|Export.Result.ChunkSize.Medium||Returns the number of objects that will be included in a chunk of "medium" objects. This setting should only be changed if you are tuning the performance of result exports.||100 INT|
|Export.Result.ChunkSize.Small||Returns the number of objects that will be included in a chunk of "small" objects. This setting should only be changed if you are tuning the performance of result exports.||200 INT|
|Export.Result.ChunkSize.LargeReturns the number of objects that will be included in a chunk of "large" objects. This setting should only be changed if you are tuning the performance of result exports.|
|MemoryTable.max_heap_table_size||The max memory that the database layer will use for the MessageFact if memory tables are used. Value in GB.||4 INT|
|Export.Monitor.ChunkSize||Returns the number of objects that will be included in a chunk of monitor data. This setting should only be changed if you are tuning the performance of monitor exports.||200 INT|
|MemoryTable.UseMemoryTable||Enter 1 to use a memory table for the MessageFact table. At completion of the test it will be automatically persisted to disk.|
|Batching.writeAggregatesFrequency||The frequency, in seconds, of how often to write aggregates to disk.||10 INT|
You can add additional attribute value pairs to this class by clicking the Add button, entering an Attribute name, and then defining the Value in the entry field. Click Remove to delete a selection.