Oracle Enterprise Manager Java Application Diagnostic Expert (JADE) improves the availability, performance and provides in-depth diagnostics for Java applications with low overhead. It enables:

1. Production diagnostics with no application instrumentation, saving time in reproducing problems
2. Visibility into Java activity including in-flight transactions, allowing administrators to proactively identify issues rather than diagnosing after-the-fact (application hangs, crashes, memory leaks, locks)
3. Tracing of transactions from Java to Database and vice-versa, enabling faster resolution of problems that span different tiers
4. Differential heap analysis in production applications.

This is Auptyma‘s “Java Application Monitor”. It’s likely Auptyma was acquired by Oracle – its founder and CEO was previously Director of the CRM Performance Group at Oracle.

Cary Milsap, “Optimizing Oracle Performance” (O’Reilly, 2003). On p. 361, there is a definition of scalability expressed in terms of the response time (R). [ed. scalability: The rate of change of response time with respect to some specified parameter. For example, one may speak of the scalability of a query with respect to the number of rows returned, the scalability of a system with respect to the number of CPUs installed, and so on.] This stands in contrast to the way I developed my Universal Scalability Law, which is based on a kind of normalized throughput. … For those of you who haven’t seen it, here’s how it works …

…doing things an application doesn’t need to do is exactly what makes it slow, unscalable, and—in the end—economically inefficient.

1. Don’t run reports that nobody reads.
2. Don’t generate more output than you need.
3. Don’t execute a business process any more often than the business needs.
4. Don’t write SQL that visits more blocks in the database buffer cache than necessary.
5. Don’t update a column’s value to the same value it already has.
6. Push data when it’s ready instead of forcing applications to poll to see if there’s any work to do.
7. Don’t generate redo and undo when you don’t need the recoverability benefits provided by generating it.
8. Don’t parse any SQL statement that you could have pre-parsed and shared.
9. Don’t process DML one row at a time; use array fetches, bulk inserts, etc.
10. Don’t lock data any more often or for any longer than is absolutely necessary.

While I won’t pretend that the list is complete, I do believe that it should help you get into the spirit of understanding what an appropriately lean application should look like.

Technorati Tags: Oracle

]]> http://unmanageability.com/index.php/2007/10/03/attributes-of-a-scalable-data-intensive-application-2/feed/ 0 http://unmanageability.com/index.php/2006/01/23/bruce-lindsay-on-the-future-of-databases/ http://unmanageability.com/index.php/2006/01/23/bruce-lindsay-on-the-future-of-databases/#comments Mon, 23 Jan 2006 07:52:16 +0000 coder http://codeperformance.com/index.php/2006/01/23/bruce-lindsay-on-the-future-of-databases/ developerWorks : Blogs : Grady Booch

Distributed two-phase commit will be avoided by recoverable messaging to applications (via services) that consult and modify the database and send a recoverable reply. Database size will become a non-issue. We’ll see lots of low-latency asynchronous replication of reference data among databases serving various applications and their associated service interfaces.

… user authentication is a transactional event that requires fast, reliable, scalable, persistence and robust high-availability. To deliver this level of service, Google Accounts uses Berkeley DB HA for the storage and retrieval of user data and for replication, thereby ensuring scalability and availability.

…how you can monitor the database performance of your MySQL installation. Monitoring is always an iterative and continuous process. You need to learn what patterns are OK for your database and what are the signs of slight problems or even dangerous situations.Below are the main items you can use to monitor your system:

1. mysqladmin extended (absolute values)
2. mysqladmin extended -i10 -r (relative values)
3. mysqladmin processlist
4. mysql -e “show innodb status”
5. OS data. vmstat/iostat
6. MySQL error log
7. InnoDB tablespace info.

When tuning a database for better performance, one area to examine is the proximity of the database to the application. Can the database be located on the same server as the application? Will a database server located far away from the application server cause performance degradation? To answer these questions, a series of measurements were conducted to determine performance impact based on the distance between the application and database servers. This paper discusses the results of our tests.

IBM Redbooks | Local vs Remote Database Access: A Performance Test