bright bough
I know that the only reliable answer I can get involves running a test and I will eventually load test my API, so consider this as a preliminary validation of my architectural choices where I try to make sure that I am not making a stupid mistake somewhere.
I am using a server with 4 CPU cores and 24 GBs of RAM where I hosted a simple golang chat application using net/http, htmx, pgx and pgpool (no websockets). Everything is i/o bound. The same server also hosts a postgres database with a shared_buffer size of 6GBs.
To serve the requests fast, I want to follow an asynchronous request-reply pattern where I send the response once the comment is persisted to the database and trigger a workflow asynchronously by executing the post-request actions inside of a worker pool. I would like to set the worker pool size at 10 000 workers. Since everything is io bound, my understanding is that this should not have a very important impact on the resources available given that the default stack size of a goroutine is at 2kbs. Correct me if I am wrong.
I am planing to load test it with 10k concurrent connections (very simple workflow involving requesting homepage, navigating to channel page, posting, requesting another channel page with a delay between each request)
So here's my question. Am I planning things wrong? Am I overestimating the output I can get from the resources of the server? Are worker pools a poor solution to handle in process async events? Thank you in advance.
frank tide