Non Functional Requirements for Part 2

[Miro Rimo]

hi everyone,
I'm trying to address the non functional requirements of the assignment and I did a lot of research but didn't reach to a solid approach.
The problem is that the assignment specifies specific performance measures (like 90% of transactions must be under 5 seconds and scalability is up to 200 concurrent users), how this can be ensured? what kind of assumptions I need to make to come with an optimum architecture?

Another requirement mentions 128-bit encryption as a minimum. Can this be achieved by just using HTTPS, that supports 128-bit encryption, as the communication protocol between the browser and the web server?

Many Thanks for your helpful inputs.

[J J Wright]

In a nutshell, non-functional requirements are usually satisfied by selecting appropriate design patterns and deploying to appropriate IT infrastructure.

If you don't understand how to meet your non-functional requirements you need to go back and look at these basic building blocks.

Think of it as test-driven development - identify your core technical risks, then iteratively design to mitigate them.

[Miro Rimo]

Thanks Jonathan.

I absolutely agree with what you say. My point is how to prove/show that this architecture/design can definitely meet these specific performance measures?
What kind of assumptions are needed? should these assumptions be numeric as well? if yes, based on which data?

[J J Wright]

In the real world, the high risk parts of your design will typically be implemented during the elaboration phase. Each iteration will then contain one or more (performance) testing phases, the results of which get fed back into your design.

In this case of the SCEA assignment you don't have the luxury of that feedback. However, this doesn't stop you from identifying where the potential, or most obvious, bottlenecks will be. For example, in the case of the transaction requirements, what are the likely reasons for a transaction exceeding that amount of time? Once you know the answer to that question you can start designing to mitigate the causes, or in cases where the causes are beyond your control, mitigate the effects. You might come up with any number of solutions based on your assumptions, but the point is you explicitly identified and addressed the problems.

If your assumptions involve SLAs with third-parties then obviously they'll be a numeric element to them.

[Miro Rimo]

I see. This is very helpful, many thanks.

For the deployment diagram, how can I assume the average or typical server capability in order to probably size the system?
For instance, if the target availability is 99.99%, this can be achieved in so many ways depending on single server availability, what could the assumption, of each server availability, that can be the starting point of doing the math?

[Vincenzo Meglio]

Miro Rimo wrote:I see. This is very helpful, many thanks.

For the deployment diagram, how can I assume the average or typical server capability in order to probably size the system?
For instance, if the target availability is 99.99%, this can be achieved in so many ways depending on single server availability, what could the assumption, of each server availability, that can be the starting point of doing the math?

HI evryone this is the first time that I post on this forum

I agree with Miro,
Is there somewhere a table showing the typical availability of a modern server with a fixed stack of OS, APPlication Sever , test application? and furthermore there is something similar for the maximum number of concurrent user (If you fix thinking time, elaboration time, OS , apllication LAyer, ecc..)
Or we need to build the main block of the application a take some mesaure on a real environment (I hope this is not the right way ( )

By the way I'm taking the part 2 scea too

[Alexandre Portugal]

Hi Miro.

My assignment has similar requirements as yours and I don't think performance tests are very usefull since none of the diagrams we should deliver will reflect their effects on the resulting architecture.

But I've got some ideas for at least 2 of our requirements:

- No transactions should take more than 10 seconds
"For enterprise beans with bean-managed JTA transactions, you invoke the setTransactionTimeout method of the UserTransaction interface." (JEE 5 Tutorial).
Question: is it really interesting to give up from using CMT in order to garantee your transactions timeout ?

- 90% of transactions must be under 5 seconds
Well, if you can programatically set the timeout for your transactions using the method above, then it would be enough to design a "TransactionProfile" class responsible to log every transaction and, based on this history, determine on runtime which will be the next transaction timeout value needed for the system to address this requirement continuously.

[J J Wright]

...based on this history, determine on runtime which will be the next transaction timeout value needed for the system to address this requirement continuously.

Why would you implement a solution that dynamically changes the transaction timeout of your system? Imagine the system is experiencing problems. For example; it may be under extremely heavy load, experiencing networking problems, recovering from a hardware failure, etc. etc. As a result "transactions" are taking around 6 seconds. According to your proposal, at some point, the whole system shuts down because the profiling class says everything must take less than 5 seconds. Revenue for that sales channel is now zero.

is it really interesting to give up from using CMT in order to garantee your transactions timeout

No. You can still use CMT and set transaction timeout. You just do it through the app server.

it would be enough to design a "TransactionProfile" class responsible to log every transaction

Most app servers already have profiling functionality built in. If your system is experiencing problems it's up to the System Administrator to deal with it - that's their job. Besides, if a system is experiencing extremely heavy load, the app server or infrastructure in general may well implement some kind request throttling. That is, refuse some connections in an attempt to prevent the system from failing completely.

[Alexandre Portugal]

Imagine the system is experiencing problems. For example; it may be under extremely heavy load, experiencing networking problems, recovering from a hardware failure, etc. etc. As a result "transactions" are taking around 6 seconds.

I was told 90% of my transactions should be completed under 5 seconds. The scenario you said is high-realistic and should be taken into account, but that doesn't mean my system should stop processing longer transactions, it's just a question of creating a smarter algorithm for that.

No. You can still use CMT and set transaction timeout. You just do it through the app server.

If we keep my approach, we need to change the transaction timeout dynamically. I don't think we are able to do that through the app server.

Most app servers already have profiling functionality built in. If your system is experiencing problems it's up to the System Administrator to deal with it - that's their job. Besides, if a system is experiencing extremely heavy load, the app server or infrastructure in general may well implement some kind request throttling. That is, refuse some connections in an attempt to prevent the system from failing completely.

I agree with you, but I'm trying to address the requirements in a deterministic manner. Following your suggestion I will improve the performance for sure, but how do I garantee 90% of transactions under 5 secs?

Maybe I didn't get the point of all these non-functional requirements(NFR). Maybe they are just a guideline for performance tests after deploying the system. After all, how would we "architecturally" garantee 200 concorrent users (another NFR example)? But it's hard to believe that...

[J J Wright]

I was told 90% of my transactions should be completed under 5 seconds

OK, but if you were the customer would you accept that the system met this non-functional requirement if it simply pretends that some transactions never happened by timing them out.

Surely if 200 out of every 1000 transaction timeout you're not meeting the requirement. In which case, what have you achieved (other than a poor user experience)?