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.
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.
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.
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.”.
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.
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.
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.
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
As illustrated earlier, the number of concurrent HTTPS connections with the management node
limit by 1, the time that a user waits for the completion of an operation can nearly double. Generally, if the
N requests the completion time will be approximately
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.
If a UI operation takes a long time due to large data or low 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.
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 (
or nginx (
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.
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.