Ocelot: performance question

[WindowAzure]

Expected Behavior / New Feature

Does Ocelot stress the performance? If the gateway performance becomes the biggest bottleneck in microservices, it is very embarrassing. Does the author have any subsequent plans for performance improvement? Looking forward to your reply, thank you!

Actual Behavior / Motivation for New Feautre

Our team is planning to build microservices with Ocelot+consul, so we are very concerned about performance issues

[TomPallister]

@WindowAzure Ocelot doesn't have any known performance problems.

If you are using console logging with info/trace then the performance will be bad.

Perhaps @geffzhang can comment on Ocelot performance to reassure? In testing Ocelot adds minimum overhead to normal call to downstream service.

It is worth noting Ocelot doesn't really do any I/O apart from call service and this is usually the reason for poor performance in applications :) However there are certainly areas where Ocelot could be optimised but the same can be said of any software :)

[geffzhang]

Ocelot has no big performance bottleneck. The biggest problem with Ocelot's performance is HttpClient. This is about to be solved in the .NET Core 2.1 version.

[TomPallister]

Agreed! I'm looking forward to 2.1. I will close this issue now!

[WeihanLi]

Is there a performance comparison with kong, zuul or other api gateway products?

[balarvs2002]

Will there be any performance issue , If I use log4net elascticSearch appender with warnings/Error log level ?

[Mar4eli]

Sorry for the necroposting. But i was able to find this project: https://gitee.com/hongjun45/Ocelot

Maybe it would help. But use it on your own risk. I haven't checked this code for vulnerabilities

[AnthonySteele]

What are the performance _characteristics_ of Ocelot? What load and what throughput does it support?
What is the typical time to first byte of a downstream service from when Ocelot gets the first byte? Does the downstream service always get first byte after Ocelot gets last byte, or can it be before?

Does ocelot deserialise the entire request into C# objects, and the serialise it out again while passing through? How often does .NET GC happen when running Ocelot?

What do your benchmarks say?

I don't want to talk in terms of performance "issues" because that's not a meaningful phrase in general without a specific use-case. YYMV.

But if you know how Ocelot performs, then it can be meaningfully compared, and a decision taken as to when it's "the right tool for the job" or if it is appropriate to step up to a more "bare metal" gateway such as NGINX, which is undoubtedly more effort to get set up, but hard to match in terms of load and throughput.

tl;dr: It's not clear when Ocelot is "The right tool for the job" and knowing performance characteristics is a big part of that.

[AnthonySteele]

My understanding of code like this is that Ocelot cannot send the first byte to the downstream until after the last byte has reached ocelot and been read into memory. And likely the same on the response.

So this puts constraints on how fast Ocelot can operate, and how much it can scale. and each request / response creates objects that need to be collected with GC.
Nginx does not share these constraints - although it has it's own pros and cons. So it is clear that Nginx is a very different piece of software to Ocelot, and that they are suitable for very different scenarios.

[bc4250]

Is there a performance comparison with kong, zuul or other api gateway products?

With Ocelot in K8S docker, .netcore 3.1 runtime, set serilog level to "Error", use consul as service registry, test one simple echo api service, just get 20% throughput compare to direct API, more concurency worse performance; but test with Kong, get much better, nearly the same with direct api calling.

Could someone tell me a clue to finetune the performance of Ocelot? thank you in advance! Because it's in dotnet we already using, so if performance not too bad we prefer to choose Ocelot.