CloudBlue Commerce API (DRAFT)
Table Of Contents
Performance¶
Although the APS development team pays much attention to making the UI operations as fast as possible, there are still some cases when the custom code in an application can radically affect the performance and consequently the user perception.
In addition to multiple descriptions of JavaScript and other scripting languages performance pitfalls and tips you can find in the Internet, this document addresses some performance-related approaches specific for applications integrated with the platform.
In this document:
Frontend Connections¶
Interaction with Host¶
As noted by many developers using JavaScript, the interactions of a browser with the host affect the performance most of all. In APS, each REST request requires the APS controller to get or update an object or several objects in the database. In many cases, the APS controller has to interact with the application to complete an operation.
An HTTP request imposes the TCP handshake to establish a TCP connection before data is transferred. An HTTPS request, in addition to TCP handshake, requires also the SSL/TSL handshake.
All REST requests based on HTTP/1.1 and higher version contain the Connection:keep-alive header that requires the
server to use a single TCP connection to exchange multiple HTTP requests/response pairs. This is also known
as a persistent or keepalive connection.
If there is no activity on the TCP connection longer than the timeout defined by the server (5 sec in the
Apache 2.2 default configuration), the server closes the connection.
When in a REST request/respond the message body (payload) is pretty small (simple APS resources) and fits into a single packet, the HTTPS handshake requires more time than the data transfer itself.
Network Latency and Bandwidth¶
The network latency and bandwidth affect the UI performance substantially. In turn, they depend on the following:
The protocol used at the Network Interface layer. For example, mobile devices connected through 2G/3G experience not only less bandwidth but also much longer latencies compared with 4G and WiFi. Generally, wired network interfaces tend to have the lower latency as compared with wireless interfaces.
Geographical latency. Usually, the longer distance between a client and the server, the longer the latency is. It is caused by longer cables and more router hops. On long links (roundtrip time is 200-400 ms), an HTTPS handshake adds about 1 second or more.
Browser Limitation¶
Each browser is limited in the number of HTTP connections it can keep concurrently with the same host. In our case, the latter is the platform management node where the APS controller is functioning.
The limit requirements in the HTTP standards are even stronger, for example, refer to RFC-2616, HTTP/1.1 Connections, Chapter 8.1.4 that states “Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy.”.
For this reason, if an application JavaScript code sends many REST requests to the APS controller, the browser can delay the last requests until the previous are completed.
In the above diagram, the Google Chrome browser keeps up to 6 concurrent HTTP requests for the management node. Each request uses a separate HTTPS connection. The scenario presents 8 resources to be updated at once, for example, all are being started or all are being stopped. The whole process goes through the following intervals:
The first request (#1) starts on the HTTPS connection left open after the navigation procedure.
The next five requests (#2-6) start with DNS lookup and HTTPS handshake procedure.
The first six requests (#1-6) use the HTTPS connections in parallel. The other two requests (#7-8) are in the queue.
After the request #1 is closed, its HTTPS connection is still open, which allows the request #7 to start on it without a handshake.
After the request #2 is closed, the request #8 starts on the HTTPS connection left open.
Performance Alerts¶
When testing and debugging your custom code on the platform in the development mode, you may notice some pop-up alerts saying that your code exceeds some limits on REST requests. The system also sends the same warnings to the JavaScript developer console even when the platform functions in the normal mode.
There are the following types of alerts:
Burst calls - the number of calls to all URLs exceeds 20 requests per minute (RPM).
Too frequent polling - the number of calls to a URL exceeds 4 RPM.
Backend Connections¶
On its backend, the APS controller interacts with endpoint servers:
As a client, it sends REST requests to application endpoints, typically through the TCP port 443.
As the server on the APS bus, it receives REST requests from application instances on its input TCP port 6308.
Note
For all APS connectors on the APS bus, the APS controller is the only client and the server, since applications cannot interact with each other directly on the bus.
In both cases, the session between the two parties must be secure, meaning the HTTP session must run over the transport layer security (TLS) protocol. We usually call this ‘HTTPS connection’ that ensures the confidentiality (preventing eavesdropping) and integrity (preventing tampering) for the transferred data.
The TLS handshake spends additional time to negotiate the details of the encryption protocol and then to generate and share a unique symmetrical key, known as the session key, used to encrypt and decrypt the TLS payload including the HTTP URL address string, headers, and data. The identity of both parties is authenticated using the asymmetric public-key cryptography.
The APS controller either as the client or the server supports the SSL session reuse. This speeds up the handshake almost twice as much when a client reconnects to the server. The session reuse method is based on saving the SSL session key. To verify it on your platform installation, use, for example, the OpenSSL tools as explained at the serverfault site:
~$ s_client -connect a.isv1.apsdemo.org:6308 -reconnect
// ...Most part of the print-out is omitted for brevity...
---
drop connection and then reconnect
CONNECTED(00000003)
---
Reused, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : AES256-GCM-SHA384
Session-ID: 0CFD2226C0555C88D1B94B06F158132E3705428B78ED1D3A9DAD19725F23FC33
Best Practice¶
Concurrent Requests¶
As illustrated earlier, the number of concurrent HTTPS connections with the management node
is limited (usually up to 6) by a browser. For example, if the number of XHR calls in a JavaScript code exceeds this
limit by 1, the time that a user waits for the completion of an operation can nearly double. Generally, if the
browser sends N requests the completion time will be approximately T*N/6, where T is the time required
for one request.
In addition, the web server resets a persistent connection in several seconds of inactivity. It means, if the user does not show any activity that requires access to the APS controller for longer than 5 seconds, the requests run after that will require establishing new HTTPS connections.
To further improve SSL connection performance, both OSS and BSS UI servers support the SSL session reuse.
Loading State¶
If a UI operation takes a long time due to large data or low connection, show the “Loading…” state for the user
meanwhile.
For this purpose, in the onContext method, do not run aps.apsc.hideLoading() until all necessary data is
retrieved. In other cases, you can call aps.apsc.showLoading() to show the “Loading…” state.
Backend Sessions¶
To get benefits of the SSL session reuse embedded into the APS controller, the endpoint host must support that
mechanism at least as a server. Take this into account when setting your proprietary server or configuring a third party
server, for example, Apache (SSLSessionCache directive)
or nginx (ssl_session_cache directive).
When developing your own SSL client or using a third party SSL client, for example, cURL wrapped around OpenSSL or other SSL libraries, use at least one of the following methods to avoid rapid decrease of performance:
If the application needs to send several requests to the APS controller, do not close the session until all those requests are completed. Typically, the APS controller calls an application method, and the application sends several requests back to the APS controller to get needed data required by the called method.
If the application needs to open a new connection to the APS controller often, configure the client to reuse the SSL sessions.
Impersonation¶
When there are a huge number of subscriptions on the application services, it is important to restrict the number of resources involved in an application call. When an application method requests a list of resources by APS type, it will scan through all resources of that type in all subscriptions although the method typically needs only the resources of a specific subscription or an account. When the number of resources is tens of thousands, it may cause a substantial delay and server load. The recommended way to limit the number of resources for an application is to impersonate the current subscriber as explained in Security Context. In this case, the application is granted access only to the customer’s resources.