Skip to main content

Notes from Tuesday morning Jazoon

Posted by haroldcarr on June 23, 2009 at 5:29 AM PDT

Here are my notes from the Tuesday morning at

Tuesday morning June 23, 2009

Why Applications Don't Scale
Alois Reitbauer, dynaTrace Software

Scalability: Increased resources results in increased performance
- Werner Vogels

- Can ensure performance with increasing load

- characteristics like response time, processing volume..

Queuing Theory
- Modeling resource
- Resources and waiting requests are modeled as queues
- EX: CPU and current requests

Queuing Networks
- Modeling of app as network of resources
- Combing multiple queues
- EX: CPU, Network, Connections Pools, Servlet Threads

Scalability and Requirements
- Increasing number of parallel requests
- Increasing number of parallel users
- Increasing number of data
- Increasing availability with same performance

Types of Scalability
- Vertical (UP)
  A physical node gets more resources (CPU or memory)
  In virtual env "on demand"
- Horizontal (OUT)
  A new physical node is added
  Trends to more and more servers
  Distributed system

If system is fast in single user mode but slow under havey load then
the problem is scalability, not performance
- Cameron Purdy

Scalability does not improve performance
- Increases complexity and degrades performance
- Slower in single user mode
- performance is still an issue

Scalability can improve availability
- Scale out introduces redundance
- Synchronize status/state

Scalability never comes for free
- Must be engineered into the application
- Introduces additional complexity
- Plan time for building scalability into app

Limiting factors
- CPU Time
  scalability via hardware
- Memory consumption
  scalability via hardware
- I/O and Network
  limited and harder to scale
  architectural changes
- shared resource access
  limited and harder to scale
  architectural changes

Major problems
- Database access
  high number of database requests
  Locks and concurrent access
- Remoting Behavior
  Bad interaction design (communication patterns)
  High data volume
  (it's too easy to make remote calls)
- Locking
  Configuration problems (Connections Pools)
  Wrong synchronization patterns
  Serial data access

- Throughput
- Response times
  vs CPU time
- System metrics
  CPU and Garbage Collection
  Memory pools (including generations)
- Application metrics
  connections pools
  component level
  Transactional trace data

- Complex interdependencies due to frameworks
- High serialization
- Full heap due to memory leak
- Inefficient or redundant remote calls
- Too many SQL calls

Database access
- Wrong use of O/R mappers
  Configuration/Loading behavior
- Bad Transaction Design
  Connection kept too long
  Isolation level incorrectly defined (or not at all)
- Inefficient data loading logic

Distributed Systems/Remoting
- Bad interface design
  Interfaces are too generic
  Interactions not suitable for SOA
- Wrong communication protocols
  SOAP services in homogeneous landscape
  Sync instead of async interactions

- Locks kept too long
- wrong lock granularity
- Neglecting locking at DB level

Serial access
- Access MUST be handled in serial way
- Scalability logically limited

Too much synchronous program logic
- Developer think procedurally
- Sync interaction in distributed systems is problematic
- high resource usage
- typical indicator: low CPU while other resources saturated
- class ex: web apps

Memory management
- Bad GC Config
  Generation size; collection strategy
- Unnecessary creation of objects
  O/R mapping frameworks
- Memory leaks
  Bad reference clearing logic

Problems in development
- Don't understand dynamic program behavior
- Sacrifice functionality over scalability and performance
- Waiting for symptoms
- Real problems often only visible under high load

- tools: jimmi, selenium, sniffer, soapUI,
- check DB and/or remoting at continuous integration time

Design Patterns in Dynamic Languages
Neal Ford, ThoughtWorks

slides from (same talk at JavaOne 2009)
samples from

Pattern solutions from weaker languages
have more elegant solution in dynamic languages

Many patterns in _Design Patterns_ are just bandaids to C++ deficiencies.

Patterns define common problems
Dynamic languages give you better tools to solve those problems


- Now Java has foreach
- .each in groovy and ruby

- via closures

- See: "Execution in the Kingdom of Nouns" - Steve Yegge

- code blocks as placeholders

- build DSL using dyn language features
- EX: Groovy expando metaclass
- internal DSL == embedded interpreter
- because language is powerful enough to build language on top

Pattern: type transmogrification
- transform types as needed as part of a fluent interface call

- See: groovy .invokeMethod
- Decorate in place: add new method to instance of class

- round hole/square peg
- no need for extra adaptor class - dynamically add method
- but what if new method conflicts with existing method : InterfaceSwitching
  like DCOM


Null Object
- Groovy:  <reference>?.<method>
- Ruby: NilClass already defined
  Can add new methods to NilClass

- From _Pragmatic Programmer_: DRY: Don't Repeat Yourself

Traditional languages rely on structure for solutions
Related Topics >>