iOS: CouchBase slow to wake from background

[Dave]

I'm liking Couchbase Mobile for data storage in my iOS app -- not only
for the offline sync but also because it feels simpler than CoreData.

But the time it takes for the local Couchbase instance to come online
after resuming the app from the background is a real issue -- in my
fairly simple app it's taking a good 5-10 seconds. I know the ability
to background in the first place is a relatively recent addition, so I
don't mean to complain; but I worry that without a fix for this I'll
have to go back to Core Data for performance reasons. Is there
anything in the works?

Thanks!

Dave

[Jens Alfke]

On Nov 6, 2011, at 12:08 AM, Dave wrote:

But the time it takes for the local Couchbase instance to come online
after resuming the app from the background is a real issue -- in my
fairly simple app it's taking a good 5-10 seconds.

This should be better in recent nightly builds as compared to the beta — there was an earlier unintentional regression in server startup time, that we rolled back a week or so ago. It should cut launch time roughly in half.

—Jens

[Dave Feldman]

That's good to know, but unfortunately I was already on the latest nightly (from 11/2). Do you think it will continue to improve? Or is there a way to add an API to manually pause is when the app backgrounds and resume when it returns?

Is there a way to query CouchBase quickly during the time it takes to start back up? That is, can my app either get notified via a callback when CouchBase is up and running again, or can it poll to see if it's back? At least that way I can create a cache and pull from it (or create some sort of progress spinner) so it doesn't just hang.

Thanks again,

--Dave

[Jens Alfke]

On Nov 7, 2011, at 10:47 AM, Dave Feldman wrote:

That's good to know, but unfortunately I was already on the latest nightly (from 11/2). Do you think it will continue to improve?

I think so. Restarting the server is a bit of a hack — the underlying problem is that the OS will close the server’s listener socket when the app goes into the background (or soon thereafter), and Erlang’s web-server library doesn’t have a way to recover from that, so we just kill and restart it. 

In the longer term we should find a way to just re-open that socket and keep the server code running. Patches are welcome ;-)

Is there a way to query CouchBase quickly during the time it takes to start back up? That is, can my app either get notified via a callback when CouchBase is up and running again, or can it poll to see if it's back?

Sure — the CouchbaseMobile object calls its delegate’s -couchbase:didStart: method again when the server restarts. So in between the UIKit notification that you’re being suspended, and the restart callback, you shouldn’t access the server.

At least that way I can create a cache and pull from it (or create some sort of progress spinner) so it doesn't just hang.

You can also avoid hanging by making your calls asynchronous. (And I know, CouchCocoa includes some synchronous calls internally for convenience, but it’s always possible to do them yourself asynchronously if you need to.)

—Jens

[Dave Feldman]

> I think so. Restarting the server is a bit of a hack — the underlying problem is that the OS will close the server’s listener socket when the app goes into the background (or soon thereafter), and Erlang’s web-server library doesn’t have a way to recover from that, so we just kill and restart it.
>
> In the longer term we should find a way to just re-open that socket and keep the server code running. Patches are welcome ;-)

So is it reasonable to expect that as Couchbase Mobile matures (say, within 6 months) there'll be a solution to this that provides near-instant availability after coming out of the background? Or is this always going to be an inherent issue to one degree or another?

Thanks.

--Dave

[J Chris Anderson]

Resetting just the web module in Erlang shouldn't be tough. I'm really looking forward to all the tightening up we'll be able to do now that we've got basic stability (and more importantly a repeatable test process).

Chris

[Gavin]

We've used CouchDB for persistence in our app, which we're hoping to beta very soon. Unfortunately, we're experiencing the same pain Dave mentioned, which is turning out to be a bit of a show-stopper.

While we're looking at caching etc. as a workaround, would be great to see the core issue resolved. I'd gladly dive in to see what I could do to improve the situation were it not that my Erlang skills are non-existent. 

Chris, you mentioned that resetting the web module "shouldn't be tough" to fix? I'd gladly buy you a beer (or two) if you could encourage someone with the necessary skills to have a look the problem. ;)

Thanks,

Gavin

[Jens Alfke]

On Nov 17, 2011, at 12:49 AM, Gavin wrote:

Chris, you mentioned that resetting the web module "shouldn't be tough" to fix? I'd gladly buy you a beer (or two) if you could encourage someone with the necessary skills to have a look the problem. ;)

Chris encouraged me by telling me what Erlang function to call (couch_httpd:stop). I got it working today, and it’s pretty much instantaneous. I also put in a check that only restarts on wake if the listener socket isn’t responding anymore. In the bit of testing I’ve done, the restart isn’t even necessary if the app hasn’t been evicted from RAM and the device hasn’t been put to sleep; so if you leave the app and go into another app for a few minutes and then come back, everything is still running when you return and nothing needs to be done.

This isn’t checked in yet, but I know this has been a sore point for some people, and extra testing is always valuable; so if you’re really eager to try it, here are the code-review pages that you can download patches from:

http://review.couchbase.org/#change,11016 <— in the iErl repo

http://review.couchbase.org/#change,11017 <— in the iOS-Couchbase repo

If anyone tries this out, please let me know whether or not it works well.

(The less eager can wait a day or two for this to be checked in and appear in an automated build.)

—Jens

[Sarah Gray]

Wow, Jens, that's awesome that you did that! Thanks! (I'm going to wait till it's integrated, but it's fabulous to know it's there).

--

http://www.twitter.com/fablednet

http://www.fabled.net/blog/

[Alexander Gabriel]

what a fabulous support!

Alex

2011/11/19 Sarah Gray <sarah...@gmail.com>

[Gavin]

I've (re)built the iOSCouchbase framework using the patched implementation files and it seems to work well. CouchDB is indeed immediately available again once the app re-enters the foreground. No more waiting 4-5 seconds before the user can read/write from the DB. All other CouchDB operations also seem to work fine (although I haven't tested replication yet).

Jens/Chris, regarding the beer I think you/Chris will have to add it to my tab until we're able to catch up at CouchConf (Europe) at some point in the future. I won't forget. :)

Thanks for the speedy solution!

Cheers,
Gavin

[Jens Alfke]

On Nov 20, 2011, at 1:55 PM, Gavin wrote:

I've (re)built the iOSCouchbase framework using the patched implementation files and it seems to work well. CouchDB is indeed immediately available again once the app re-enters the foreground. No more waiting 4-5 seconds before the user can read/write from the DB. All other CouchDB operations also seem to work fine (although I haven't tested replication yet).

Excellent! Thanks for your help. I’m just waiting on one more code review, so the patches should be committed & built tomorrow.

—Jens

[Jens Alfke]

On Nov 18, 2011, at 12:06 PM, Jens Alfke wrote:

Chris encouraged me by telling me what Erlang function to call (couch_httpd:stop). I got it working today, and it’s pretty much instantaneous. I also put in a check that only restarts on wake if the listener socket isn’t responding anymore. In the bit of testing I’ve done, the restart isn’t even necessary if the app hasn’t been evicted from RAM and the device hasn’t been put to sleep; so if you leave the app and go into another app for a few minutes and then come back, everything is still running when you return and nothing needs to be done.

This fix is now available in the latest ‘nightly’ build:

http://files.couchbase.com/developer-previews/mobile/ios/nightlybuild/ios-couchbase-87.zip

—Jens

[Amos Hayes]

Should the fixes below be working in the 2.0.2 build for iOS? We're having some problems on iOS 5.1 with couchbase not responding after sleep and not calling back to the main app with a new socket.

--
Amos