function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
Grant FisherGrant Fisher 

Slow REST API return for first call of day (30s+)

Hello, I am hoping that somebody can help me out with a very slow first REST call to our SalesForce test instance. 

We have boiled it down to a few cURL calls for reproducibility. Unfortunately, it is reproducible every day - but only once, after the first slow REST call, all subsequent calls are fast. The first API call to authenticate is fast, but the first to query the /services/data/v39.0/query API is slow. It appears that the instance is warming or caching somehow, but we can't find any documentation about this.

Has anybody seen anything like this before? 30s calls are just too slow for a simple select.

Thanks,
Grant
 
Steps for reproducing -
First, we authenticate:
curl -v --trace-time -X POST https://test.salesforce.com/services/oauth2/token  -H 'content-type: multipart/form-data'  -F grant_type=password  -F client_id=<snip>    -F client_secret=<snip>  -F username=<snip>    -F password=<snip>

cURL verbose of that call:
10:12:09.125368 * About to connect() to test.salesforce.com port 443 (#0)
10:12:09.125867 *   Trying 136.147.58.173...
10:12:09.147686 * Connected to test.salesforce.com (136.147.58.173) port 443 (#0)
10:12:09.148953 * successfully set certificate verify locations:
10:12:09.149214 *   CAfile: none
  CApath: /etc/ssl/certs
10:12:09.149905 * SSLv3, TLS handshake, Client hello (1):
10:12:09.171806 * SSLv3, TLS handshake, Server hello (2):
10:12:09.172253 * SSLv3, TLS handshake, CERT (11):
10:12:09.174550 * SSLv3, TLS handshake, Server finished (14):
10:12:09.175193 * SSLv3, TLS handshake, Client key exchange (16):
10:12:09.175473 * SSLv3, TLS change cipher, Client hello (1):
10:12:09.176019 * SSLv3, TLS handshake, Finished (20):
10:12:09.196838 * SSLv3, TLS change cipher, Client hello (1):
10:12:09.197305 * SSLv3, TLS handshake, Finished (20):
10:12:09.197607 * SSL connection using AES256-SHA
10:12:09.197919 * Server certificate:
10:12:09.198192 *        subject: C=US; ST=California; L=San Francisco; O=Salesforce.com, Inc; OU=Applications; CN=test.salesforce.com
10:12:09.198481 *        start date: 2015-06-05 00:00:00 GMT
10:12:09.198741 *        expire date: 2018-06-04 23:59:59 GMT
10:12:09.199137 *        subjectAltName: test.salesforce.com matched
10:12:09.199435 *        issuer: C=US; O=Symantec Corporation; OU=Symantec Trust Network; CN=Symantec Class 3 Secure Server CA - G4
10:12:09.199793 *        SSL certificate verify ok.
10:12:09.200266 > POST /services/oauth2/token HTTP/1.1
10:12:09.200266 > User-Agent: curl/7.29.0
10:12:09.200266 > Host: test.salesforce.com
10:12:09.200266 > Accept: */*
10:12:09.200266 > Content-Length: 712
10:12:09.200266 > Expect: 100-continue
10:12:09.200266 > content-type: multipart/form-data; boundary=----------------------------5f6c77e4d919
10:12:09.200266 >
10:12:09.218608 < HTTP/1.1 100 Continue
10:12:09.592160 < HTTP/1.1 200 OK
10:12:09.592452 < Date: Wed, 03 May 2017 15:12:19 GMT
10:12:09.592745 < Strict-Transport-Security: max-age=31536000; includeSubDomains
10:12:09.593017 < X-Content-Type-Options: nosniff
10:12:09.593286 < X-XSS-Protection: 1; mode=block
10:12:09.593539 < Content-Security-Policy: reflected-xss block;report-uri /_/ContentDomainCSPNoAuth?type=xss
10:12:09.593784 < Content-Security-Policy: referrer origin-when-cross-origin
10:12:09.594033 < Set-Cookie: BrowserId=<snip>;Path=/;Domain=.salesforce.com;Expires=Sun, 02-Jul-2017 15:12:19 GMT
10:12:09.594283 < Expires: Thu, 01 Jan 1970 00:00:00 GMT
10:12:09.594630 < Pragma: no-cache
10:12:09.594894 < Cache-Control: no-cache, no-store
10:12:09.595144 < X-ReadOnlyMode: false
10:12:09.595406 < Content-Type: application/json;charset=UTF-8
10:12:09.595671 < Vary: Accept-Encoding
10:12:09.595920 < Transfer-Encoding: chunked
10:12:09.596204 <
10:12:09.596619 * Connection #0 to host test.salesforce.com left intact
 
Returning:
{"access_token":"<snip>","instance_url":"https://cs54.salesforce.com","id":"<snip>","token_type":"Bearer","issued_at":"<snip>","signature":"<snip>"}

From here, we attempt a simple select Id limit 1, but it takes almost 30 seconds:
curl -v --trace-time -X GET \
'https://cs54.salesforce.com/services/data/v39.0/query?q=SELECT%20Id%20FROM%20Account%20LIMIT%201' \
  -H 'authorization: Bearer <snip>
 
Verbose (don't worry about the time this was run - 3p vs 10a, we are concerned about the time from intialization to return):
curl -v --trace-time -X GET \
>  'https://cs54.salesforce.com/services/data/v39.0/query?q=SELECT%20Id%20FROM%Account%20LIMIT%201' \
>   -H 'authorization: Bearer <snip>
15:03:54.066383 * About to connect() to cs54.salesforce.com port 443 (#0)
15:03:54.066855 *   Trying 136.147.103.22...
15:03:54.104193 * Connected to cs54.salesforce.com (136.147.103.22) port 443 (#0)
15:03:54.105318 * successfully set certificate verify locations:
15:03:54.105583 *   CAfile: none
  CApath: /etc/ssl/certs
15:03:54.106125 * SSLv3, TLS handshake, Client hello (1):
15:03:54.142363 * SSLv3, TLS handshake, Server hello (2):
15:03:54.142774 * SSLv3, TLS handshake, CERT (11):
15:03:54.144940 * SSLv3, TLS handshake, Server finished (14):
15:03:54.145588 * SSLv3, TLS handshake, Client key exchange (16):
15:03:54.145858 * SSLv3, TLS change cipher, Client hello (1):
15:03:54.146462 * SSLv3, TLS handshake, Finished (20):
15:03:54.185332 * SSLv3, TLS change cipher, Client hello (1):
15:03:54.185789 * SSLv3, TLS handshake, Finished (20):
15:03:54.186074 * SSL connection using AES256-SHA
15:03:54.186335 * Server certificate:
15:03:54.186606 *        subject: C=US; ST=California; L=San Francisco; O=Salesforce.com, Inc; OU=Applications; CN=*.salesforce.com
15:03:54.186889 *        start date: 2015-02-14 00:00:00 GMT
15:03:54.187141 *        expire date: 2018-02-14 23:59:59 GMT
15:03:54.187421 *        subjectAltName: cs54.salesforce.com matched
15:03:54.187692 *        issuer: C=US; O=Symantec Corporation; OU=Symantec Trust Network; CN=Symantec Class 3 Secure Server CA - G4
15:03:54.188013 *        SSL certificate verify ok.
15:03:54.188432 > GET /services/data/v39.0/query?q=SELECT%20Id%20FROM%Account%20LIMIT%201 HTTP/1.1
15:03:54.188432 > User-Agent: curl/7.29.0
15:03:54.188432 > Host: cs54.salesforce.com
15:03:54.188432 > Accept: */*
15:03:54.188432 > authorization: Bearer <snip>
15:03:54.188432 >
15:04:11.267080 < HTTP/1.1 200 OK
15:04:11.267389 < Date: Wed, 03 May 2017 20:04:04 GMT
15:04:11.267633 < X-Content-Type-Options: nosniff
15:04:11.267900 < X-XSS-Protection: 1; mode=block
15:04:11.268178 < Content-Security-Policy: reflected-xss block;report-uri /_/ContentDomainCSPNoAuth?type=xss
15:04:11.268423 < Content-Security-Policy: referrer origin-when-cross-origin
15:04:11.268659 < Set-Cookie: BrowserId=<snip>;Path=/;Domain=.salesforce.com;Expires=Sun, 02-Jul-2017 20:04:04 GMT
15:04:11.268894 < Expires: Thu, 01 Jan 1970 00:00:00 GMT
15:04:11.269139 < Sforce-Limit-Info: api-usage=34/5000000
15:04:11.269380 < Content-Type: application/json;charset=UTF-8
15:04:11.269616 < Vary: Accept-Encoding
15:04:11.269852 < Transfer-Encoding: chunked
15:04:11.270089 <
15:04:11.270493 * Connection #0 to host cs54.salesforce.com left intact

Returning:
{"totalSize":1,"done":true,"records":[{"attributes":{"type":"<snip>","url<snip>"},"Id":"<snip>"}]}

 
Igor Androsov 5Igor Androsov 5
What you are describing I have seen this before on REST and SOAP API calls direct to Salesforce via client app. It was daily issues face delays or some timeouts even on API calls during specific timeframe may be initial 5-10 min after that all goes fast. I try to ask support but got no reply. This was work out of Japan wth time difference and typically noticed when it was an early morning hour on WEST PST time zone this will effect API. Best I could find is some DB/Server/network maintenance. Have seen this on several pods similar behavior on sandbox but not in PROD. If it effects your operation file a case.
Grant FisherGrant Fisher
Igor,

We have continued to see this in both testing and Production. Unfortunately, we have not received a good answer to the issue. Because it is always reproducable (at least once per day), I assumed that there would be a fix.

In the meantime, we are warming the instance with scheduled calls, but that isn't a good answer for a production system, in my opinion.

Thanks,
Grant