Fiber: 🤔 Fiber perfomance / benchmarks

[bogdanciuca]

Why doesn't fiber use easyjson for serialization? What about query performance improvements?

I am trying to decide on a Go framework for developing high performance and reliable http microservices for the next few years. Looking at various benchmarks (e.g. TE), it seems that fiber is one of the strongest candidates, since it's based on fasthttp and offers plenty features.

However, one of its downsides is multiple query performance on physical (up to 21% difference), while cloud stats look good (for Go), but still bad compared to e.g. Java. Also, single query performance (smaller difference, but up to 8% is still noticeable).

The other is json serialization performance (up to 18% difference is quite significant). This might also impact stats for query benchmarks, assuming they involve json marshalling.

Are there any plans for this integration or any other improvements regarding these topics?

Thanks for this awesome framework!

[welcome[bot]]

Thanks for opening your first issue here! 🎉 Be sure to follow the issue template! If you need help or want to chat with us, join us on Discord https://gofiber.io/discord

[Fenny]

Hi @bogdanciuca, sorry for the late reply.

You have to take into account that these benchmarks are edge cases and Fiber scores top 3 on all benchmarks versus other Go frameworks. I'm not convincing you to choose Fiber for your next project, it's up to you what language/framework you feel comfortable with.

When it comes to other languages in the benchmarks, you can see that Fiber scores in the top 25 ( out of 422 - 655 ) which is still pretty impressive regarding the fact Go has some overhead because it has proper concurrency and garbage collection support.
When other Go frameworks have a higher score, that means we have room for improvement 🚀

I think the big selling point here is minimalism and design for fast development with zero memory allocation. I think Fiber provides a simple API and installation to get started rather quickly, along with the insane compile time that Go provides.
We are improving Fiber almost every day, it's a growing community with great documentation and weekly releases

So in summary, I think it's use-case dependent and development speed is a major factor if you ask me.

Some worthy mentions taken from the tfb benchmarks to check out 👍
https://github.com/actix/actix (rust)
https://github.com/an-tao/drogon (c++)
https://github.com/h2o/h2o (c)
https://github.com/wizzardo/webery (java)
https://github.com/metosin/reitit (clojure)
https://github.com/reactiverse/es4x (js)

I hope this answer some of your concerns, feel free to close the issue or comment if you have further questions.

[kiyonlin]

Hi @bogdanciuca , thanks for the good issue!

We have been doing work to optimize performance. Recently there has been an optimization for json(#581)

But what I want to say is that if you want to do microservices, then the performance of fiber is definitely enough. Because the bottleneck of microservices basically lies in the _network_.

And compared to Java, golang can save more memory, speed up the compile time and simplify deployment.

As @Fenny said, Fiber has its own characteristics. And performance is generally not the first priority imo.

[bogdanciuca]

Hi @Fenny , thanks for the prompt feedback!

I'm not convincing you to choose Fiber for your next project

No need for that, I'm almost there because Express productivity with Go performance = <3. However, let me share a bit more context:

• I need a Go framework (am aware of alternatives)
• I need a fast and reliable http server (e.g. fasthttp)
• I need a reliable community that keeps performance a priority
• Current requirements involve caching (in memory + Redis), jwt verification, http calls / proxy scenarios, kafka for messaging, k8s integrations, etc

I am quite confident that Go is perfect for this, since it's mostly networking stuff (like @kiyonlin mentioned). There's some digging to find the right libs, however I still prefer that to our only alternative - Java (Spring Boot).

When other Go frameworks have a higher score, that means we have room for improvement

We have been doing work to optimize performance. Recently there has been an optimization for json(#581)

That's great! I understand that performance is not the first priority, but to be completely honest, if Fiber wouldn't rank so good I wouldn't be posting these questions, I would probably be writing my own micro-framework based on fasthttp. So I guess it matters to some degree.

Putting that aside, another concern is that Fiber looks like a baby (born in 2020). The community looks great, however I'm not sure about commitment, scope, roadmap, etc. Care to share?

The other concern is the obvious dependency on fasthttp (around since 2015). Although quite popular, if something happens, will the Fiber community take on the extra responsibility?

[songjiayang]

I want fiber to remain competitive so we need do some pprof work about www.techempower.com all benchmark test and keep looking.

[kiyonlin]

Thanks @songjiayang .

I want fiber to remain competitive so we need do some pprof work about www.techempower.com all benchmark test and keep looking.

Yeah of cource.

We have optimized the code to participate in the competition, if you have any better idea, welcome to submit PR.

[Fenny]

@bogdanciuca let me try to answer some of your questions.

• Fiber has almost no overhead on top of the Fasthttp engine, we follow the same _no-memory allocation_ principle.
• This project is very young indeed, but we managed to set-up a mature and growing open source project building a great community ( please join us on Discord 💭 ) .
• We do not have a specific roadmap / scope on paper yet, but when I have some time I will definitely clarify this.
• I do agree that our biggest dependency ( fasthttp ) is both a advantage and disadvantage, we are planning to have our own http core in the feature. @ReneWerner87 and I are working on a event-driven networking core that makes direct epoll and kqueue syscalls.

I hope this answered some of your questions, feel free to close or comment on this issue 👍

[bogdanciuca]

@Fenny thanks for the detailed info! Looking forward to seeing some sort of roadmap and the new networking core (I assume it will be fully backwards compatible with fasthttp).

@kiyonlin @songjiayang thank you for your feedback and contributions to Fiber.

As far as I'm concerned, I'm going to push it in our stack and hopefully will be able to pitch back to the community. I still need to run some load testing / benchmarks, but I'm confident I'll see similar results to what I've seen with fasthttp. Closing this for now, but I might come back with other questions.