As my post described, all webservers I tested have deficiencies either in speed, memory leaks, or deal-breaking missing features. While individual servers excel in some areas (httpbeast is fast in raw request-response performance for example), there is none that satisfies all requirements that are provided by most of the languages you referenced.
I previously worked with the Vert.x toolkit on the JVM which had speed and request streaming, which is my point of reference. Its memory usage was predictably high because of the JVM, but it didn't leak memory. I'm also not aiming to compare these servers with really bad setups like the Python one you mentioned. It's unproductive to play the game of saying "well we're better than this dire setup." I understand why you're saying it, but it's not relevant. > I have been using Nim's AsyncHttpServer in production for five years and > everything has worked great. And, in my opinion, Mummy is not a toy - just > take a look at Guzba's recent forum posts. I don't know if I pointed it out clearly or not, but from my testing, I think Mummy is actually one of the few servers that can be reasonably used for production services, and most certainly is being used successfully for real-world, high-pressure cases. I'm not here to say Mummy is objectively deficient, but I pointed out that it's missing streaming I/O which makes it unsuited for many tasks. > The feature you want - streaming video - it's just the tip of the iceberg for > a video site. You also need to store the files, back them up, and have > multiple locations worldwide with a CDN. You are much better served by > something like AWS's S3, GPC's CloudStore, Backblaze's b2, and many other > competitors. They all offer similar APIs. Building a file server like S3 is > entirely different from building a logic server, and unfortunately, there are > no webservers that fit your needs. I know you're not trying to be demeaning here, but I know what it takes to build and maintain a video site. I've worked on and do work on sites that have hundreds of thousands of users with tens of terabytes of video. This is not at all new to me, I've also implemented entire video sites from scratch that are currently in use. With that said, you still need streaming I/O to ingest the files initially. You need to receive the video to then send it to the processing server which it will be converted into other formats before being uploaded to S3/B2/etc. I'm also not oblivious to the fact that you're going to be serving over a CDN in most cases. I would also like to point out that none of these things discount the fact that unstable/slow servers or servers that lack streaming I/O is a real lack. When you work with servers like Vert.x's HTTP server, you realize that you can have both speed of response _and_ async streaming I/O. They're not mutually exclusive. I'm not here to start an argument either. I'm currently working on implementing streaming I/O for httpx, so this isn't just talk.
