…similar solutions for addressing the scalability challenges:

On the Data Tier we see the following:

1. Adding a caching layer to take advantage of memory resources availability and reduce I/O overhead

2. Moving from a database-centric approach to partitioning, aka shards

On the Business Logic Tier:

3. Adding parallelization semantics to the application tier (e.g., MapReduce)

4. Moving to scale-out application models to achieve linear scalability

5. Moving away from the classic two-phase commit and XA for transaction processing (See: Lessons from Pat Helland: Life Beyond Distributed Transactions)

…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/06/12/its-2006-cmp-vs-bmp/ http://unmanageability.com/index.php/2006/06/12/its-2006-cmp-vs-bmp/#comments Mon, 12 Jun 2006 09:43:48 +0000 Coder http://codeperformance.com/index.php/2006/06/12/its-2006-cmp-vs-bmp/ Musings on software » Why choose cmp

…consider the strengths in performance and reduction in development that can be added by leveraging a high-quality CMP container as opposed to developing data access logic using a BMP architecture. I guarantee you’ll be happy with the results.

Excellent post! I couldn’t agree more, the debate mirrors the one around the merits and usefulness of automatic garbage collection. Sure you can manage memory yourself, but how much are you willing to pay for that vs. the performance hit you’d take in a garbage collected environment.

One issue that comes up often in this debate is the quality of the underlying SQL generated by CMP containers. The problem stems from the fact that one has very little, if any, opportunity to tune the generated SQL, and that it’s usually an all or nothing proposition. Hibernate, and to some extent Toplink, have attempted to address this but there’s still a long way to go for CMP containers to bridge this gap.

• Steve Pawlowski and Ofri Wechsler: Intel® Coreâ„¢ microarchitecture and Usages
• Paolo A. Gargini: Intel’s Silicon R&D Pipeline
• The keynotes of Pat P. Gelsinger (Digital Enterprise), Sean M. Maloney (Mobility), Donald J. MacDonald (The Digital Home) and Justin R. Rattner (Opening Keynote)

1. High Performance Throughput Computing, Dr. Marc Tremblay, Sun Fellow, Vice President, and Chief Architect, Sun’s Scalable Systems Group
2. Software and the Concurrency Revolution, Herb Sutter, Microsoft
3. Architecture Support for Parallel Programming, Dr. Kunle Olukotun, Associate Professor, Stanford University

Uniform Utilization of hardware resources ensures scalability:

• Uniform Hardware Utilization Through Time (All program Phases use the hardware uniformly)
• Uniform Utilization of Hardware Threads (All Hardware Threads are Busy)
• Uniform Use of Software Threads (There are enough threads)
• Uniform Cache Set Use in the Cache Hierarchy (No cache sets are over subscribed)
• Uniform Physical Memory Use (All memory boards used evenly)
• Uniform Virtual Memory Use (No Hot Locks)

If you want to keep producing high-performance software, you must be able to run reproducible, comparable performance tests. Ideally, you’ll have dedicated, standard hardware on which to run these tests; this should be representative of, if not directly comparable with, what your customers run in production. You’ll run a basic set of performance tests as part of your release cycle, plus more comprehensive benchmarks as required.So what should you test? What is important? You need to find a balance between the time it takes to run the tests and the information they actually give you. A large set of complex tests can tell you a huge amount about your application and even help you track down areas that have caused performance degradation, but that might be too time consuming to run for every release. Simpler tests that can run automatically in less than an hour would be better. Furthermore, your tests need to measure something using public interfaces that are stable between releases; otherwise, maintaining the tests will become an overhead.
Of course, the tests must exercise the operations and code paths that are important to your customers. They must measure the throughput of the common transactions or queries, based on the types of datasets and loadings seen on production systems. If practical, a captured production workload that can be rerun on demand would be ideal.

(Q): If you have to pick top 10 things that you must monitor on any server to look for performance and/or scalability issues…what would they be?
Richard McDougall (A): Off the top of my head, in no particular order:

1. CPU: Check idle time and run queue length.
2. If there’s a CPU bottleneck, check if it’s an application or kernel CPU utilization issue with mpstat: high percentages of users indicate it’s an application issue. High sys may point to high network load or lock contention.
3. Memory: Check MDBs memstat to ensure there is sufficient free memory
4. Network: Check that networks are not overloaded by observing the bytes xfered against the availability bandwidth per link.
5. CPU for network: check if any CPUs are 100% busy servicing network interrupts. CPUs at 100% in mpstat, or intrstat are possible candidates.
6. File system latency: check the application visible latency with DTrace at the system call level (perhaps fsstat, iosnoop, or an aggregation around system calls).
7. Storage latency: check disk latency with iostat
8. Application level lock contention: check application level locks are now visible with plockstat
9. Kernel level locks: Check for hot locks with lockstat.
10. Check MMU activity on SPARC using trapstat. Sometimes an application may be reporting as running 100% in user mode, but may actually be spending a significant amount of time in kernel mode servicing TLB misses. Trapstat will show the % of time spent using TLB misses. If a significant amount of time (>10%) is evident, then large MMU pages may help.