在投掷504错误之前花费的ASP .NET核心捕获时间
我有ASP.NET Core 6.0 API项目，该项目内部调用其他端点以获取或从第三方应用程序设置数据。
当前正在进行性能测试，为哪个应用程序抛出504个网关超时错误。
我已经将超时跨度设置为program.cs文件，如下
应用程序在Azure App Service上托管，我们使用Profiler来捕获几个端点所花费的时间。
终点之一是花4分钟，少于10分钟的超时，但我们仍会遇到504个错误。
我们想知道这个超时是否在任何级别都被覆盖。
因此，是否有任何方法可以知道并记录在扔504个网关错误之前花了多少时间？
I have ASP.NET core 6.0 API project which internally calls other endpoints to get or set data from 3rd party applications.
Currently there is performance test going on , for which application is throwing 504 gateway timeout error.
I have set timeout span to be 10 mins in Program.cs file as below
Application is hosted on Azure app service and we are using profiler to capture the time taken for few endpoints.
One of the endpoints is taking 4 mins which is less than 10 mins timeout given , still we are getting 504 error.
We want to know if this timeout is being overridden at any level.
So is there any way to know and log how much time has been taken before throwing 504 gateway error?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您使用.NET Core API项目，并且需要致电第三方应用程序。
我可以确认的是，您的要求无法在HTTP请求中实现。由于浏览器的默认超时时间约为4分钟，因此不同的浏览器可能会有不同的时间，但是总时间不会超过5分钟，并且浏览器将崩溃。
打击答案是我的测试结果。
请求更高。 Web服务器无法在指定的时间内响应
src =“ https://i.sstatic.net/p7vby.png” alt =“在此处输入图像说明”>
我敢肯定，即使我们在Broswer中也会在Broswer中获得500个错误，该作业仍在后端服务器中运行。
options.limits.empalivetimeout = 10配置应用于后端httpclient发送的请求，而不是浏览器发送的请求。通过上述测试结果和分析的建议
，我认为需要以另一种方式实施这一要求。
如果有如此长的HTTP请求，我建议您创建HTTPCLIENT并在后端发布和发布请求。可以通过调用控制器方法直接实现浏览器使用的交互式请求。时间越短，互动体验越好。
以您的需求为例：
①前端浏览器发送请求，提交任务并在提交后返回JobID，
status应为创建。JobID和状态可以存储在REDIS或其他缓存中。②提交任务后，httpclient提出异步请求，并等待操作完成。假设任务在10分钟后完成，则可以将Jobid标记为已完成。
③这只是一个例子，建议。我们可以在前端localstorage中创建一个键值对，以存储JobID。当JobID未完成时，我们可以每十秒发送一次请求，以询问服务器是否结束了。如果完成，请终止循环。清晰的Jobid信息在LocalStorage中。
如何设计它需要进一步的研究。这只是一个主意。由于浏览器的限制，我们遇到了504错误，并且应用程序服务无法直接获得504错误之前的运行时间。最多可以使用日志记录一些信息，但这肯定会给服务器施加压力，并且无法解决问题。
我遇到的常见应用程序场景是Azure门户。在创建资源时，一些资源需要半小时以上。通过上述设计，我们将在单个浏览器HTTP请求上花费的时间缩短了最少。
You use .net core api project, and you want call third-party applications.
What I can confirm is that your requirements cannot be achieved in an Http Request. Because the default timeout time of the browser is about 4 minutes, different browsers may have different time, but the overall time will not exceed 5 minutes, and the browser will crash.
Blow answer is my test result.
The request timed out. The web server failed to respond within the specified time
I am sure even we get 500 error in broswer, the job still running in backend server. The
options.Limits.KeepAliveTimeout = 10configuration should be used for requests sent by the backend HttpClient, not for requests sent by the browser.Suggestion
Through the above test results and analysis, I feel that this requirement needs to be implemented in another way.
If there is such a long http request, I recommend creating httpclient and making get and post requests on the backend. The interactive request used by the browser can be directly implemented by calling the controller method. The shorter the time, the better the interactive experience.
Take your needs as an example:
① The front-end browser sends a request, submits a task, and returns a jobId after it is submitted, and the
Statusshould becreating. ThejobIdandStatuscan be stored in redis or other cache.② After the task is submitted, httpclient makes an asynchronous request and waits for the operation to complete. Assuming that the task is completed after 10 minutes, the jobId can be marked as completed.
③ This is just an example, suggested. We can create a key-value pair in the front-end localStorage to store the jobId. When the jobId is not completed, we can send a request every ten seconds to ask the server whether the task is over. If finished, terminate the loop. Clear jobId information in localStorage.
How to design it needs further research. This is just an idea. Because of the limitation of the browser, we encountered the 504 error, and the app service cannot directly obtain the running time before the 504 error. At most, log can be used to record some information, but this will definitely put pressure on the server, and it will not solve the problem.
The common application scenario I encountered is the azure portal. When creating resources in it, some resources take more than half an hour. Through the above design, we have shortened the time spent on a single browser http request to a minimum.