Here are my notes from the Tuesday morning at jazoon.com

==============================================================================
Tuesday morning June 23, 2009

------------------------------------------------------------------------------
Why Applications Don't Scale
Alois Reitbauer, dynaTrace Software

blog.dynatrace.com
blog.codecentric.com
highscalability.com

Scalability: Increased resources results in increased performance
- Werner Vogels

Scalability
- Can ensure performance with increasing load

Performance
- 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

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

Problems:
- 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

Synchronization
- 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
  Serialization
  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

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

------------------------------------------------------------------------------
Design Patterns in Dynamic Languages
Neal Ford, ThoughtWorks

slides from nealford.com (same talk at JavaOne 2009)
samples from github.com/nealford

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

_DESIGN PATTERNS_ PATTERNS

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

Command
- via closures

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

Template
- code blocks as placeholders

Interpreter
- 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

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

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

DYNAMIC LANGUAGE PATTERNS

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

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

Traditional languages rely on structure for solutions