This page describes some performance testing conducted by CA Technologies.
Performance is a notoriously difficult thing to measure. There are many variables. This page describes only one testing setup. Your mileage will vary.
Performance is usually measured using two broad axes:
But we live in the real world, and there are many factors influencing this.
Obviously, the faster your CPU(s), the faster Live API Server will run -- assuming the database and the network can keep up.
Live API Creator is designed to take advantage of as many servers, CPUs and cores as possible. In theory, there is no limit to how many can be used, but in practice at some point some other component will start to be the limiting factor: the database or the network are the most common.
Live API Creator is (usually) not memory-hungry. How much memory you should allocate to it depends a great deal on the size of your database model(s), how much logic you have defined, and how many concurrent requests you get. For most applications, 1GB of heap per server is sufficient. For smaller systems, 512M is often sufficient.
Latency to the database measures how long it takes for a query (or insert, update, delete, etc...) to get to the database, and how long for the response to get back, excluding the time it takes to execute the query. Latency is one of the most critical factors in performance. If the latency to your database is more than a millisecond, you may start seeing some performance degradation. It's usually a very good idea to physically place your Live API Server as close as possible to your database server(s).
This is another critical factor. Live API Creator, by definition, cannot go faster than your database server(s). If a query takes a long time to execute (perhaps because of an inefficient execution plan, or improper indexing), performance will suffer accordingly. This can often be optimized with better queries, better indexing, and other common database optimization techniques.
If you define complex resources, with many levels, the retrieval of all that data may take some time. This is not necessarily a bad thing if the alternative would be to make many requests. It's usually better to spend a little time in the server than to make many requests.
If you define a lot of rules, and these rules are complex, e.g. they make calls to outside systems, or they make complex calculations or queries, then anything that results in the invocation of that logic will obviously incur its cost.
If your security settings are complex, e.g. you have defined a lot of permissions for a table, then the execution of the queries may be slowed down due to the increased complexity of the SQL.
When we test performance, we use the following environment. All servers are located in the same room, on a 1GB/s network.
This is the server that runs Live API Creator on Tomcat 8.
OS: CentOS6.7 (this changes over time, of course)
This server runs CentOS 6.7 and MySQL 5.6. It holds the admin database, e.g. the database that stores all of Live API Creator's metadata (resource definitions, rules, etc...)
This server runs CentOS 6.7 and Postgres 9.4 This is the database that contains the "user" data, in this case a simple schema consisting of customers, orders and line items. The database contains several million rows.
This server runs CentOS 6.7 and JMeter. It runs the testing scripts. This can be quite demanding -- it is not unusual for this machine to run out of steam before the others.