6.x
NA
NA
This is related to an email exchanged with Oleg Vyalyh about recent slowness in reading data from the new EU server… this is created Oleg Request for follow up on the case
Hello, @eyad-pro !
How did you test the speed? I did a series of tests and the response from Dallas was 1000ms average, and the response from Europe was 800ms, and it should have been. Because the difference between Dallas and Europe in the distance over the network is about 110ms, so the European cluster works faster in my case. Testing was performed using the data of your Application.
You can specify your IP or subnet or service provider so that I can measure network delays from the Dallas and Europe clusters.
Hi Marian,
The testing I have done is simply measuring the time in EPOC just before firing the API and then after receiving the reply exactly, working out the difference and uploading the result in a separate table … I have not changed anything in the measuring code between 4th of Jan and 6 this Jan, but the figures are giving me a jump from 0.7-0.9 Sec to 1.4-1.6 on the EU cluster … see the two sheets attached for the fetching times on 4th & 6th on the EU server, in most cases you can see double the fetching time !
As for your testing I’m not sure where are you testing from? I If you are in EU, then 800 ms as average is around the figures I saw on 3rd and 4th of Jan from my location outside the EU (I’m in middle East) but of course I can’t see these figures now. My current dynamic IP is 88.201.58.201 and the ISP is (https://www.batelco.com)
Let me know if you want do live testing
Thanks
Eyad
Hello … I did run the command:
curl -w "%{time_namelookup}\n%{time_connect}\n%{time_appconnect}\n%{time_pretransfer}\n%{time_redirect}\n%{time_starttransfer}\n%{time_total}\n" -o /dev/null -s "https://eu-api.backendless.com/8C44389D-54B2-5DF3-FFF8-40A831D81800/3C69F62A-5673-48CB-FFB0-06CAAC984600/data/beSP?pageSize=20"
attached are the results
The results
Hello @eyad-pro,
We updated a curl a little and now it shows the corresponding names for those values, if you run it you’ll see the description for those values:
curl -w "name lookup: %{time_namelookup}\nconnect: %{time_connect}\napp connect: %{time_appconnect}\npretransfer: %{time_pretransfer}\nredirect: %{time_redirect}\nstart transfer: %{time_starttransfer}\ntotal: %{time_total}\n" -o /dev/null -s "https://eu-api.backendless.com/8C44389D-54B2-5DF3-FFF8-40A831D81800/3C69F62A-5673-48CB-FFB0-06CAAC984600/data/beSP?pageSize=20"
Here are the results of my requests:
- lookup: The time, in seconds, it took from the start until the name resolving was completed.
- connect: The time, in seconds, it took from the start until the TCP connect to the remote host (or proxy) was completed.
- app connect: The time, in seconds, it took from the start until the SSL/SSH/etc connect/handshake to the remote host was completed.
- pretransfer: The time, in seconds, it took from the start until the file transfer was just about to begin. This includes all pre-transfer commands and negotiations that are specific to the particular protocol(s) involved.
- redirect: The time, in seconds, it took for all redirection steps include name lookup, connect, pretransfer and transfer before the final transaction was started. time_redirect shows the complete execution time for multiple redirections.
- start transfer: The time, in seconds, it took from the start until the first byte was just about to be transferred. This includes time_pretransfer and also the time the server needed to calculate the result.
- total: The total time, in seconds, that the full operation lasted. The time will be displayed with millisecond resolution.
As you can see it takes much longer time for you to connect, handshake and pretransfer than in our tests.
Right now I’m looking into the Swift-SDK, maybe I could make it a little bit faster but as you can see even the clear curl requests take more time at your side…
Regards,
Olha
Hi Olha,
This is why I have been arguing that handshaking specifically is the main contributor to this delay, and that this delay is avoidable for most of the APIs . …
You can refer to Apple WWDC sessions on how to enable your server to avoid the handshaking for every API
https://developer.apple.com/videos/play/wwdc2016/711/
the most relevant part is from slide 52 onward , the slides illustrate thru some clear diagrams the effect of HTTP 1.x on TLS and the redundant delay …I’m not sure of the server current configuration but clearly it affect the handshaking process with the client … I think maybe we need to look at this as whole issue as server-client issue thing and not just a client side issue …
as for my connection I’m using Fiber connection and I don’t face the much latency on test server I used to compare (its located in UK)… If you like I can share with you the figures to compare
Hello,
A new version of Swift-SDK v6.2.1 is released.
You can now configure the URLSession using these methods and property:
public var useSharedUrlSession = false
// true: URLSession is created only once for all requests
// false: URLSession is created for every request
// to setup URLSessionConfiguration manually for all you URLSession requests
public func setupURLSessionConfig(_ config: URLSessionConfiguration)
// to setup URLSession manually for all you requests
public func setupURLSession(_ session: URLSession)
E.g.
Backendless.shared.useSharedUrlSession = true
Backendless.shared.setupURLSession(mySession)
Regards,
Olha
Hi Olha,
First Thanks for your efforts … my initial testing showed significant improvement specially on a wifi connection … here are the numbers
without shared URL Session
wifi API fetch :1.481 sec
Mobile Broadband API fetch : 1.384 sec
with shared URL Session
wifi API fetch : 0.860 sec
Mobile Broadband API fetch : 1.026 sec
Note : all tests done by sending fast consecutive fetches to avoid TLS handshaking as much as possible
attached is the raw stats file for your reference, I guess the part of the iOS SDK is solved now. I will raise another ticket for the server side (the TLS handshaking issue)
Thanks again
Eyad
backendless Fetching time (with & without shared sessions).csv (10.1 KB)