2

Is there a specific metric which a system should meet to be considered/classified as real-time web application or a near- real time web application?

When I see a non-functional requirement for a system on which I am working which states the solution shall return data in real time/near real time. I understand the definition of the terms (as found http://en.wikipedia.org/wiki/Near_real-time), but I was wondering if there were standards like one might find for an application UI (example: Gnome recommendations http://developer.gnome.org/hig-book/3.5/feedback-response-times.html.en) for expectations of near real time in a web application.

This is a variant of another question: Define realtime on the web for business

Community
  • 1
  • 1
Thronk
  • 624
  • 14
  • 37
  • From the wikipedia page you linked, "The delay in near real-time can be as high as 15 to 20 minutes in some applications." Contrast this to the entry on [real-time Computing](http://en.wikipedia.org/wiki/Real-time_computing) in which the time-delay constraint is often milliseconds or microseconds. Examples include anti-lock break systems and medical systems. – svidgen Jan 18 '13 at 03:50
  • Yes, but the type and speed of transmission in a web application would indicate the answer for a web application is > milliseconds and < 15 minutes. I am looking specifically for a web application recommendation. – Thronk Jan 18 '13 at 03:52
  • 2
    I think the concept of real-time computing is pretty clear. Operations need to be responsive "immediately" and without interference from other processes -- i.e., no other unstable processes are running in the background, and the "real time" process runs in constant time. *Near* real-time, as indicated to by the article you linked, is subjective. If I had to guess, the term started in a marketing department somewhere. – svidgen Jan 18 '13 at 03:55
  • 2
    There is no such thing as a "real time web application". Network latency alone would mean this isn't possible. – Ken White Jan 18 '13 at 03:56
  • I think the most accurate you can get in labeling something "real time" or "near real time" in a web application is "very low latency with respect to current events." I.e., a web application with a feed of some sort that doesn't inject any "significant" delays. But again, the value of "significant" is subjective in *near* real-time applications. And a *real* time application is a nearly impossible feat -- you'd need a stripped OS for both the clients and server that *only* served the purpose of this application. And you'd probably need to be on a network dedicated to this app alone. – svidgen Jan 18 '13 at 04:01
  • 1
    This paper references response times of cloud hosted web applications and seems to indicate something in the neighborhood of 4 seconds for a reponse is acceptable. This is a better target than either milliseconds or 15 minutes https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&ved=0CD0QFjAB&url=http%3A%2F%2Fwww.iiste.org%2FJournals%2Findex.php%2FIKM%2Farticle%2Fdownload%2F686%2F579&ei=8cj4UIOGAufV0gG5goDQDw&usg=AFQjCNELrazB_xpEJFGPKeQ2ALfFjD2hNQ&sig2=OQRfHCGZlpCgRT3yPJ2nzw&bvm=bv.41248874,d.dmQ – Thronk Jan 18 '13 at 04:03
  • Ken White - http://en.wikipedia.org/wiki/Real-time_web would disagree. Specifically: The real-time web is fundamentally different from real-time computing since there is no knowing when, or if, a response will be received. The information types transmitted this way are often short messages, status updates, news alerts, or links to longer documents. The content is often "soft" in that it is based on the social web—people's opinions, attitudes, thoughts, and interests—as opposed to hard news or facts. – Thronk Jan 23 '13 at 20:14

3 Answers3

5

Real-time computing has nothing to do with performance, but rather the guarantee that an event can be completed in a set amount of time. Real-time requirements have implications throughout the architecture from CPU scheduling algorithms to the operating system all the way to the application being built.

Real-time requirements are specified in terms of the amount of time in which an operation must be completed. Again, this must be guarantee and systems will often fault when the deadline is not met (this is not expected).

See also What constitutes 'real time'

Community
  • 1
  • 1
Michael
  • 701
  • 6
  • 18
  • Thanks, the link answered my question in that the answer for a business system is really defined by the business user within the constraints of the system and its architecture. My app is real time in the same context as the banking application in the answer to your linked question. – Thronk Jan 23 '13 at 18:53
  • Adding any reference book/article/document will help a lot for further study. – ar2015 Mar 17 '18 at 06:05
3

At the high level (quite abstract):

http://cs.brown.edu/~ugur/8rulesSigRec.pdf

At the low level, basically it means (whether it is hardware or software):

a. no caching: software cache, hardware cache etc.

b. no pipelining of instructions: this is simply because at each branch points a lot of executed instructions may have to be thrown away, resulting in indeterminacy.

c. no asynchronous mechanism (eg, interrupt). use polling whenever possible. this is because in interrupt mehanism, we are not sure when the event will happen.

d. highly clock-based or clock triggered mechanism: this usually means a sophisticated way of distributing the clock signals inside the hardware (lookup "Clock Tree Sythesis").

e. I have used LynxOS RTOS before. It has high responsiveness and predictability in its processing. But if you look at its internals, you will see that it skips a lot of unlikely event error processing - especially if it is hardware resources (eg, memory). so memory is always assume to be available - simply because it has low threshold in its entire design - to ensure maximum limits are seldom reached. Of course, the moment you pushed the numbers to its limits (eg, spawning lots of processes) the realtime behavior of LynxOS does not exhibit anymore.

Peter Teoh
  • 6,337
  • 4
  • 42
  • 58
0

When seen in a Business requirements document, the technical nature of the application should be taken into consideration. Context aids in determination of whether the requirement is truly real-time, is web real-time, or is near real time meaning as soon as processing allows without having to wait for a scheduled/batch process (for example, a trickle feed of data as opposed to a data load every 15 minutes).

According to the developers of SignalR, this is the ability to have your server-side code push content to the connected clients as it happens, in real-time.

Thronk
  • 624
  • 14
  • 37