File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Performance and the fly likes High Load application - design not scalable Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Performance
Bookmark "High Load application - design not scalable" Watch "High Load application - design not scalable" New topic

High Load application - design not scalable

P B Madhavan

Joined: Dec 23, 2009
Posts: 5
Hi All,

I have inherited a poorly performing application running on JBOSS

The application has been designed in a way that all of the business logic is in the DB layer. The application therefore runs insanely complex SQL queries.

This results in ridiculous performance latencies from the user perspective.

I know it is due for an overhaul of design. To temporarily alleviate performance issue, I am thinking of introducing another application server instance (if required on a different machine) - this would function as a batch server.

I intent do identify the most DB intensive online enquiries and try to convert them as batch processes.

The high level approach is as follows

1) When a user wishes to execute a very DB intensive enquiry - Store the request into a DB table

2) Run a batch process on the newly introduced batch application server instance that runs every 5 minutes to pick up the request and email the query output as EMAIL.

Please advice if this approach makes sense. Any further input/ideas would be greatly appreciated.

Deepak Bala

Joined: Feb 24, 2006
Posts: 6662

Your users are actually ok with this idea ? If it were me I would ask the team why an email is sent for every operation when it was supposed to be updated on the web page. What if the email server is down ? How do you handle that ? What if the user is not in a position to check email ?

Try to analyze why the queries take so long. Optimize if possible. Moving to a batch system will take more or less the same time but perhaps you could update other parts of your web app instead of sending an email.

I have no clue what your application does so take this with a grain of salt. Your ideas may actually make sense but it is hard to know. As a short term solution however, I would definitely look at tuning the queries first before affecting user experience. Changing user experience is a last resort.

SCJP 6 articles - SCJP 5/6 mock exams - More SCJP Mocks
William Brogden
Author and all-around good cowpoke

Joined: Mar 22, 2000
Posts: 13036
What kind of usage does this application get?

1. Are people changing the database content all the time or is the DB changed infrequently?
2. Where does the DB server live?
3. Are queries being duplicated or are all queries unique.

Peter Johnson

Joined: May 14, 2008
Posts: 5852

Your database should provide tools to evaluate the SQL statements and identify poorly performing statements. Many such tools can even provide suggestions to improve performance. Having complex SQL is not a problem, having poorly written SQL or poorly designed tables is. Hey, you might find out that all you really need is another index or two (ask me how many times doing just that has dramatically improved performance on our databases).

By the way, which data is it?

JBoss In Action
Ireneusz Kordal
Ranch Hand

Joined: Jun 21, 2008
Posts: 423
P B Madhavan wrote:Hi All,
Please advice if this approach makes sense. Any further input/ideas would be greatly appreciated.

Similar approach works in our application - there is a security policy that after 15 min. of inactivity force an invalidation of user's session
- and because of this policy user can never get results of long running reports/queries
(he clicks on link ... and cannot do anything because must wait for results from the server, but after 15 min. the session timeouts).
For these long running reports there is a special function implemented called 'batch reports' - with this function
user can 'order' the report - he specifies query criteria (various tables/fields), then the order is saved in the database,
and at night, when system is not loaded, these reports are executed and results are saved.
In the morning user checks the status of his 'order', and if report is ready - clicks and displays results (or import data to the spreadsheet).
I agree. Here's the link:
subject: High Load application - design not scalable
jQuery in Action, 3rd edition