> Are Android developers content with all calls to a web service taking > 800ms over WiFi and 4000ms on EDGE?
Actually, yes, that is expected. Particularly when using HTTP, because of the overhead which includes many syn/ack packets and may split the packets up resulting in more round trips. If you really want to minimize the latency I suggest you work with sockets and bytes directly. What's interesting is that the browser takes <20ms for a request. I haven't worked with the inner workings of HTTP for a while but it may set some headers that makes the server optimize the packets. (i.e. sends bigger packets instead of a bunch of small ones.) On Tue, Nov 23, 2010 at 1:54 PM, Wipeout <[email protected]> wrote: > Hello again, and thank you for all your replies. I will try to break > them down in an organized fashion. > > Kumar: > The while loop takes <20ms on the emulator, and less still on the > Nexus One. I have measured the time it takes for every line to > complete -- I'm sorry I did not mention that. The problem is in the > call to the web service (i.e. client.execute(request), or > androidHttpTransport.call(soapAction, envelope) from another way of > trying). I have much more code from me trying this many different > ways; this is a single snapshot of where I left the code. > > Jason: > I don't understand how the browser can be so much faster than a direct > HTTP call to the web service. I do know that timing the execution > synchronously is not going to give me perfect results, but I timed the > timer and, especially on the Nexus One, it takes a negligible amount > of time for the timer code to run. What I forgot to mention was that > we have tried hosting the web service locally on our network (<1ms > late...@100mbit) and even then the web service call takes >100ms > through the app, and <20ms through the browser. > > This code is housed in WebService.java, which is always called > asynchronously from other parts of the app. I wanted the entire > instantiation to be asynchronous, in case in the future we decide to > return or parse a more-than-trivial amount of data. I have ran this > test with GZIP compression enabled and disabled. > > Unfortunately, it is not feasible to implement a local cache. That was > my very first thought, but the data is important enough that I do not > want the possibility of tech savvy users extracting the data > themselves without using the web service the way it was intended. > > One thing I noticed, using Microsoft's Visual Round Trip Analyzer > (very cool little tool, if you guys haven't used it already), is that > a certain call to my .NET web service (which in this case returns a > soap envelope with a .NET datatable inside, which I parse manually, > blegh) results in a bunch of ACKs going back and forth. Over WiFi this > isn't terrible, but over a higher latency connection like EDGE this > takes 4+ seconds to complete. It looks like TCP Slow Start may have > something to do with it, but admittedly I don't have enough knowledge > of the inner workings of TCP to fix this issue. Here is what VRTA > returns: > > > KB Up=1.499 Down=8.765; > Compressibility: 0.00; Packet Loss: 0.00% > HTTPS NotSupported Headers (Size=0 Cookie=0): > Response Status Code: null Headers (Size=0 Cookie=0): > Time [ms]: TCP=86 TTFB=0 Total=2149 > > Frame ms A Size Proto Flags Communication > 7 98 0 66 TCP .S Sync to establish Conn > 8 184 86 66 TCP .S. .A <--- Sync-Ack confirm Conn > 9 184 0 54 TCP ....A ---> Ack > 10 405 220 142 TCP ...PA ---> Ack > 11 499 95 1514 TCP ....A <--- Ack > 12 502 3 1514 TCP ....A <--- Ack > 13 502 0 54 TCP ....A ---> Ack > 14 591 89 1159 TCP ...PA <--- Ack > 15 795 203 54 TCP ....A ---> Ack > 16 828 33 364 TCP ...PA ---> Ack > 17 931 104 97 TCP ...PA <--- Ack > 19 1137 205 54 TCP ....A ---> Ack > 20 1903 767 286 TCP ...PA ---> Ack > 21 2115 212 60 TCP ....A <--- Ack > 22 2115 0 407 TCP ...PA ---> Ack > 23 2247 132 1514 TCP ....A <--- Ack > 24 2247 0 1514 TCP ....A <--- Ack > 25 2247 0 1477 TCP ...PA <--- Ack > 26 2247 0 60 TCP F.. .A <--- Close connection > 27 2247 0 54 TCP ....A ---> Ack > > Are Android developers content with all calls to a web service taking > 800ms over WiFi and 4000ms on EDGE? > > Again, thank you for all your replies. > > Regards, > Adam Smith > Norsoft > > On Nov 23, 9:33 am, Hal <[email protected]> wrote: >> You may want to try Jt secure Web Services for Android: >> >> -Java Pattern Oriented Framework, An application of the Messaging >> Design Pattern >> IBM Technical >> Libraryhttp://www.ibm.com/developerworks/webservices/library/ws-designpatter... >> >> - Messaging Design Pattern and a distributed Component/Service >> Modelhttps://jt.dev.java.net/files/documents/5553/149793/MDPdistributedMod... >> >> The following code is taken from the Jt.JtURL component (invoked by >> the Jt.rest.JtRestService component) >> >> private String doPost (String request) { >> URLConnection urlConn; >> URL destURL; >> DataOutputStream outStream; >> DataInputStream inStream; >> int c; >> StringBuffer sBuffer = new StringBuffer (); >> >> if (request == null) >> return null; >> >> if (url == null) >> return null; >> >> handleTrace ("request:" + request); >> >> try { >> >> destURL = new URL (url); >> >> urlConn = destURL.openConnection(); >> urlConn.setDoOutput(true); >> urlConn.setDoInput(true); >> >> urlConn.setRequestProperty("Content-length", >> "" + request.length()); >> >> outStream = new DataOutputStream (urlConn.getOutputStream()); >> >> outStream.writeBytes(request); >> >> outStream.close (); >> >> inStream = new DataInputStream (urlConn.getInputStream()); >> >> while ((c = inStream.read()) >= 0) { >> sBuffer.append((char) c); >> } >> } catch (Exception ex) { >> handleException (ex); >> } >> >> return ((String) sBuffer.toString()); >> >> } >> >> If feasible you may want to try without GZIP. It should be a bit >> faster. >> >> On Nov 18, 6:00 pm, Wipeout <[email protected]> wrote: >> >> >> >> >> >> >> >> > Hey guys, >> > This is my first post to the Android Developers group. I have been >> > working with HTTP communication in the Android SDK and have noticed >> > that calls to a web service through my app are very slow (taking >> > 800+ms on high speed wifi). They take less than 100ms if I call the >> > web service through the phone's browser. I am developing on a Google >> > Nexus One. The size of the data returned is very small, <1K. I have >> > tried enabling gzip compression, and that helps slightly but I assume >> > there is another problem at hand. I have tried using SOAP with the >> > ksoap2-android library, as well as making things simple using >> > HttpClient and InputStreamReader. Below is my code for the fastest I >> > can make the app perform; using no SOAP, and using GZIP compression. I >> > apologize for the lengthy code -- I think all of it is beneficial for >> > determining the best way to make this request and response happen >> > faster. >> >> > [code] >> > public String GetRest() >> > { >> >> > long startTime = System.currentTimeMillis(); >> > String result = ""; >> >> > Log.v("time", "Beginning rest: " + (System.currentTimeMillis() - >> > startTime) + "ms"); >> >> > try >> > { >> > HttpClient client = new DefaultHttpClient(); >> > HttpGet request = new HttpGet("https://usad.enlyght.com/ws/ >> > AndroidService.asmx/GetWebServiceVersion"); >> > request.addHeader("Accept-Encoding", "gzip"); >> >> > Log.v("time", "Before call: " + >> > (System.currentTimeMillis() - >> > startTime) + "ms"); >> > HttpResponse response = client.execute(request); >> > InputStream instream = response.getEntity().getContent(); >> > Header contentEncoding = response.getFirstHeader("Content- >> > Encoding"); >> > if (contentEncoding != null && >> > contentEncoding.getValue().equalsIgnoreCase("gzip")) { >> > instream = new GZIPInputStream(instream); >> > } >> > InputStreamReader isreader = new >> > InputStreamReader(instream); >> > BufferedReader reader = new BufferedReader(isreader); >> > StringWriter sw = new StringWriter(); >> >> > String read; >> > while ((read = reader.readLine()) != null) { >> > result += read; >> > } >> >> > client.getConnectionManager().shutdown(); >> > } >> > catch (Exception e) {} >> > Log.v("time", "End rest: " + (System.currentTimeMillis() - >> > startTime) + "ms"); >> >> > return result; >> > } >> > [/code] >> >> > Regards, >> > Adam Smith >> > Norsoft > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en -- ~ Jeremiah:9:23-24 Android 2D MMORPG: http://developingthedream.blogspot.com/, http://www.youtube.com/user/revoltingx -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
