There are two main sets of data you can look at around Gateway performance criteria.
Performance of the API Gateway
This should not be the focus of performance evaluation - a Gateway is in an environment and the gateway usually isn't an end point. In some specific use cases, i.e. the OAuth Toolkit in token issuance, the gateway has some cases that it is the "end point", but even that depends on some kind of data storage subsystem. In a few cases, for specific requirements, the performance of individual elements, like "Sign JWT" have bearing on overall performance. Some assertions, especially cryptographic ones, have a real cost - Sign JWT is CPU intensive and can take hundreds of milliseconds per signature, depending on the algorithm.
Performance of an API measured BY the API Gateway
This would be by far the more important set of criteria. In a properly designed gateway policy, the performance of back-end APIs and subsystems is far more salient to overall performance than the gateway itself. In such a case, the latency of back end APIs, maximum throughput, the performance of the subsystems consulted by policy - subsystems like LDAP, databases, Identity and Access Management systems all contribute more to overall performance than the gateway itself. There are several ways to evaluate performance, and while Transactions Per Second often shows up as a number one customer requirement, it is our view that latency is crucial - if you have good latency, TPS will take care of itself. Good latency, by the way, is measured in milliseconds. Our view is that an ideal back-end should average in the 10 to 150-millisecond range.
See: Thinking in Policy - CA API Gateway - 9.2 - CA Technologies Documentation for what "properly designed policy" means in this context.