API focus

APILoader is intended for load testing servers that are addressed by a Java API.

The API might be proprietary, embedded in one layer of your system, for talking to another layer. Or it might be part of a public or private SDK (such as the Amazon Web Services API clients in the AWS SDK). Or it might be built into your web site and present a web interface on one side and an API interface on the other (such as in the Weather Channel's web site). Whichever way the servers are ultimately addressed by a lump of Java code that talks to the servers via a mutually understooed protocol.

And don't worry about protocols. Your API-client defines the protocol so whatever it uses, APILoader supports. You just have to give it a name. Tough, but doable.

Simple to use - no recording, scripting, or programming

Once the Java API client has been uploaded to the tool use cases that invoke the methods of the client are created via dropdown selection.

So to create a three-step use case:

• Name the use case and press "Create" in the load generator window
• Select the new use case and press "Steps"
• Press "Add at end"
• Press the "API calls" radio button
• Select the API client method to be invoked in the drop down
• Press "Add"
• Repeat the last 4 steps two more times
• Press "Save"

And you are done. You still have to specify a run time data source for each call but you have a usable use case. This you put into a load and run the load. At execution time the three methods of the API client will be invoked and the server loaded accordingly.

Simple run-time data

Each of your API client requests will need some data to work on.

You can provide that data from:

• constants
• tool-scope variables
• run parameters
• unique name / value generators
• output of earlier calls
• Java code
• run-time data files

Often the APIClient will require as input objects of types known to the client but not to APILoader. No problem. We give you access to the constructors of the classes known to the API client so you can construct objects of the necessary types.

And fluent methods ?. Yes, we do those too.

Stable artifacts

Use cases and data provisioning are relatively cheap to do in APILoader. Doesn't mean we don't value them though. We make a real effort to preserve your investment in these over changes - such as a new version of the API client. You should only have to adapt your use cases and data provisioning to the specific changes in the new version. Yeah, okay, sometimes we don't do so good and you have to do a bit more. But we guarantee you will never, ever, have to rerecord a script !

Very, very high throughput

With a very light API we have achieved 2,000,000 API calls per second, sustained for over an hour, and producing over 8bn timing points.

We are in the process of determining sustainable throughput with a more realistic API - in this case that of the Amazon EC2 API client. The difficulty in establishing this number is that we have to implement our own server that supports the API. And it needs to be very, very fast itself.

In the unlikely event that you need more throughput than we currently provide this is likely to be possible. We do not yet fully exploit the largest Amazon EC2 server types. And we expect to be able to replicate the component of APILoader that is bottlenecking througput.

Mobile application ready

You've encapsulated the mechanics of conversing between your mobile app and its supporting server(s) into a Java class. Right ?

Then APILoader can help you.

Upload the Java class, answer some questions, and start testing the performance of the application with the servers under load.

See LoMAppS the upcoming pay-per-run mobile application performance testing tool.

Cloud capable

APILoader runs in the cloud - currently Amazon Web Services. It will however run on local machines, including your PC, in-house servers, or a combination of all three (firewalls permitting).

It will run on a single PC or on a host of cloud boxes. Our current high-water mark is 42 large cloud machines.

Allocation, configuration, provisioning, and exploitation of the machines used is of course completely automatic.

You can monitor resource usage on any machine allocated by APILoader and, if necessary, logon to the machine to explore in more detail.

Storage of run results can also be in the clouse, on in-house file servers, or the run-initiating machine.

Load testing process aware

APILoader is aware of the load testing process. So it allows you to define and use all the common load testing artifacts - like use cases, loads, data files, resource files, targets, configurations, runs, run templates, results, system-under-test credentials (encrypted, of course), presentation widgets, cloud provider accounts, results stores, ...

Runs and results are filed within run series within test phase within test so its easy to find the results of a given run or to repeat a run.

APILoader supports accounts, which are hermetically sealed from one another. And projects, which are named collections of the resources above. So you can focus on some particular testing without being distracted by all the other testing that is going on. One day we will allow you to be selectively distracted. But not today.

Analytics

Naturally APILoader allows you to analyse run results. If the query makes sense you can commission it by a few selections on the results query screen. Don't worry about there being a billion or several billion timings in the run. 5 seconds and you will have your answer.

Multi-user

APILoader is a J(2)EE application and is intended for multi-user use

That being said, we have to admit we aren't yet in a position to properly test multi-user use. But what we have proven is the ablility of a single user to perform a lot of actions in parallel.

JMeter-based

AIPILoader has a heart of JMeter. What more needs to be said? Only that we make the test plans for you.

Take for granteds

A load testing tool wouldn't be worth a pinch of the proverbial if it wasn't realiable, accurate, ... . You can take those for granted. We do.