Web 应用程序中的并发性答案

【问题标题】：Concurrency in web applicationsWeb 应用程序中的并发性
【发布时间】：2011-01-14 07:50:11
【问题描述】：

因此，最近几乎所有平台提供商都非常重视提供新的工具/语言结构以实现更好的并发性。这也是为什么很多函数式编程语言的想法被集成到 C#、Java 等主流语言中的原因之一。

尽管这些在今天特别是在引入多核 CPU 时很有意义，但我想知道如何在 Web 应用程序领域特别使用这些。在 Web 应用程序中，很多并发由 Web 服务器本身管理，我很少看到在网页中实现多线程。 AJAX 还启用了“pagelets”之类的范例，以进一步提供帮助。

Web 应用程序通常包括快速获取结果，到目前为止，我们使用了许多策略，如缓存、冗余等来实现这一目标。如果有一些计算密集型的事情，它必须离线发生（客户端可以稍后查询结果或者可以实现回调）。

并发类型已经在很多库/框架中实现，这些库/框架通常用于 Web 应用程序（如数据库）、框架中的多获取（如 memcached）。

我找不到很多可以在 Web 应用程序上下文中使用最新并发平台和库的示例场景。所以我想知道它们在网络领域是否有意义。

【问题讨论】：

能否请您详细说明您的要求？
所以我想知道人们在 Web 应用程序中探索新的并发结构和库的方式。
我认为这是一个很有洞察力的问题。我认为 Web 应用程序实际上并没有非常自然地需要超出容器已经提供的并发性。我担心现在出现的新并发特性并没有人们想象的那么有用。让我们在十年后再次讨论这个问题，看看结果如何。

标签： performance web-applications concurrency

【解决方案1】：

当然，并发平台在 Web 应用程序中很有意义。例如，只需查看 SO（以及多租户框架 StackExchange）——在很多情况下，同一对象（问题、答案等）正在“同时”更新。这将是我想象的此类软件的一个重要考虑因素。

【讨论】：

【解决方案2】：

是的，在高性能服务器和长时间运行的任务中

在ASP.Net MVC 中查看Async controllers

【讨论】：

【解决方案3】：

由于默认情况下 Web 应用程序是并发的，因此您不太可能在 Web 应用程序中使用新的并发机制（例如用于 .NET 的 TPL 或 PLINQ）。在高负载的 Web 服务器上，您通常一无所获（您可以通过减慢另一个请求来加速一个请求）。但是，如果您有一个专用的网络服务器，它的大部分 CPU 周期都没有提供服务（同时有多个内核），那么这些技术可能会很有用。

[更新：] 只需阅读Parallel Programming with .NET blog 上的new article。这里有两个有趣的引述：

在大多数情况下，尤其是对于使用量大的 Web 应用程序，它可能没必要介绍额外的并行性，因为添加更多工作项只会导致 CPU时间的竞争和最终降低请求吞吐量。

和：

需要执行的 Web 应用程序昂贵的计算可能仍然如果单个请求的延迟是比整体要求更重要吞吐量。

我认为这回答了你的问题。

【讨论】：

【解决方案4】：

所有东西都是同步和一致的严格观点并不能很好地扩展。然后倾向于拥有更多异步并接受最终一致性。这也反映在语言和框架的设计方式上。

很多灵感来自功能领域，因为它非常适合这种计算模式。函数式编程有助于推理要执行什么，而不是如何和何时。

这实际上补充了传统的并发处理机制。

我找不到很多样本最近的情景并发平台和库可以在 Web 应用程序的上下文中使用。所以我想知道他们是否制作在网络领域很有意义。

这取决于你的意思。您不需要使用低级构造，例如 java.util.concurrent 中的构造。但是框架堆栈对异步的支持越来越好。例如，Servlet 3.0 引入了异步 Web 请求来简化 AJAX 应用程序的开发。因此，EJB 3.1 具有异步方法调用以与异步 Web 层集成。在底部，我们有函数（或委托、闭包）的低级抽象，它抽象了计算本身，以及计算所需的信息（其上下文）。我想 .NET 也是如此。

与传统的 Web 应用程序无关，而是将 Web 作为“云”，函数式编程有助于跨 CPU 和节点的分布式计算。一个著名的例子是 map/reduce 之类的，它们旨在处理大量数据。

所有这些结合在一起，我们看到一个 Web 应用程序保持响应，同时异步处理大量数据。

但是不，对于传统的网络应用程序，您不需要所有这些！

【讨论】：

【解决方案5】：

坚持你的问题...

如果有一些计算密集型的事情，它必须离线发生（客户端可以稍后查询结果或者可以实现回调）。

这正是有时需要后台并发（在服务器上）的部分，并且比 Ajax 产生的网络线程更可取：

后台计算可能会话过长，因此您不能使用网络线程（您的会话会超时）。
后台计算可能不需要保存该用户原本需要的太多信息，它可能需要更少的上下文，这有利于释放内存。
夜间批处理可能按块处理大型数据库表，并且需要对这些表的独占访问权限。可能需要多线程以将计算时间带入可接受的持续时间（允许其他任务跟随，或用户在可接受的持续时间后访问结果）。在晚上的某个时间范围内停止用户交互并处理一些批处理的情况并不少见，掌握当时的并发交互可能很关键。

【讨论】：

【解决方案6】：

关于网络应用程序中的所有并发性都基于多用户体验。通常它只是“每个用户一个进程”，没有共同点，并且可能仅在数据库级别连接，但是像 Flockdraw、usteream 和其他应用程序这样将许多用户实时组合在一起，通过多个线程保持相互连接和同步，并承担单独的负载用户，但可以实时主动地相互交流。

【讨论】：

【解决方案7】：

据我了解，问题源于概念并发的两种不同含义的复杂性：网站对用户请求的并发服务（宏观级别）与两个并发执行程序/进程/线程（微观层面）。

他们使用相同的词并发，但前者是同质的，如果我们简单地假设服务器只提供一种服务，并且两者之间没有交互/共性提供给不同用户的宏观服务。即使针对不同用户的服务进入数据存储层面，从而争夺 IO 资源，这更多的是微观层面的问题：两个查询/写入相互竞争共同资源。作为一种抽象，提供给用户的服务总是同质的，因此平台提供的并发功能/库（我猜你是指 Java、.Net 等）与 Web 应用程序无关，而只是微操作。他们。

【讨论】：