是否存在系统应满足的特定指标，以将其视为/分类为实时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
答案 0 :(得分：3)
实时计算与性能无关，而是保证事件可以在一定时间内完成。从CPU调度算法到操作系统一直到正在构建的应用程序，实时需求都会影响整个架构。
实时要求是根据必须完成操作的时间量来指定的。同样，这必须是保证，并且系统通常会在未达到最后期限时出现故障（这不是预期的）。
答案 1 :(得分：1)
在高层（非常抽象）：
http://cs.brown.edu/~ugur/8rulesSigRec.pdf
在低级别，基本上它意味着（无论是硬件还是软件）：
一个。没有缓存：软件缓存，硬件缓存等。
湾没有流水线指令：这只是因为在每个分支点都可能不得不丢弃许多执行的指令，导致不确定性。
℃。没有异步机制（例如，中断）。尽可能使用轮询。这是因为在中断机制中，我们不确定事件何时会发生。
d。高度基于时钟或时钟触发的机制：这通常意味着在硬件内部分配时钟信号的复杂方式（查找“时钟树合成”）。
即我之前使用过LynxOS RTOS。它在处理过程中具有很高的响应性和可预测性。但是如果你看一下它的内部结构，你会发现它会跳过很多不太可能的事件错误处理 - 特别是如果它是硬件资源（例如，内存）。因此，总是假设存储器是可用的 - 仅仅因为它在整个设计中具有低阈值 - 以确保很少达到最大限制。当然，当你将数字推到极限时（例如，产生大量进程），LynxOS的实时行为不再表现出来。
答案 2 :(得分：0)
在业务需求文档中，应考虑应用程序的技术性质。上下文有助于确定需求是真正的real-time，是web real-time还是接近实时，这意味着只要处理允许而不必等待计划/批处理（例如，{ {3}}数据而不是每15分钟加载一次数据。）
根据SignalR的开发人员，这是trickle feed