Table Of Contents

Previous topic

Personal Data

Next topic

API Reference

Performance

Although the APS development team strives to make the UI operations as fast as possible, there are still some cases when the custom code in an application can radically affect performance and, consequently, the user perception.

In addition to multiple descriptions of JavaScript and other scripting languages performance pitfalls and tips you can find on the Internet, this document addresses some performance-related approaches specific for applications integrated with the platform.

Frontend Connections

Interaction with the Host

As noted by many developers using JavaScript, the interactions of a browser with the host affect 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 must 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 the TCP handshake, also requires 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 and 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 seconds in the Apache 2.2 default configuration), the server closes the connection.

When in a REST request and respond the message bodies (payload) are comparatively small (simple APS resources) and fit 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 or 3G experience less bandwidth and much longer latencies than 4G and WiFi. Generally, wired network interfaces tend to have lower latency than wireless interfaces.

  • Geographical latency. Usually, the longer distance between a client and the server, the longer the latency is. This is due to longer cables and more router hops. On long links (with a roundtrip time of 200-400 ms), an HTTPS handshake usually adds more than 1 second.

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 functions.

The limit requirements in the HTTP standards are even stronger. According to RFC-2616, HTTP/1.1 Connections, Chapter 8.1.4, “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.

../../_images/many-xhr-timeline.png

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:

  1. The first request (#1) starts on the HTTPS connection left open after the navigation procedure.

  2. The next five requests (#2-6) start with DNS lookup and HTTPS handshake procedure.

  3. The first six requests (#1-6) use the HTTPS connections in parallel. The other two requests (#7-8) are in the queue.

  4. After request #1 is closed, its HTTPS connection is still open, which allows request #7 to start on it without a handshake.

  5. After request #2 is closed, request #8 starts on the HTTPS connection which is 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 regular mode.

../../_images/performance-alert.png

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, as 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 refer to this as the ‘HTTPS connection’ that ensures the confidentiality (by preventing eavesdropping) and integrity (by preventing tampering) of 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 use special tools such as the OpenSSL client as explained at the serverfault site:

~$ s_client -connect a.isv1.apsdemo.org:6308 -reconnect

// ...Most 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

Long List of Resources

One of the most common REST requests is a request for a list of APS resources that match a certain RQL statement. Even if a request limits the number of returned resources implicitly or explicitly (by the limit function), in accordance with the pagination rules, the platform must calculate the total number of the resources, regardless of that limit. This calculation impacts the platform performance. The following recommendations help you reduce that impact:

  1. When requesting a list of resources, send the APS-Skip-Content-Range header to avoid the calculation of the total number of resources in the database.

  2. If you still need to know the total number of resources that match a certain criteria, use the limit(0,0) RQL function and get the result in the Content-Range header.

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 after several seconds of inactivity. This means that 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 SSL session reuse.

Loading State

If a UI operation takes a long time due to large data or a slow connection, show the “Loading…” state for the user. 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 a rapid decrease in 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 the data required by the called method.

  • If the application needs to open a new connection to the APS controller regularly, configure the client to reuse the SSL sessions.

Impersonation

When there is a very large 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 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.