Network.Request really slow on Nook Tablet and Kindle Fire

AppdojoStudios · February 20, 2013, 5:22am

I’ve done some more testing–on 4 different devices, loading the URL in the web browser is fast.
With the Nook Tablet an Kindle Fire, the time to submit the request is very large (8-16s from the network.request() call to the point where the request is logged on the server).

Here are the results:
network.request()
Nook Tablet: 10-16s before the request is sent
Nook HD: <1s to send the request
Kindle Fire: 8-12s before the request is sent
Kindle Fire HD: <1s to send the request

Loading the URL via a browser consistently gets <1s for the request & response on all 4 devices

Does anyone have any idea what might be causing the slowdown on the order devices? My current test app is little more than the AsyncHTTP demo app except that I am calling a different URL.

Is it possible that there is some different ssl cipher negotiation in network.request() compared to what the web browsers use? Could this be impacting performance on the older devices?
[import]uid: 14461 topic_id: 36061 reply_id: 143425[/import]

AppdojoStudios · February 20, 2013, 5:54am

Here’s server Log data for a network.request() and a web browser request from the Nook Tablet to the same URL:

network.request():15.043s
[19/Feb/2013:21:44:34 -0800] “GET /version HTTP/1.1” 200 628 “-” “My User Agent” TLSv1 RC4-SHA 15.043

nook browser get: 0.147s
[19/Feb/2013:21:44:50 -0800] “GET /version HTTP/1.1” 200 628 “-” “Mozilla/5.0 (Linux; U; Android 2.3.4; en-us; NOOK BNTV250 Build/GINGERBREAD 1.4.3) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Safari/533.1” TLSv1 RC4-SHA 0.147

Does anyone have any idea why the network.request() would be taking so much longer? Does anyone have a suggestion of additional data that I could log to get to the bottom of this?
It looks like both requests are using the same SSL protocol & cipher, and both are GET requests to the same URL.
[import]uid: 14461 topic_id: 36061 reply_id: 143429[/import]

Anderoth · February 20, 2013, 8:44pm

On my lunch break I loaded up my app on the Nook Color and Kindle Fire (original) to verify how fast mine is working. The app uses https network.requests to communicate with the Parse servers. All requests happen immediately. No delays or lag.

I am currently using build 1025. What build are you using? Though I have used many different builds and never experienced this behavior.

In the process of getting all the data above, did you try any simple clean slate projects with like 10 lines of code to test the devices? Weird things happen and something in your config, build or app could be causing issues. Doing a simple clean project can sometimes help determine if it’s in your project or build bug. [import]uid: 56820 topic_id: 36061 reply_id: 143489[/import]

AppdojoStudios · February 21, 2013, 12:36am

I’m using Corona SDK 2012.971
I trimmed it down to essentially the HTTP network.request sample app connecting to my URL, and I am still seeing the issue on just the Kindle Fire and Nook Tablet. [import]uid: 14461 topic_id: 36061 reply_id: 143520[/import]

Anderoth · February 21, 2013, 8:18am

I’ve been hammering some bugs in my app tonight but I got a chance to experiment.

I loaded up .971 and made an amazon and nook build. Still not seeing any lag on network.requests. If your confident it’s not your code, I am confident it isn’t Corona. My next suspicion is the kindle/nook, being cheaper tablets, maybe do not work well with your wireless router. If you can test on a different wireless connection, perhaps that is a problem. [import]uid: 56820 topic_id: 36061 reply_id: 143554[/import]

AppdojoStudios · February 21, 2013, 3:52pm

The fact that loading the page in the web browser is fast, yet loading the same html content with a GET request using network.request being slow on the same device points to some difference with Corona (as compared to the browser) that is causing the slowdown.
The fact that the browser is fast to load the same page rules out a general issue with the hardware or with the wifi connection.

Early in my investigation, I also thought it might be wifi related, and I tried connecting via three different wifi routers (seeing the same results) prior to realizing that access via the native web browsers on both the Nook Tablet and Kindle Fire does not have the same performance issue as Corona’s network.request call.
[import]uid: 14461 topic_id: 36061 reply_id: 143601[/import]

Anderoth · February 21, 2013, 5:13pm

Good point. I totally overlooked your tests on the browser. Sorry about that.

If it is indeed a bug with Corona it is not a simple bug. I don’t see it happening and I have not read of any other complaints. Have you attempted to load a simple URL like google.com to see if it’s fast and has no errors? I don’t see anywhere you mentioning what URL you are testing.

