When it comes to webservices response messages, how much data is too much?
I have an HTTP servlet written in Java that is open outside of our network. It makes a call to a database, then sends a JSON message back over the firewall. We’re talking 344kb just for the data, not including packet headers. I wouldn’t consider this substantial. We’re receiving the response on both iOS and Android platforms, total round trip could be anywhere from 1 second to 15 seconds. An average being maybe > 6. I’d like to get this steadily under 5 seconds and I’m learning this is quite the feat. Based on my timings, the webservice call to the database is milliseconds. We’ve wired directly behind the firewall but in front of the internet (thus ruling out the internet) and have seen a total round trip of maybe a second.
Just as a test I’ve trimmed the return JSON to return only 1 row of data (4kb) and, of course, I’m seeing substantial speed increases… steadily < 1 second when outside of our network. It really begs the question, is there a max data size when returning JSON messages to be consumed on mobile devices where the expectation is < 5 seconds? Running wireshark shows me this is being delivered as multiple packets, I imagine having a lot of do with it.
I’ve also clocked the time the client receives the message and the time it takes to render it on the screen… mere milliseconds.
I’d hate to break my client program up into multiple webservice calls for different data, considering the program is very basic and I don’t see it requiring multiple calls.
What do you think? Blame the internet and just make a nice splash/loading screen? 🙂
** EDIT: I also forgot to add that I’m going through SSL **
Blame mobile connections and their added latency.
It’s not even download speeds, expressly, rather the likelihood of maintaining a constant connection, and non-chunked packets.
Sadly, you’re not going to find a “right” answer here.
Under perfect conditions, a phone might have an RTT of a second or two, with all of your data.
Under less-ideal circumstances, your data might never finish arriving.
So you need to subscribe to a balancing-act of weight versus frequency.
And nobody can really give you the ratio but you.
Personally, my advice might be to start breaking the data down by module.
If you’ve got little modular widgets which make up your app, each requiring config data, or user-data, load each one separately, and in a loosely-coupled way.
As a quick illustration, you might have a chat-app, where your message-window, list of online friends and list of PMs all load independently of one another.
If each initializes as it’s ready, and each has its own separate “loading” indicator (progress is nice, but really a “working on it” will do).
If your app is more like a blog roll, or a set of items, where only a handful can be on screen, then logically chunk them based on average number per screen.
Set that on a timer, or in a queue where the successful loads trigger the next async load, until you get an empty response back.
If your app is more like an analysis-suite, where you’re loading thousands of rows of stats…
Well, there’s not a lot you can do, but make sure the user knows that it IS working.
You could send a “total” field with the first result, and mark your progress based on how many unique rows you’ve loaded thus far.
Or if you had stats by day, you could chunk by day or by week, and mark on a bar or calendar, how far back your currently-available set goes.
There’s no easy answer here, but hopefully a little help, and one piece of advice:
Waiting 5 seconds in a program where I can see that everything is streaming in, and will work when it’s done, is more bearable than 3 seconds where it’s just a blank screen and nobody tells me a thing, before the finished product pops up.