Hi Ivan, thanks for your answer.
Unfortunately, it’s not that simple for me. I’m building something that serves binary content out of a database, not from the filesystem, and is accessible only via a REST API. In my case, I don’t care how fast webpages full of controls load, it’s not a web application.
This is why my test was focused on data throughput and not responsiveness of a web GUI.
Having said that, I would be happy with the 4MB/sec of Web 1.0, unless having 20 download sessions running, not only slows it down but crashes the server entirely. Now, that’d be a definite dealbreaker.
Since I’m not serving static files, but binary content that comes out of a data source, I can’t just use a web server that’s “made for that”. There is also a significant amount of logic between the data source and the web server and writing the content to the filesystem in order to have someone else serve it, is not really an option.
I wasn’t aware of this particular Xojo design guideline. Never seen it anywhere in the documentation and it’s not exactly a minor hint or remark.
I’d be willing to accept blame for not doing my homework right, but even at this time, I would really, really appreciate a Xojo employee confirming that Xojo is not what I ought to use for such application, so I don’t waste my time building something that’s not going to work properly in practice.