Gigya's services appear slow or unresponsive. Responses time out or show indications of high latency.
No matter how far Gigya's servers are from an implementation, even under ideal circumstances, there is some degree of latency between computers as information is passed via switches, between networks, and across the internet. However, issues sometimes arise which cause unusual latency and unresponsiveness to occur. Sometimes latency can be the result of a network infrastructure issue between both parties; sometimes latency can be a result of issues with network infrastructure on one side of a communication chain, and sometimes latency can be the result of a software issue at one end of the communication chain. Further, external forces can sometimes artificially introduce latency issues or create false positives in monitoring software. These external forces can be contributed by (but are not limited to) things such as poor implementations, unusual traffic patterns, or improperly configured monitoring tools.
Because of this, latency issues can at times be difficult to identify, investigate, and diagnose.
It can be helpful to double check the network infrastructure between Gigya and other endpoints by running both a TraceRoute and an NSLookUp from point of failure to Gigya (cdn.us1.gigya.com). Additionally, switching the DNS settings to use Google's free DNS servers (126.96.36.199 / 188.8.131.52) can sometimes provide remediation.
If no remediation can be found using the information above then a Gigya Support request can be submitted to assist. Gigya will always attempt to investigate latency issues in good faith using the logs and monitoring that we have at our disposal; however, in many cases, no issue can be identified without additional information. Therefore, when seeking assistance with such an issue (e.g. slow responses from the REST API. gigya.js not loading, etc.), Gigya should be provided with the following data points:
- The time of the request (with Timezone);
- The requested object (the URL of the requested JS, image etc.);
- The location where the tested was executed (the agent name);
- The resolved IP address of the destination;
- DNS resolve time;
- TCP connect time;
- Download time;
- Time to first byte;
- Total request time;
- Client IP Address;
- DNS IP Address; and,
- The output results of an MTR trace run against cdn.gigya.com
Much of the information above can be provided by using a tool such as WireShark to capture the requests and Gigya will often request such a capture to continue an investigation.