"Real-time" its a word that gets thrown about a lot in IT and its worth documenting a few of the different ways it gets used
Hard Real-time
This is what Real-time Java was created to address (along with Soft Real-time) what is this? Easiest way to say it is that often in Hard Real-time environments the following statement is true
Soft Real-time
This was another use case for RTJ, here there are deadlines but missing deadlines isn't fatal but does degrade the value of the result and results in degraded performance. Again though we are talking about deadlines not performance
This is when two machines are communicating on a task or processes within a machine, here the answer is 'as fast as is possible' there aren't any deadlines but the times are always measured below the microsecond level. These are calculations and communications that get done millions and billions of times so a shift from 0.1ms to 1ms over a billion attempts means that the end-to-end work takes just over a day against 11 days. This is the world of fast and HPC where the communications and processes need to be slimmed for speed.
Transactional real-time is about what it says, the time to complete a transaction, something that hits the database and returns. Here we are in the millisecond to a tenth of a second type of range, its this number that determines how internally responsive an application is. This is the end to end time from initiation to response and at that point the state of the system has been changed.
User transaction real-time is what looks fast to a user of a system, this varies from interactional systems where it means sub-second to internet solutions and web-sites where it might mean 5 seconds or so. Again this is the end-to-end time and includes something actually having happened and being able to check that it has happened.
Next up are the pieces that are the views on the recent reality the time it takes for a report to be generated from 'landed data'. Here BI guys tend to think of real-time in the same way as User Transactional real-time, 5 or so seconds is therefore acceptable. This isn't however an end-to-end time as the data is already landed and all that is happening is the reports being done quickly. Crucially however this is about reporting, its not about having transactional systems hitting the reporting system.
The next definition is for the end-to-end of BI, so the extracting of data from a source system, the loading and transformation of that data and finally a report being done which includes that new information. Here for BI the real-time definition can get longer and longer. I've had clients say that 5 minutes, 15 minutes or even 2 hours are considered acceptable 'real-time' responses. The point here is that when the current response time is 'next day' then something that is only minutes or even a few hours delayed is a significant increase in performance and is considered responsive.
In Chuck Norris real-time its happened before you even knew that you wanted it to happen.
Hard Real-time
This is what Real-time Java was created to address (along with Soft Real-time) what is this? Easiest way to say it is that often in Hard Real-time environments the following statement is true
If it doesn't finish in X milliseconds then people might dieSo if you miss a deadline its a systems failure. Deadlines don't have to be super small, they could be '120 seconds' but the point is that you cannot miss them.
Soft Real-time
This was another use case for RTJ, here there are deadlines but missing deadlines isn't fatal but does degrade the value of the result and results in degraded performance. Again though we are talking about deadlines not performance
If it doesn't finish in X milliseconds the system risks failing and will be performing sub-optimallyMachine real-time
This is when two machines are communicating on a task or processes within a machine, here the answer is 'as fast as is possible' there aren't any deadlines but the times are always measured below the microsecond level. These are calculations and communications that get done millions and billions of times so a shift from 0.1ms to 1ms over a billion attempts means that the end-to-end work takes just over a day against 11 days. This is the world of fast and HPC where the communications and processes need to be slimmed for speed.
Every microsecond counts, slim-it, trim-it because we're going to do it a billion timesTransactional real-time
Transactional real-time is about what it says, the time to complete a transaction, something that hits the database and returns. Here we are in the millisecond to a tenth of a second type of range, its this number that determines how internally responsive an application is. This is the end to end time from initiation to response and at that point the state of the system has been changed.
Don't make me wait for youUser transactional real-time
User transaction real-time is what looks fast to a user of a system, this varies from interactional systems where it means sub-second to internet solutions and web-sites where it might mean 5 seconds or so. Again this is the end-to-end time and includes something actually having happened and being able to check that it has happened.
Be fast enough so the user thinks its magicBI reporting real-time
Next up are the pieces that are the views on the recent reality the time it takes for a report to be generated from 'landed data'. Here BI guys tend to think of real-time in the same way as User Transactional real-time, 5 or so seconds is therefore acceptable. This isn't however an end-to-end time as the data is already landed and all that is happening is the reports being done quickly. Crucially however this is about reporting, its not about having transactional systems hitting the reporting system.
Let the user do all the reports and variations they want, we can handle it and not annoy themBI real-time
The next definition is for the end-to-end of BI, so the extracting of data from a source system, the loading and transformation of that data and finally a report being done which includes that new information. Here for BI the real-time definition can get longer and longer. I've had clients say that 5 minutes, 15 minutes or even 2 hours are considered acceptable 'real-time' responses. The point here is that when the current response time is 'next day' then something that is only minutes or even a few hours delayed is a significant increase in performance and is considered responsive.
Tell me shortly what went wrong right nowChuck Norris Real-Time
In Chuck Norris real-time its happened before you even knew that you wanted it to happen.
Problem solved
No comments:
Post a Comment