Saw this... but why not?

[unisqu]

You would not want to use this framework if you need to handle long-running requests (milliseconds or more). For example, a web api that needs to connect to a mongo database, authenticate, and respond; just use the Go net/http package instead.

Why not? What will be the problem if I do so? Most request will be sub milliseconds but just one or two will be in the milliseconds... but I'm curious what will the problem be... can you elaborate?

[tidwall]

Because you risk having a sluggish server.

I'm very picky when it comes to performance and for me a millisecond can feel like an eternity, but ultimately it depends on your tolerance level.

An Evio loop can only process one event at a time. Long running operations can block the entire loop and make the system feel slow. I do not recommend using Evio when the duration of an operation cannot be determined, such as making network calls to non-local services.

With the standard Go net package this is a non-issue because the Go scheduler is so damn good.

I generally use Go's net package by default. And then Evio for specialized use cases, where each request has a predicable response time.

[unisqu]

where is the timeout configuration for this?

[tidwall]

What do you mean by timeout?

[unisqu]

I do not recommend using Evio when the duration of an operation cannot be determined, such as making network calls to non-local services.

we can just time out this connection. so why is there no timeout configuration feature?

[tidwall]

If by timeout, you mean something like conn.SetDeadline. That’s not a feature that I have on the roadmap.

If you are concerned with IO deadlines then I recommend that you use the net package. It provides timeout operations.

[unisqu]

what a waste. it just lacks that timeout feature.