We're using YARP as a reverse proxy for a SaaS #1178
-
|
Our DotNest service is an Orchard CMS (Orchard 1) and Orchard Core SaaS, i.e. you sign up and can quickly create hosted Orchard sites. For the Orchard 1 version we're using IIS Application Request Routing as the reverse proxy but for the Orchard Core one we wanted something newer, and we opted with YARP. Given that Orchard Core is also an ASP.NET Core web app, having another such web app as the reverse proxy that can be extended directly in .NET seemed like a good choice (you can read more about our motivation and goals here). While YARP is serving requests in production, we don't have much experience yet. Setting up YARP itself was quite simple. Adding SSL to the app (which is not necessarily about YARP - though see: #305 - but Kestrel) and deploying it to Azure Container Instances posed a bigger challenge, mostly due to the lack of detail in the applicable documentation. What was quite strange is that the latency of requests went down dramatically when served via YARP: When accessing files/apps hosted in the East US Azure datacenter the roundtrip to me in Hungary was 400 ms when going to the Azure App Service directly but is <150 ms when there's the YARP instance in between. (Given the transatlantic latency roughly 150 ms is what I'd expect.) I don't know why it was slower before but this is, of course, a welcome unexpected present. Just wanted to tell about a YARP implementation, maybe as a bit of inspiration for others. Let me know if you have questions! I've also submitted feedback: #916. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
In terms of the latency improvements, it may be related to TLS handshaking and connection pooling. YARP will keep the connection open to the back end (with a timeout), so it can be used for subsequent connections. |
Beta Was this translation helpful? Give feedback.
-
|
Hmm, interesting. The app serves the requests in <50 ms usually (as indicated by Application Insights) so the time is taken somewhere else. From what I could tell from Chrome was that the request was mostly "waiting", i.e. most of the time was taken while waiting for the first by to arrive in the response. (So not TLS handshaking.) |
Beta Was this translation helpful? Give feedback.
In terms of the latency improvements, it may be related to TLS handshaking and connection pooling. YARP will keep the connection open to the back end (with a timeout), so it can be used for subsequent connections.
If you can capture logs in the back end, to compare with the client, it would be good to see how long the backend is processing the request, and if the problem is with intermediary infrastructure.