Changes between Version 9 and Version 10 of LEGACY - LAMP proposal

Timestamp:

11/16/10 16:30:37 (14 years ago)

Author:

jeff.lusted

Comment:

--

LEGACY - LAMP proposal

@@ -14 +14 @@
     1. Speed of restore after failure
     1. Can we afford to lose transactions?
-    1. Turn around time for a support request. Advice please on this one.
+    1. Turn around time for a support request. _Advice please on this one_.
   * Type of data stored and usage. I'm not sure how to characterize this. What about:
     1. Transactional
     1. Research
+
+These are my guesses so far for...
 
 ==== Labels Webapp: ====
@@ -31 +33 @@
 
 ==== caTissue: ====
+  * Number of users: 10 at any one time. (At the moment there are only three)
+  * Hours of use during the day: 8:00 to 17:00
+  * Peak or sensitive periods: None.
+  * Level of activity. 300 transactions per week?
+  * Quality of service:
+    1. Speed of response: within 5 seconds.
+    1. Speed of restore after a failure: ?
+    1. We cannot afford to lose transactions, which would give rise to losing the locality of samples.
+  * Type of data: Transactional
 
 ==== i2b2: ====
+  * Number of users: ?
+  * Hours of use during the day: 8:00 to 17:00 by clients. However, it is possible updating/inserts into the system might become an overnight batch task.
+  * Peak or sensitive periods: None, but reference the above.
+  * Level of activity: ? 
+  * Quality of service:
+    1. Speed of response: ?
+    1. Speed of restore after a failure: ?
+    1. Some client side activity is transactional: System admin at least. What about batched updates/inserts?
+  * Type of data: largely Research.
 
 === VM's and Applications ===