How can I assure a high QoS in a web application ?

[Federica]

Hi all java programmers,
I have got to design a Java architecture as university thesis.
It's a simulation of an auction web system which receives up to 200
users concurrently and
must assure a high QoS (max 5 seconds for delivering the web page in
peak time).

For the techical point of view I have stated in the thesis that the
framework will use AJAX for sending just changed data between
browser-server.

Anyway I must choose a policy for the site to assure the Qos (max 5
seconds). What could I choose ? I'm thinking to kill all the process
that exceed 5 seconds and re-dispatch the call......like if you hit the
"Cancel" button and reload the page........
bad idea ? any thought about how can I achieve this ? ( for example you
could inspect the stuck threads in the application server ??)

Hope I explained myself correctly....
Thanks in advance
Federica

 

[wesley.hall]

Hi all java programmers,
I have got to design a Java architecture as university thesis.
It's a simulation of an auction web system which receives up to 200
users concurrently and
must assure a high QoS (max 5 seconds for delivering the web page in
peak time).

For the techical point of view I have stated in the thesis that the
framework will use AJAX for sending just changed data between
browser-server.

Anyway I must choose a policy for the site to assure the Qos (max 5
seconds). What could I choose ? I'm thinking to kill all the process
that exceed 5 seconds and re-dispatch the call......like if you hit the
"Cancel" button and reload the page........
bad idea ? any thought about how can I achieve this ? ( for example you
could inspect the stuck threads in the application server ??)

Hope I explained myself correctly....
Thanks in advance
Federica

Federica,

At 200 concurrent request for a web application, you should be able to
hit a 5 second QoS requirement without any serious optimisation (on
reasonable hardware). Just make sure your database is suitably indexed.

I would avoid doing what you propose regarding killing threads that
live for > 5 seconds. 99 times out of a 100, if a thread is taking
longer than 5 seconds, and you kill it and retry, it will take longer
than 5 seconds the next time.

It would be advisable (given your specific performance requirements),
to write a servlet filter that could easily determine if a thread had
been running for > 5 seconds and if so, print a thread stack trace to
the log file. This would allow you to analyse and resolve the problem
at testing time.

Dont fall into the trap of over-designing from day one, to resolve
potential forseen problems at day 100 (especially when your QoS
requirements are as reasonable as this one is). It is far cheaper and
cleaner in the long term.

If you really must show proactive optimisation in your design, focus on
the database. This is where your performance problems will arrise.

 

[Red Orchid]

Hi all java programmers,
I have got to design a Java architecture as university thesis.
It's a simulation of an auction web system which receives up to 200
users concurrently and
must assure a high QoS (max 5 seconds for delivering the web page in
peak time).

If the word "assure" is used in her literal sense, I think, it is impossible
to assure a QoS in computation field. Therefore, I believe that she
should be used in the following sense:

- Best efforts toward guaranteeing a QoS.
- Exception process if the efforts fails.


With your case, an example of the implementation will be:

1) Best efforts toward guaranteeing a QoS.

While (true) {
Execute a tolerance test for concurrent requests <= 200.
If the QoS is guaranteed, break.
Execute an optimization (code, database, etc).
Consider hardware upgrade (or addition).
}


2) Exception process if the efforts fails.

While (Receive an user request) {
If concurrent requests > 200, send a busy message to the user.
Process the request.
}


#) Proof of assuring the QoS.
- By "1)", the QoS is guaranteed for requests <= 200.
- By "2)", the max concurrent requests is 200.

 

[Lew]

While (true) {
Execute a tolerance test for concurrent requests <= 200.

The point of testing for actual performance is vital. Much of your design will
be for process, not code; you need to define protocols for measurement of
runtime performance, identification of failures in QoS, and locations of the
weak points.

Be careful what you measure. Generally it is impossible to guarantee display
time to the browser, since that depends on network factors outside the
application. One can aim for, if not assure, time from receipt of request to
dispatch of response. Likewise, one can measure the latter but likely not the
former.

Your process protocols most definitely will include logging policies.

Consider statistical guarantees over absolutes. That is, aim for "response
time t for at least x % of requests" where x < 100. (Limiting variance on
service times may be very valuable.)

These sorts of definitions tend to make the problem space more approachable
and the solution able to evolve toward the most practical results.

- Lew