I have an Rest API hosted in Azure function, exposed via Azure APIM. The total execution time of the API is 1 to 2 seconds via postman. Below is the time split up in Postman. The DNS look up is 400ms and SSL handshake is 1154 ms. Could this be reduced.
Related
I am testing a API endpoint via postman
Postman screenshot
The transfer start time period is 1271.98ms which is a bit longer than I expected.
I check the Cloudwatch logs for this request, the integration latency for it is62ms.
API-Gateway log
Because this transfer start time period displayed by postman doesn't contain DNS lookup, TCP/SSL handshake. I am curious why there is such a difference due to the endpoint processing is quite fast.
I expect postman transfer start time period is the same as API-Gateway integration latency.
We are using the WEB Socket connection to push messages to our Front end Browser. Following is the architecture:
Backend Service A is the backend service that uses WAMP RPC WEB socket invocation to push the message to the Browser via a Proxy P1 which receives the message from the Service A and forwards it to the browser via the WEB Socket connection. Proxy takes some extra responsibilities like authentication and plays a role in all the communication between the browser and the back service A.
We are observing high Latency issues during the initial web socket connection itself via the proxy and latencies are going as high as 8-12 seconds. (p99 average)
We seek help to debug the issue.
We have already checked if Backend Service A which created the WAMP Router is sufficiently provisioned and a similar check was also made for the Proxy Layer in terms of over CPU, memory, connections.
Backend Service A is using https://github.com/gammazero/nexus
Proxy is written in node.js and in the following way websocket is being initialized:
new WebSocket(
`<URL>`,
'wamp.2.json',
{
origin: 'http://localhost',
headers: {
'Sec-Websocket-Protocol': ['wamp.2.json', 'wamp.2.msgpack']
}
}
)
wamp.2 dictates to use wamp for the web socket connection.
We did not find any configuration to explicitly specify the number of wamp connections etc anywhere in the backend service A and in the proxy layer. Kindly help with how can we debug the high latency issue. One of the possible root cause which we found till now is related bad browser internet connection, however, this should not translate to 8-12 seconds of p99 avg latency.
We were experimenting load balancing startegies for grpc based services in aws cloud. In addition to client side load balancing recommened in grpc platform, we also wanted to try the ALB offered in aws over the grpc protocol. We created a grpc service written in golang with two instances and followed all the steps like creating Target groups, configuring an ALB over grpc protocol and health checks. We wrote a load generation[in golang] tool to send concurrent requests to the service. The load generation tool creates a single grpc client connection and uses the same to send concurrent requests. When the concurrency[workers] is increased[~1000] and run for a period of time, some requests are failing with below error.
code = Unavailable desc = transport is closing
For 250K requests to the ALB in 20mins, around 1k requests were failing in small batches with the above error.
Then to identify the root cause, we used a NLB to test the same load and didn't get any errors.
Note: We are aware that NLB won't load balance requests over single client to multiple instances. This is done just to identify the cause of error.
We added channelz to the service and monitored the number of failed messages in all channels/sockets. The number of failures are below hunder[~70] in the channelz stats.
We also noticed that the monitoring stats for the alb showed 4xx error codes.
Please share suggestions to debug the failures from ALB or articles around the internals of AWS ALB to figure out the solution.
I have a web application that makes 100 AJAX requests per second to the server from 1 client. Now the issue is my server is overloaded and I am currently load balancing the server with high cost. So can I use web sockets instead of AJAX requests will that reduce the server load?
I have a service which requires the usage of refresh credential API from Gmail and I have recently noticed a surge in HTTP 503 errors for the following API: https://accounts.google.com/o/oauth2/token
This happens for a certain duration of times and twice it coincided with a gmail downtime according to Google App Status. I have also checked to make sure that any Quota limits for gmail API was not hit from the admin console.
Please advice on how to proceed further on this.
Editing the question to provide further details from comments:
There are separate limits on authentication API (like the token endpoint).
-- Where do I find the limits on authentication API in Google developer console? I could only find the limits for Application APIs like Gmail/Google Calendar.
Questions:
How often are you calling this API/token endpoint?
-- once every ~50-60 mins for a user
Is this for the same user/token? (for the same user, you should try to use the access token until the expiry time that is 1 hour).
-- No this is for different users. For the same user, the same access token is used until its expiry.
If your server is making a lot of requests for different tokens/users, are they coming from the same IP?
-- They are not coming from the same IP, but from few servers (~5) which makes these requests.
What is the max qps you may be hitting?
-- 300 qps on an average (aggregated from all our servers), max would be 450 qps.