hi Arne! Thanks for the reply!
On Sat, May 12, 2018 at 4:00 AM, Arne Babenhauserheide <arne_...@web.de> wrote: > Ragnarok and pristine Guile both let specific requests starve, while > fibers accepts higher average latency to avoid high maximum latency. > > Is this repeatable? If yes, then you can see the difference in > scheduling here: With fibers none of the 1000 requests has to wait more > than a second, while with pristine guile and with ragnarok some requests > can stall everything. If you have a lot of resources being loaded to > display a page, the maximum latency is the effective page load delay. Yes, Ragnarok is not preempt-able yet, so it may delay too long when a big request stall. There're only 4 situations for a task could be scheduled: 1. I/O blocking 2. The socket buffer is full (users may tweak it) 3. Resources are insufficient to allocate (listening sockets, DB connection pool, etc...) 4. Developers call (break-task) explicitly in the handler I would like to make it preempt-able, but I still don't get the skill how to do it from outside of a delimited-continuation. And I would like to implement a better scheduler, for now it's just simple FIFO. But I need to know how many size left when suspend-able ports were blocking. It seems there's not interface for me to get that size. Maybe there should be a patch for it. > I left out the 4-instance ragnarok test, because its coping with latency > in the face of overload is not comparable, since it is less highly > overloaded (and that’s the feature which struck me while reading). > > And anyway: These are already pretty good numbers. They don’t achieve > the level of static file serving with massive caching (in my tests > lighttpd could get more than a factor 2 increase over (fibers web > server)), but it’s already on a level where it could support around 500 > active users on a single instance running on consumer hardware. I have to mention that Django of Python got 700 req/s in the same test under my same condition. But it's trivial since Django is not good at performance but the security and full-featured web stuffs. I think the best choice is that to use Nginx for reverse-proxy, since Nginx handles static files that may get 300,000 req/s though-out. No one can compete with it for static files handling. > What I also see is that Artanis seems to have low overhead. How do the > numbers change with more complex pages? I have to mention that even I have modified the code to do real json serialization from assoc-list, the test result still remains. But OK it's the credit of the author of guile-json ;-) For more complex pages and DB based dynamic pages, I've tested before roughly, it's not bad. And I have many ideas to optimize it. So no hurry to test the current things. I'm going to submit Artanis to Techempower for full tests, there'll be more con-vincible test result. But before that, I have to finish all the features in my TODO, and make it more stable to avoid crash. The version 0.2.5 is already very stable by eliminated many exceptions. But I still need more users to test it and feed back. Best regards.
