Loading db (store) to memory sometimes takes too much time

[EmiM]

Orbitdb entries need to be loaded to memory in order for us to make queries. Even though our databases are small (up to 500 entries) loading them can take up to a minute. I posted a question in gitter: https://gitter.im/orbitdb/Lobby?at=608180542e5574669b51a8c2 They have plans for making it more efficient: https://github.com/orbitdb/orbit-db/issues/819

I think the next step is to find out what exactly in db.load() is so slow and maybe find out if we can do anything about it.

[holmesworcester]

Let's say we're going to spend a full day on this and then discuss before we do more.

[holmesworcester]

Also, to add a bit more clarity, I think these are the things we're seeing here that we don't understand.

1. Users that are new to the network seem to sync the entire db really quickly. That is rarely a problem.
2. Returning users sometimes sync the db quickly, but sometimes it takes a minute to load just a few hundred entries.
3. If new messages are being added to the db, this syncing seems to happen quicker.

One theory we have is that the kinds of connections we need to make to sync old entries are simply failing at the network layer.

(@EmiM, @kowalski please correct me if any of this is wrong, as this is from memory from our calls.)

[aphelionz]

Which kind of db is this?

[holmesworcester]

I believe it’s an EventStore.

See: https://github.com/ZbayApp/waggle/blob/546ab4cac07da9a28590053b2bb206207346a103/src/storage/storage.ts#L147

On May 9, 2021, at 2:56 PM, Mark Robert Henderson @.***> wrote:

Which kind of db is this?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ZbayApp/zbay/issues/776#issuecomment-835863614, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABUFLQXADFIUYK4DNTRCJ3TM3LF5ANCNFSM43OLTDGA.

[aphelionz]

EventStore definitely shouldn't take that long to load. To be clear, this is NOT replicating from the network but simply loading from IPFS into memory? Is it an in-process IPFS node or is it using an HTTP API?

[kowalski]

@aphelionz yes, thats right, it looks like it takes a lot time to read data that is stored locally. We're using js-ipfs, so inprocess node.

[aphelionz]

@kowalski thanks - if I check out this code and run it locally, can I easily replicate this state?

[EmiM]

While I was preparing docker image with very basic setup I noticed that the long load() time is probably our fault. Normally we run it (waggle) inside electron main process and then loading takes at least 13 seconds for largest eventstore (about 1000 records). By running it outside electron (as it is e.g in prepared image) time is shortened to 1.5 second.

[aphelionz]

Very interesting. What is the reason for electron slowing it down? Something due to leveldb, maybe?

[EmiM]

I don't know the exact reason. Orbitdb performs many operations, perhaps electron slows it down because of single threading and electron cutting between orbitdb operations?

For test I spawned a process with waggle (from electron main process) and messages also loaded very fast. https://www.electronjs.org/docs/tutorial/performance#how-2 I think that if we'd use worker threads or something like that, the problem will be solved.

[EmiM]

Note for myself: https://news.ycombinator.com/item?id=27156872

[aphelionz]

Here's an attempt at an isomorphic OrbitDB worker that uses web workers int he browser and worker threads in node.js: https://github.com/tallylab/orbitdb-worker

It might need to be updated but hopefully it provides a good start.

[holmesworcester]

@vinkabuki assigning this to you since you're working on this now, right?

[holmesworcester]

We've fixed this, right? @vinkabuki

[holmesworcester]

@EmiM @vinkabuki is this still happening?