是否存在系统应满足的特定指标才能被视为/分类为实时 Web 应用程序或近实时 Web 应用程序？
当我看到我正在使用的系统的非功能性需求时，该解决方案应实时/近乎实时地返回数据。我了解这些术语的定义（如http://en.wikipedia.org/wiki/Near_real-time所示），但我想知道是否有类似应用程序 UI 的标准（例如：Gnome 建议 http： //developer.gnome.org/hig-book/3.5/feedback-response-times.html.en ) 用于在 Web 应用程序中接近实时的期望。
这是另一个问题的变体： Define realtime on the web for business
实时计算与性能无关，而是保证事件可以在设定的时间内完成。从 CPU 调度算法到操作系统，一直到正在构建的应用程序，实时要求对整个体系结构都有影响。
实时要求是根据必须完成操作的时间量来指定的。同样，这必须得到保证，当没有达到最后期限时，系统通常会出现故障（这不是预期的）。
另见什么是“实时”
在高层（非常抽象）：
http://cs.brown.edu/~ugur/8rulesSigRec.pdf
在底层，基本上是指（无论是硬件还是软件）：
一种。无缓存：软件缓存、硬件缓存等。
湾。没有指令流水线：这仅仅是因为在每个分支点可能必须丢弃大量执行的指令，从而导致不确定性。
C。没有异步机制（例如，中断）。尽可能使用轮询。这是因为在中断机制中，我们不确定事件何时发生。
d。高度基于时钟或时钟触发的机制：这通常意味着在硬件内部分配时钟信号的复杂方式（查找“时钟树合成”）。
e. 我以前用过 LynxOS RTOS。它在处理过程中具有很高的响应性和可预测性。但是如果你看一下它的内部，你会发现它跳过了很多不太可能的事件错误处理——特别是如果它是硬件资源（例如，内存）。所以内存总是被假设是可用的——仅仅因为它在整个设计中的阈值很低——以确保很少达到最大限制。当然，当您将数字推到极限时（例如，产生大量进程），LynxOS 的实时行为就不再表现出来了。
在业务需求文档中看到时，应考虑应用程序的技术性质。上下文有助于确定需求是真正实时的、Web 实时的还是接近实时的意思，只要处理允许，无需等待计划/批处理过程（例如，数据的涓涓细流而不是每 15 分钟加载一次数据）。
根据 SignalR 的开发人员的说法，这是让您的服务器端代码实时将内容推送到连接的客户端的能力。