Using your example and adapting it to http (dusty), then would I have to beforehand associate each route with a certain number of tasks (256KB/task) ? Something like:
for (0..num_tasks1) |_| {
try group.concurrent(io, root_handler, .{io});
}
for (0..num_tasks2) |_| {
try group.concurrent(io, register_handler, .{io});
}
Should I use a different group (std.Io.Group) per route ?
Then when I listen (try dusty_server.listen(address);) zio/dusty would automagically do the load balance ?
More noob questions:
Is it possible to add corroutines dynamically while dusty is listening ?
Is it planned for the future dynamic add/removal of routes in dusty ? For ephemeral routes.
Dusty automatically spawns tasks for each connection, you don’t need to do that yourself. See this minimal example:
The default runtime config, as shown in the example, will use one OS thread total, but one coroutine per active connection. If you have slow handlers and have 100k active requests, it will run 100k coroutines.
For dynamic routes, I’ve not considered it, but I don’t see it as super important, you can always achieve this yourself using wildcard matches in the router and the handling the sub-routing yourself.
Perhaps a silly question, but since this thread has gained some talk about memory usage/active requests, I was curious, is there way to see how the dusty application is doing at runtime? E.g., to know if you’re getting saturated by requests? It doesn’t have to respond to that of course, just be able to indicate it in some fashion. That way, people could know to spin up more nodes behind a load balancer. If this isn’t a foolish question, my only thoughts were if the internal logic logs something or if it exposes a socket over which a status query can be sent.
Not at the moment, both dusty and zio need to expose some metrics.
For dusty, it’s mostly informative, how many requests are we processing, what are the status codes, duration histogram, etc.
For zio, it’s more interesting, it can do things like task latency between it’s schedule time and when it actually runs. If that is too high, you might need to run more threads, for example. There are many metrics that can be useful that could be exported from zio.