Automation has value only in so far as there are no compromises in architecture (to integrate with existing systems), extensibility (to address elements that are not automated), and performance. delivers on the best-practice patterns by revisiting relevant optimizations on each logic change. performance remains at a high level over maintenance iterations the same as database management system (DBMS) optimizers maintain high performance by revising retrieval plans.
Automation has value only in so far as there are no compromises in architecture (to integrate with existing systems), extensibility (to address elements that are not automated), and performance.
CA Live API Creatordelivers on the best-practice patterns by revisiting relevant optimizations on each logic change.
CA Live API Creatorperformance remains at a high level over maintenance iterations the same as database management system (DBMS) optimizers maintain high performance by revising retrieval plans.
This article details how
CA Live API Creatordelivers enterprise-class performance.
In this article:
Minimize Client Latency
Modern applications might often be required to support clients that are connected through high-latency cloud-based connections. The following
CA Live API Creatorcharacteristics minimize client-connection latency.
When retrieving objects for presentation, you can define resources that include multiple types. For example, a customer with their payments, orders, and items.
CA Live API Creatordelivers these resources in a single response message, so that only a single trip is required.
This requirement is not fully satisfied by views. You cannot update views and joins result in cartesian products when joining multiple child tables for the same parent. In our example, a customer with five payments and ten orders returns fifty rows. This requirement is unreasonable for the client to decode and present.
For more information about how to create a resource, see Customize your API.
Leverage Relational Database Query Power
Each resource/subresource can be a full relational query that you can send. You can send this query in a single trip to the REST server (and then database). Contrast this solution to less powerful retrieval engines, where the client must compute common requirements such as sums and counts. This solution drives the number of queries up
n-fold, which can affect performance.
Large result sets can affect the client, network, server, and database. You can truncate large results, with provisions to retrieve remaining results, such as when the end-user scrolls, using pagination. Pagination can be a complex problem. Consider a resource of customer, orders, and items. If there are many orders, pagination must occur at this level, with provision for including the line items on subsequent pagination requests.
For more information about pagination, see Pagination.
Network considerations apply to update and retrieval. Consider many rows that
CA Live API Creatorretrieves into a client, followed by an update. Clients can send only the changes, instead of the entire set of objects, using APIs. Clients can also send multiple row types (for example, an Order and Items) in a single message using APIs. This results in single, small update message.
For more information about batched updates, see PUT.
Business logic consists not only of validation rules, but derivation rules. These derivation rules can often involve rows visible but not directly updated by the client. For example, saving an order might update the customer's balance. The updated balance must be reflected on the screen.
Clients typically solve this problem by re-retrieving the data, which is an extra client/server trip. And sometimes, it is difficult to program, for example, when the system assigns the order's key.
CA Live API Creatormight know the computed key and might need to re-retrieve the entire rich result set.
CA Live API Creator
Server-Enforced Integrity Minimizes Client Traffic
An infamous anti-pattern is to place business logic in the client. Placing the business logic in the client does not ensure integrity, and causes multiple client/server trips. For example, inserting a new line item might require business logic that updates the order, the customer, and the product. If the client issues these, the result is four client/server trips when only one should be required.
Minimize Database Connectivity
You can minimize database connectivity by customizing the connection pool that is available for each data source, by having
CA Live API Creatorreuse existing connections, and by avoiding the cost of initiating a connection to the database.
For more information about how to define the maximum number of database connections that
CA Live API Creatoruses to create a pool of connections, see Database Connectivity.
Minimize Database Load
CA Live API Creator's logic engine minimizes the cost and number of SQL operations. The following
CA Live API Creatorcharacteristics minimize database load.
Minimize Database Latency
If you must deploy databases in the cloud, and you want to minimize the database latency that you experience from
CA Live API Creator, consider installing
CA Live API Creatorin the same region as the connecting databases.
For more information about security considerations with cloud database connections, see Securing APIs.
Get Logic with Optimized SQLs using Pagination and Chunking
CA Live API Creator's logic engine retrieves rows for multi-level table-based resources with a minimal number of SQL operations.
For more information about
CA Live API Creatorapproach to retrieving rows on table-based subresources, see Define Table-Based Resource Types.
Update Logic Pruning Eliminates SQLs
API Server prunes (eliminates) SQL operations where possible. For example:
- Parent Reference Pruning.API Server accesses parent rows by averting SQL operations if other (local) expression values are unaltered.For example, ifattribute-Xis derived asattribute-Y * parent.attribute-1, API Server eliminates the retrieval for parent ifattribute-Yis unaltered.
- Cascade Pruning.If you alter parent attributes that child logic references, API Server cascades the change to each child row. If the parent attribute is unaltered, cascade overhead is pruned.In the previous example, API Server cascades the value ofparent.attribute-1if it is altered.
Update Adjustment Logic Eliminates Multi-level Aggregate SQLs
CA Live API Creator's logic engine minimizes the cost of SQL operations. For example:
- Adjustment.For persisted sum/count aggregates,CA Live API Creatoradjusts the parent based on the old/new values in the child by making a single-row update. Aggregate queries can be costly when they cascade. For example, the customer's balance is the sum of the order Amount, which is the sum of each order's line item amounts.
- Adjustment pruning.CA Live API Creatoradjusts only when the summed attribute changes, the foreign key changes, or the qualification condition changes. If none of these occur, it averts parent access/chaining.
Consider inserting an order with multiple line items. The following image shows the rules that are organized in the Check Credit topic for the
DemoAPI sample. Per the logic that is shown in the following image,
CA Live API Creatormust update, or adjust, the order total and customer balance for each line item:
CA Live API Creatorretrieves these objects only once and maintains a cache for each transaction. All reads and writes go through the cache. API Server flushes them at the end of the transaction. This eliminates many SQL operations and ensures a consistent view of updated data.
Good performance dictates that data not be locked on retrieval. Optimistic locking typically addresses concurrency. API Server automates optimistic locking for all transactions. The automation can be based on a configured timestamp column, or, if a timestamp is not configured, a hash of all resource attributes.
CA Live API Creatorautomates transaction bracketing. It bundles PUT/POST/DELETE requests (which might be comprised of multiple roles) into a transaction, including all logic-triggered updates.
GET: Optimistic Locking
A well-known pattern is optimistic locking. Acquiring locks while viewing data can reduce concurrency.
CA Live API Creatordoes not acquire locks while it processes GET requests. API Server ensures that updated data has not been altered since it initially retrieved the data.
For more information about optimistic locking, see optimistic concurrency control on Wikipedia.
PUT, POST, and DELETE: Leverage Database Locking and Transactions
CA Live API Creatorlocks update requests using database locking services. Consider the following cases:
- Client updates.In accordance with optimistic locking,CA Live API Creatorensures that client-submitted rows are not altered since retrieval. It write-locks the row using a timestamp, or (if one is not defined) by a hash code of all retrieved data. This strategy means that it does note require a timestamp.CA Live API Creatorcompletes this process as the first part of the transaction. It detects optimistic locking issues before it incurs SQL overhead.
- Rule chaining.CA Live API Creatorread locks the rows that it processes in a transaction as a consequence of logic execution, such as adjusting parent sums or counts.CA Live API Creatoracquires write locks at the end of the transaction, during the "flush" phase.CA Live API Creatorcould have acquired and released other transactions' read locks between the time of the initial read lock and the flush.
CA Live API Creatorcharacteristics illustrate how API Server promotes good performance.
Load Balanced Dynamic Clustering
Cloud-based installations of
CA Live API Creatoron AWS Elastic Beanstalk provide services for dynamic auto-scaling to address increased load. Each server is stateless and
CA Live API Creatorload balances incoming requests over the set of clustered servers.
For more information about auto-scaling and dynamic clustering, see Install on Amazon Web Services Elastic Beanstalk.
Meta Data Caching (Logic and Security)
API Server processes requests into a transaction request by reading the specified logic and security information. It persists the transaction cache over transactions until you alter your logic. For example, inserting an order with five
OrderDetailsresults in an order and a customer adjustment.
Direct Execution (No Code Generation)
For more information about reactive logic, see Reactive Logic.
View SQL Performance
Transparent information about system performance is an important requirement. You can view the logs of SQL and rule execution. You can also obtain aggregate information.
For more information about how to view the logs and how to obtain aggregate information, see the View Logging Information.