长时间处理后 Azure 网站超时

Question

团队，

我在 Azure 上发布了一个 Azure 网站。该应用程序从 API 读取大约 30,000 名员工，读取成功后，它会使用所有 30,000 名员工更新二级 redis 缓存。

超时发生在第二步，即当它与所有员工一起更新辅助 redis 缓存时。从我当地来看，它工作正常。但是一旦我将它部署到 Azure，它就会给我一个

500 - The request timed out.
The web server failed to respond within the specified time

从博客中我了解到，Azure 网站的默认超时设置为 4 分钟。

我已经尝试了博客上提供的所有修复，例如将应用程序设置中的命令 SCM_COMMAND_IDLE_TIMEOUT 设置为 3600。

我什至尝试将 Azure redis 缓存会话状态提供程序设置像这样放在 web.config 中，并带有夸大的超时数字。 <add type="Microsoft.Web.Redis.RedisSessionStateProvider" name="MySessionStateStore" host="[name].redis.cache.windows.net" port="6380" accessKey="QtFFY5pm9bhaMNd26eyfdyiB+StmFn8=" ssl="true" abortConnect="False" throwOnError="true" retryTimeoutInMilliseconds="500000" databaseId="0" applicationName="samname" connectionTimeoutInMilliseconds="500000" operationTimeoutInMilliseconds="100000" />

导致超时的违规代码如下： `

public void Update(ReadOnlyCollection<ColleagueReferenceDataEntity> entities) 
{ 
//Trace.WriteLine("Updating the secondary cache with colleague data"); 
var secondaryCache = this.Provider.GetSecondaryCache(); 

foreach (var entity in entities) 
{ 
try 
{ 
secondaryCache.Put(entity.Id, entity); 
} 
catch (Exception ex) 
{ 
// if a record fails - log and continue. 
this.Logger.Error(ex, string.Format("Error updating a colleague in secondary cache: Id {0}, exception {1}", entity.Id)); 
} 
} 
}

`

我可以对此代码进行更改吗？

请任何人帮助我...我已经没有想法了！

Answer 1

你做错了！ Redis 不是问题。主请求线程本身在进程完成之前被终止。您不应该让请求等待那么久。有一个硬编码的飞行中请求限制为最长 230 秒，无法更改。

在这里阅读：Why does my request time out after 230 seconds?

假设 #1：您正在从客户端的第一个请求中加载数据！

解决方案：如果 30000 员工记录是针对整个应用程序的，而不是针对每个特定用户的 - 您可以在应用程序启动时触发数据加载，而不是根据用户请求。

假设 #2：您有单独的用户，并且在来自客户端的第一个请求时，您必须为每个用户存储 30000 名员工数据。

解决方案：添加后台作业（可能是 WebJob/Azure Function）来处理任务。根据客户端的请求 - 返回 202（在标头中使用作业状态位置接受。然后客户端可以以特定频率轮询任务的状态，从而相应地更新用户！

编辑 1： 对于假设 #1 - 您可以尝试在将对象推送到 Redis 时对对象进行批处理。目前，您一次更新一个对象，这种方式将是 30000 个请求。绝对是会耗尽230秒的限制。作为一种快速解决方案，在一个对 Redis 的请求中批处理多个对象。我希望它可以解决问题！

更新： 当您使用 StackExchange.Redis - 使用以下模式来批处理此处已经提到的对象。

Batch set data from Dictionary into Redis

每个请求的对象数量取决于有效负载大小和可用带宽。由于您的网站托管在 Azure 上，因此我认为带宽不会成为大问题

希望有帮助！