I'm working on the Big Smokes Cigar Shop assignment and was wondering about where to address the stringent system performance NFRs (e.g. Site response: 90% of all transactions to be under 5 seconds and no transaction exceeding 10 seconds).
I've gone through the example case studies and the corresponding solutions in both Mark Cade and Humphrey Sheil's study guides (1st and 2nd editions), but could not find the system performance NFRs being addressed in the solutions.
Again I am not SCEA certified, am working on getting there :-) ..But based on my real life experience i think it will be useful to highlight the design decisions that you have taken to address/cater to the stringent NFR's.
Well, truth be told, you cannot specify any design suggestion that leads to the exactly specified times. But you certainly can specify design choices, that lead to better scalability and faster processing. An example is worth more than thousands of explanations:
High scalable systems with low response times usually use some kind of asynchronous processing. For instance, when user clicks a button (for instance makes an order) in the web application a message is created and sent for asynchronous processing. The web application can immediately continue, because it doesn't have to wait for the request to be processed (that is where MDBs play they part). When system load increases, messages spend more time in the queue, but users won't notice anything, because webapp doesn't get slown down. This is simple but crucial design choice, that enabled high load sites like LinkedIn to even function.
Think about it this way.
posted 10 years ago
Thanks Deepak, Rishi and Pavel.
High scalable systems with low response times usually use some kind of asynchronous processing.
The keyword here is "usually"
The problem statement requires a highly scalable system with low response times using synchronous JMS processing (request-reply model).
posted 10 years ago
Well, actually this is pretty simple. Your system should be designed to allow horizontal scalability. And most of the Java EE applications do. When load increases, you add more application servers to handle the load and load balancing takes care of distribution of the load (if you use session EJBs, you have that functionality out of the box). Withe horizontal scalability, you have to consider all thigs that come with it - for instance distributed transactions (if you're gonna use them), session state synchronization etc.
Another thing is scalability of the database as long as database could be (and it often is) major problem or bottleneck. Here you can consider scalability options of the well known database systems - for instance Oracle has the RAC.
In this type of NFR, generally we specify some techniques in architecture document like caching, asynchronous tasks, clustering, request/response compression (mod-deflet) etc. You may also specify architecture patterns which will going supports above options. In the deployment section of architecture document, do the capacity planning of the application.
Apart from techniques, you can also suggest some POCs of critical tasks to support design.