right but I mean convex vs in memory
right but I mean convex vs in memory implementation
17 Replies
probably makes sense to move this into a thread
what is your main concern? the cost?
We’ve built a platform where we launched a PvP game — players basically try to jailbreak an LLM and can see their opponent’s chat in real time. Right now, it’s built on top of WebSockets and Redis, but Convex could give us a whole new level of robustness. The question is whether it would still be cost-effective if we scale to around 100–200 concurrent users, with peak usage spikes up to 3–5k.
i'm assuming this is a free to play thing?
yeah
I mean we are ok paying some amount of money
but reasonably couple hundred tops
just based on the prices i don't see you going much over what the pro plan covers tbh
you can run some tests with it then check your usage in the admin panel to do some rough math
I mean update per socond would be 2.5 mil a month
so 100 concurent is like 250 mil no ?
with absolutely no optimizations it could be a lot yes, but ideally something like this should be optimized for reducing calls
How can I do that ?
I would love some suggestions !
well in that component you can limit the amount of mutations/queries that the chunk appender triggers
like by sentence instead of by token or something.
right right
that's really the only bottleneck is how often the chunk appender is running
Hey, one more question — if, in each game, users are chatting with the LLM, does that mean each user is creating a separate HTTP connection? Would that limit me to 128 concurrent connections? Thanks again for all your help!
with this component yes i think so. if you wanna just use queries for everybody, the agent component is really good
there’s a chance for your specific scenario convex might not be the best fit though if you expect to actually have 1000s of concurrent requests for a game that is free and realtime.
i can’t remember, but may have read in the docs somewhere that realtime gaming type stuff isn’t really the ideal use case.
ok thank you
I still think we can make it work with some optimizations and compromises
The value is massive
Do you know by chance how does t3 chat do streaming to so many users ?
they are primarily streaming to a single user instead of mirroring. so by default most of the usage would be through the http action sse stream. which is a single function call. it’s the mutations/queries that could get heavy when mirroring the stream to a second person that didn’t initiate the call
So if we save only one message end, wouldn't we still tun into 128 concurrent http actions?
because thats a compromise we're willing to make
save once or twice a message