Hi @domwoe, the Cache canister is basically for performance. The idea is to maintain a static representation of what we call Discourse State, so that our Data canister doesn’t have to process the deluge of queries we’ll be getting as we scale up.
thanks and sorry for the late reply.
The pre-computation of static views that can be fetched with queries is a good idea. However, I wonder if it makes sense to have designated cache canisters for this. Queries are in general executed in a separate thread on the replica, so they shouldn’t limit the progress of your data canister.
Is your concern about the rate limits of Boundary Nodes?
Hi @domwoe, after going through this thread for a bit, yes, I’m wondering what @dsarlis and @free think about cache canisters too. In fact, I wouldn’t want to implement a solution without their input, thanks for putting me onto the current state of things! We will definitely be reaching out for help here on the Forum as we move into the cache canister feature in coming weeks.
I am not sure I can say something very specific without understanding more about your thinking here.
Caching some expensive computation so you can serve queries faster is definitely a good idea but whether you need to push that out to separate canisters or you can do it in your main data canister is another story. Dominic asked a good question. Are you worried about getting rate limited by boundary nodes if only the data canister can serve queries? Or in other words, how much load would you expect to handle in terms of queries?
A Starting Point is a very meaningful reference, which is a very visual expression for voters, I like it.
I hope Civol can provide a similar experience. Looking forward to see your progress❤️
Thanks, @MillionMiles, yes, Civol does have a similar experience in the form of our Debate feature, which allows panelists to challenge other panelists to debate on a specific question. Key differences are that Civol Debate is spontaneous and allows the community to vote on everything the debaters say, point by point. We’ll be rolling it out for the beta, so stay tuned!
Thank you, @dsarlis, I so appreciate your time and perspective! Yes, worried about rate limitation in the context of maximizing performance for the user.
The thing about Civol is, it does appear capable of scaling massively, as in millions of active users for the largest instances. For example, there might be an instance for a nation of say 100m, and they could be discoursing on multiple subjects (10-20?) of importance to them all, simultaneously… So possibly 10m+ users engaging the dapp during peak moments. Let’s assume 10% of those users could be querying in those moments. That would mean 1m queries hitting the Data canister simultaneously. To reliably service a flow like that I imagine multiple Cache canisters being needed, scaling up and down in number with demand.
It’s obviously going to be many months before Civol actually faces this problem (assuming people really like the experience), but possibly not that many, and it illustrates the need for a maximally scalable solution. So to me this means we need to spec out that solution and build a solid foundation v1 for it here at the outset, to the extent possible. Does that sound reasonable, and what do you think would be the best way to go about it?
Yeah, it sounds reasonable and I think it’s very good you’re already thinking through this. I agree that if you expect somewhere in the order of millions of queries concurrently, you can’t hope to serve this kind of traffic from a single canister alone (even if you do caching/precomputing of results).
Having an extra layer of Cache canisters is the right direction to be looking at. I would also suggest to go about this in steps as you alluded to. E.g. you can think about the implications of such a design and possible solutions and you don’t need to go all out initially but start with the right foundation. I would imagine that you can even start with a single Cache canister just to get things in place to ensure the architecture works and then scale out to more when you need. This can also give you early feedback on what works well or not.
Some things to consider when you go to a multi-canister architecture (not necessarily for your case only):
- How would Cache canisters retrieve the data from the data canister? Could that also be a bottleneck (if all cache canisters hit the data canister)?
- How will you manage the canisters lifecycle? What about the upgrade story? Can they be upgraded independently or will there be dependencies? (Likely you want to avoid dependencies as much as possible or in other words be able to upgrade the data canister without having to necessarily touch the cache canisters)
And probably more questions if someone starts an actual design doc and think through alternatives
hi @dsarlis, thanks for confirming we’re on the right track!
Yes, how does Cache canister pull from Data? After executing all the queries and filling the Cache, we would then only re-run the queries where the underlying data had changed. And I was thinking possibly only one Cache canister would actually update periodically from Data, and then we might be able to clone it as needed? And yes, lifecycle and update (no dependencies), good points…
I would love to have you take a look at our solution and advise if you’re available. Please dm me if that might be possible sometime in the next few weeks. Thanks again!
Sounds like it’s a good idea to talk At least to give you some pointers on what’s even possible or not. E.g. cloning the data is not something you just get for free somehow. Let me know, I’m happy to help any way I can (either reviews or simply explaining what’s possible and figuring out feasibility of solutions).
Thanks so much, @dsarlis, I will be in touch. We’ve already created a Backup canister for Data so we’ll probably start there. Will undoubtedly have many questions!
10 people have installed the MVP but only 3 (other than Evan and me) have posted. Most of these folks are top IC devs with very little time, so I think everyone’s waiting to see a few of their peers post first. So to incentivize taking this first step we’ve built two new features, described below. If we can get at least 10 panelists to post (hopefully 20), with a few of those being new hostposts, it should be enough content to open things up to the Community.
Voting and posting will now be rewarded with vCVL, a virtual token that will be exchanged for real CVL during our allocation event.
Voting — 10 vCVL per vote
- Hostposts — 100 vCVL
- Consensus — 1000 vCVL
- Founding Panelist — 1000 vCVL (5 posts minimum, 2 must be hostpost)
- Replies — 20 vCVL
Now panelists will be able to share Xchange Link Cards on most social platforms. Just tap the Share icon button on the Player’s bottom bar and you’ll then be able to choose where to share and make that happen. No better way to grow an audience, I think you’re going to like it.
Civol Web — Awaz decided to explore Agent-js instead of updating Agent_Dart for Flutter Web, and it looks like it’s going to work. We should have a preview of the web version soon if all continues to go well.
Civol Web Video — We have an issue on web with the chunking infrastructure (FFMPEG) that works perfectly well on mobile. So after we fix the remaining bugs in the agent we’ll focus on this, and it’s why we’ll only be offering a preview of Civol Web at first, the video part may take a bit longer.
We’re looking forward to seeing some new active panelists this week as people try out our new features, and we may have a sneak preview of Civol Web by the end of the week.
Please DM me if you’d like to be a panelist on the issues of Constitution, Experimentation, Roadmap Governance, or some other topic!
How do we log in and post? I have been waiting to see accessible/ detailed instructions on how to access it so I can “do my part” at the very least. Would you mind sharing how/ where your application is? I can share these details on my Distrikt feed and attempt to have a few of my IC friends join the conversation to get more “peer” feedback going.
Edit: Please note* I will not “shill” your project, but as I think this could be a solution to spam prevention and other issues with NNS, I will share info. on how to access and use it, as I would for this forum. Only as a way to let end-users decide for themselves with little influence on their decision making.
Sorry it’s taking so long, @jsull9, we’re still focused on recruiting our founding panelists and recording sufficient initial content. When that’s done we’ll open it up to the Community. Hopefully soon, we’re doing everything we can, thanks for your support!
Where can i install the MVP App? has it opened for testing?
Thanks for your interest, @millionmiles! We’re onboarding our founding panelists right now. After they record enough initial content we’ll publish the app store links and open it up to the Community. Can’t wait!
Hi Everyone, I was able to do a new demo video for Civol last week that I would really love your feedback on.
We’re also putting final touches on a couple of features that will allow us to open up the MVP to the entire Community.
Won’t be long now, thanks again for your patience!
Amazing App! fantastic job!
I’m very looking forward to see it public for testing.
I believe Civol can great help NNS governance in future.
organized crime? in crypto? shocking! shocking I says !
Thanks for your honesty @CatPirate
and showing your character hidden behind your persona