Zoom Logo

Scalability & Performance Technical Working Group - Shared screen with speaker view
Jordan Last
11:00
This is so exciting
Byron Becker
16:44
This is very big - so with no need for a context switch, what are we expecting in terms of performance?
Byron Becker
17:18
Especially if we go from 8GB to 32GB to 300GB
Byron Becker
21:06
Let's say I have a BTree data structure, does the read/write performance stay at log(n) as I scale out to the whole subnet?
Jordan Last
21:40
I assume it would be n * logn, n being the increase?
Jordan Last
21:49
And the optimizations would reduce n?
Byron Becker
22:03
yes
Jordan Last
22:12
Oh c * logn?
Jordan Last
22:17
c = overhead
Byron Becker
22:23
c + logn
Byron Becker
24:14
So you're thinking about like a stable schema? Or one that allows for migrations
Byron Becker
27:09
What does this mean for Motoko, since so much of the current development patterns there are based around heap memory?
Paul Young
28:35
I think a straw man example for a key-value store would be a good starting point to help people understand how it might work
Byron Becker
28:54
This would make heap memory only a specialized use case if stable memory is really able to perform at this level
Byron Becker
30:01
Is there any difference in the hardware used in heap memory vs. stable memory?
Hamish Peebles
30:22
annoyingly I need to drop off for another meeting 🙁
Byron Becker
34:55
What’s an optimistic and conservative timeline on 32GB stable memory, multiple memories backing stable memory, etc.
Byron Becker
37:36
yes
Byron Becker
46:03
So you have an auth service that generates auth tokens with a ttl that the frontend can use to communicate with your other canisters? How do the other canisters verify the authZ token is valid?
Dominic Wörner
47:57
It’s based on a HMACed token. So secure against tampering by clients, but boundary nodes/replicas could learn the secret
Jordan Last
52:56
Meidhy what are you working on?
Dominic Wörner
53:24
creating a pool and assigning new ones from the pool?
Byron Becker
53:36
Yea, I think this is the canister pool idea
Byron Becker
55:31
The stable storage abstraction still has the issue that you share your “canister” with every other project in that subnet, so 32GB and 300GB is all relative to the subnet you're using, right?
Jordan Last
58:20
Inter-canister/subnet calls are expensive and slow, I wonder if that needs to be greatly improved for the IC to reach its potential. Seems like a fundamental breakthrough in consensus might be necessary here
Byron Becker
01:03:08
There's definitely a tug-of-war when designing your application to build a monolith, or a shallow architecture with multiple canister microservices and all calls being shallow from the frontend client (no inter-canister calls). I'm assuming this bump up in stable storage will shift much of the main application back to a single canister
Byron Becker
01:04:12
Quick inter-canister calls will push back to microservices, would also help with the authZ token issue by providing a different pattern
Johan Georg Granström
01:06:35
I think inter canister calls _intra subnetwork_ can be substantially optimised, but not _inter subnetwork_. So, with optimised _intra subnetwork_ canister calls and larger stable memory, the subnetwork is the clear scalability boundary - beyond which a shallow architecture is most appealing.
Byron Becker
01:08:10
How will subnet splitting affect the stable memory changes
Byron Becker
01:08:13
Or work with that
Jesse - Portal
01:08:26
Yes, when subnet splitting?
Byron Becker
01:12:31
I see, so subnet splitting would affect a multi-canister architecture
Byron Becker
01:12:35
But not a single canister
Jesse - Portal
01:13:10
Are there any known solutions for scaling across subnets when they fill up?
Byron Becker
01:14:36
Thanks for the updates, very exciting
Jordan Last
01:14:54
ICQC!
rem.codes
01:15:14
🔥
Meidhy
01:17:28
Thanks guys !