If you can, can you share the code you use for the network.request that is slow? Including the headers etc. Something about the call itself may not jive with Corona. [import]uid: 56820 topic_id: 36061 reply_id: 143617[/import]

AppdojoStudios · February 21, 2013, 7:11pm

O.K. I finally got to the bottom of this.

It turned out to be a reverse DNS issue at the server hosting provider that resulted in a reverse DNS query timeout. This only showed up on HTTPS connections from the Kindle Fire and Nook Tablet, because there is an Android 2.3.x bug, that causes the client to unnecessarily perform a reverse-DNS query on https negotiation:
http://code.google.com/p/android/issues/detail?id=13117

There is a workaround in the details (follow the link above) to keep clients from performing the unnecessary rDNS query. My guess is that the native web browsers on Android 2.3.x implemented the workaround (which is why the connection from the web browser on the Nook Tablet and Kindle Fire is fast), but that the network.request() implementation in Corona does not implement the workaround to avoid the unnecessary reverse-DNS query.

The network.request() implementation should really be updated to implement the workaround to avoid an unnecessary rDNS query if the target OS is an Android platform affected by this bug.

Note: The server rDNS issue was verified using:
dig -x serverIP +trace
[import]uid: 14461 topic_id: 36061 reply_id: 143626[/import]

jflowers45 · February 21, 2013, 8:46pm

wow. nice find and very good to know [import]uid: 32462 topic_id: 36061 reply_id: 143637[/import]

AppdojoStudios · February 18, 2013, 11:38pm

Here’s a bit more info (I forgot to add this):
The network request is slow on the Nook Tablet and the Kindle fire meaning it takes over 10 seconds to complete.
The network request is fast on the Nook HD and the simulator with the request taking ~ 3 seconds. They are all connected to the same network and the network.request connection is over https. Any help would be appreciated! [import]uid: 14461 topic_id: 36061 reply_id: 143250[/import]

jflowers45 · February 19, 2013, 2:45am

are you by any chance using a landscape only app? on the NOOK there was an issue (that has been fixed) where opening the ‘write a review’ window took forever in landscape only apps. could (theoretically) be related - long shot though [import]uid: 32462 topic_id: 36061 reply_id: 143263[/import]

Anderoth · February 19, 2013, 5:43pm

Just throwing in my experience.

I have been testing a Kindle Fire (original) and Nook Color with Network.request in conjunction with Parse.com. It uses https also. I have had no issues with delayed requests.

It’s either an odd wireless issue or perhaps the code? What specifically is your network.request’s doing? [import]uid: 56820 topic_id: 36061 reply_id: 143344[/import]

AppdojoStudios · February 19, 2013, 7:09pm

It just calls a link which returns a table and then I save the table. Here’s my network callback (Btw I am using post in the request):

local function networkCallback(event)  
 if ( event.isError ) or event.response == "The request timed out." or event.status == 404 or event.status == 502 then  
 clearGroup(loadingScreenGroup)  
 print( "Network Error!")  
 displayServerError(group)  
 else  
 clearGroup(loadingScreenGroup)  
 local data = json.decode(event.response)  
 if table == "allTime" then  
 allTime = data  
 elseif table == "week" then  
 week = data  
 elseif table == "day" then  
 day = data  
 end  
  
 table = data  
 end  
end

There are some variables that aren’t created here but are mentioned like allTime, week, and day. Those are all variables that are just created above and table is a paramater of a different function that this callback is inside. Is this similar to your code? [import]uid: 14461 topic_id: 36061 reply_id: 143352[/import]

Anderoth · February 19, 2013, 9:42pm

How big is the json response? I have found that json.decoding can be a huge CPU hog. The Kindle and Nook I think are underpowered devices when it comes to computing power. This could be a possibility. [import]uid: 56820 topic_id: 36061 reply_id: 143374[/import]

AppdojoStudios · February 20, 2013, 12:10am

I actually looked at the logs and the delay is actually before the request goes out. Maybe it is doing some extra stuff that I can turn off? And the tables that it returns are really small. [import]uid: 14461 topic_id: 36061 reply_id: 143394[/import]

AppdojoStudios · February 20, 2013, 2:44am

O.k. so I simplified the test to load static html content.

All requests occur immediately in the simulator.

On the Kindle Fire, this is a different story:
If I load the link via the web browser, the request is sent out right away, and the html response is displayed
If I use network.request to GET the same URL, I can sometimes see 5-10 seconds delay before the request is sent to the server. Once the request goes out, the html response is received very quickly. [import]uid: 14461 topic_id: 36061 reply_id: 143420[/import]

AppdojoStudios · February 20, 2013, 5:22am