Salesforce Developer Community

Evgeny Kabantsev
NEWBIE
10 Points
Member since 2018

Chatter

Feed
0

Best Answers
0

Likes Received
0

Likes Given
1

Questions
2

Replies

SOAP responses are unacceptable slow on a certain endpoint. Could somebody help?

Hello there,

For our production and testing purposes we are using several Salesforce environments connecting them via related SOAP endpoints.

In somewhere about 4 months ago our production service become affected by significantly decreased performance of Salesforce SOAP endpoint: all queries through SOAP endpoint are responded in average 10 seconds each.
At the same time the same requests to the other Salesforce environments (via different SOAP endpoints) are responded in less then a second (~0.5s average). It is the same performance, which was observed in communication between our production service and Salesforce via SOAP before degradation described above.
Also it is quite interesting, that Salesforce portal looks working just fine: there are no visible lags in operations if they are performed directly on Salesforce site.

Since then we have tried multiple times to solve this problem with Salesforce support tea, but there is still no positive dynamic: from their position we are using SOAP on base supscription and so then they cannot support us in case of degradation of performance of the Salesforce service behind SOAP.

Here are examples of simple queries we are performing via SOAP to Salesforce database and average(for 10 requests) timing for two different endpoints:

# SF Query:

> SELECT Id, SolutionNumber, SolutionName, SolutionNote, Technical_Document__c FROM Solution IsPublished = true AND IsReviewed = true

# Average response time for https://www.salesforce.com/services/Soap/u/20.0

=> 10.72s

# Average response time for https://cs43.salesforce.com/services/Soap/u/20.0

=> 0.57s

# SF Query:

> SELECT Id, MasterLabel, ParentId, SortOrder, SortStyle FROM CategoryNode ORDER BY SortOrder

# Average response time for https://www.salesforce.com/services/Soap/u/20.0

=> 10.41s

# Average response time for https://cs43.salesforce.com/services/Soap/u/20.0

=> 0.49s

# SF Query:

> SELECT Id, SolutionNumber, SolutionName, SolutionNote, Technical_Document__c,
(SELECT Id, Name, Description, CreatedDate, CreatedBy.FirstName, CreatedBy.LastName FROM Attachments ORDER BY CreatedDate)
FROM Solution WHERE Id = '50150000000T6sfAAC'

# Average response time for https://www.salesforce.com/services/Soap/u/20.0

=> 10.68s

# Average response time for https://cs43.salesforce.com/services/Soap/u/20.0

=> 0.52s

# SF Query:

> SELECT Body, BodyLength, ContentType FROM Document WHERE Id = '01550000001QnorAAC'

# Average response time for https://www.salesforce.com/services/Soap/u/20.0

=> 10.67s

# Average response time for https://cs43.salesforce.com/services/Soap/u/20.0

=> 0.54s

And so on... We have done a lot of measurements and we are confident that all requests via SOAP to SF are performed such slow with our production endpoint only.
Tables queried above has the same contents in production and test environments, so it is not related to queried table size.
We are querying SOAP endpoint quite rare even in production (about several times in hour with bunch of 3-5 queries for a single operation: list contracts, create ticket and so on), so it this issue is also not related to some kind of high load.

Our code related to SOAP integration was not changed for about 2 years, and our infrastructure was not updated in the DC where our service is running, so it is also not related to changes on our side.

The interesting thing is that our problems with SF are started to happening after Salesforce DC outage several months ago. Not sure, but maybe there is some kind of database index or even maybe hardware issue out there?

I hope all reading this post will agree with me that this timing is not acceptable for production database even during superhigh load.

Bad thing for us is that Salesforce support team seems not interested in solving our problem. And it is realy making our customers angry, that we could not solve it for 2 month already. Can somebody suggest how can we fix this issue?

With thanks in advance and looking forward hearing your advices,
Evgeny Kabantsev.