Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Publish spring-webflux results #52

Open
devcsrj opened this issue Aug 20, 2019 · 4 comments
Open

Publish spring-webflux results #52

devcsrj opened this issue Aug 20, 2019 · 4 comments

Comments

@devcsrj
Copy link

devcsrj commented Aug 20, 2019

I noticed that the spring-boot2-webflux-* were added, but there are no results published in the README.md. The move to a reactive+netty is a major change, and I am interested on how it stacks up against light4j.

@stevehu
Copy link
Contributor

stevehu commented Aug 20, 2019

@devcsrj The web flux has throughput at about 150,000 on a 2017 Mac Book Pro while light-4j has about 2 million. The reason is not the netty as it is almost as fast as Undertow but the Spring framework is too heavy with too many dependencies. If you are using Undertow/Servlet based Sprint Boot implementation, we have provided light-spring-boot to leverage the light-4j cross-cutting concerns.

In the beginning, our focus it the performance in comparison with other frameworks; however, we are more focused on the embedded or sidecar gateway feature these days to resolve different enterprise use cases. The light-4j, light-router, and light-proxy give users a flexible gateway solution with minimum network components for security and stability.

My old desktop was retired and it doesn't make sense to publish only one of the frameworks on the new platform. I always consider to autorun and publish the result with light-bot but time is very limited.

@devcsrj
Copy link
Author

devcsrj commented Aug 21, 2019

The web flux has throughput at about 150,000 on a 2017 Mac Book Pro while light-4j has about 2 million

Damn, that's a massive difference!

...but the Spring framework is too heavy with too many dependencies.

I see. Theoretically, does this mean that if those extra dependencies that are not used in a pure HTTP context (e.g., spring-tx, spring-expression) were removed, the throughput will improve? Consequently, does this also mean that adding more dependency to a light4j application would then too suffer in throughput?

...we have provided light-spring-boot to leverage the light-4j cross-cutting concerns.

Oh, that's cool! That repo also has a spring-reactive, but sources seem to be empty. Is that intentional? Or was there just a lack of time to demo an integration?

@stevehu
Copy link
Contributor

stevehu commented Aug 21, 2019

Adding more dependencies is not the culprit but calling too many different dependencies is another story. Spring was designed to compete with Java EE so it is a monolithic framework by design. The applications on top of Spring and Java EE are heavy so nobody cares about how big is the platform. If you have an application that is 1 million lines of code, it might not be a concern that it is running on top of 12 million lines of Servlet container. However, if you are building a microservice with only 1000 lines of code, are you still comfortable to deploy it on top of 12 million lines of the platform? Light-4j is designed as cloud-native with minimum dependencies and additional ones are added per application. The final docker image is only about 50MB to 90MB in most of the cases.

@stevehu
Copy link
Contributor

stevehu commented Aug 21, 2019

I am thinking to build spring-reactive but there is no demand yet. This repo was started because one of our bank customers wants to migrate from Spring to Light-4j but doesn't want to rewrite all the existing services.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants