These are my raw notes from this event. Here mainly for me :)

Fri Mar 23 09:46:54 2007 - lightening talks

chad phillips -  delete api - 

derek wright - help with issues/cvs/tracker stuffs

allie micka - client project source management. managing drupal/module code. svn.advantagelabs.com. "svn:externals" allows 'symlinking' of other repositories in a local repo. info@advantagelabs.com

Fri Mar 23 10:09:29 2007 - state of drupal. CMSs all becoming very similar. ockham's razor will prevail. required functionality + ease of use = chosen CMS. Data API, drupal as a web service. timeframe for dropping php4 support.

Fri Mar 23 11:20:33 2007 - forms api

Fri Mar 23 14:00:12 2007 - jquery

---

Performance / Scaling Seminar

Sat Mar 24 2007

Isolating bottlenecks -

    tools:

• df -h
• w
• last
• top / top > M
• vmstate ( 1 10)
• ? sar - ongoing monitoring, prevent  problems

• cpu
• opcode
• profiling
• memory: 
• reduce maxclients
• reduce php, drupal modules that are enabled
• db / memory
• !!add memory
• faster disks, raid 0
• disk i/o
• debugging, excessive logging
• excess temp tables
• raid config
• network
• send less, use conpression
• drupal optimization
• page caching
• cron
• disable unused modules

apache/php optimization

• unnecessary modues apache
• ssi, status, 
• minimize RAM useage 
• maxclients - not enough = blocking, too many = mem hog. available RAM / httpd process size = maxclients. 
• symlinks off
• user mem/ not disks
• reduce bandwidth
• mod_gzip, mod_deflate
• mod_expires + drupal .htaccess
• alt server
• lighty much faster by default, but apache can be configured to perform the same. see dries blogpost. Allie mentioned mod to configure apache like lighty. 
• php.ini
• memory limit - max that can get away with
• opcode cache
• eaccelerator preferred by bryght, issues with php5, 
• APC
•  maintained by core developers, 
• uses mem rater than FS for cache , much faster

Architecture

• more servers + dns round robin - crude approach, no failover
• load distribution
• pound (bryght) 
• ha-proxy (lullabot)
• squid as reverse proxy
• commercial solutions generally faster
• handling static files separately
• file cache
• squid
• apache mode_cache
• ram cache
• media files
• thttpd 
• more
• separate machines
• proxy squid  / apache
• patch drupal file_url()  ??

MySQL Optimization

1. Tools
1. show status
2. show processlist
3. mytop
4. mysqlreport
2. engine
1. myisam preferred typically
1. not transactional, OS IO dependent, performance loss on large tables
2. innodb
1. can be much faster than myisam
2. auto crash recovery
3. hot backups (commercial)
4. tuning more important. out of box config will not scale. 
5. optimized for reads not writes
6. purported problems with lock contention. deadlocks. 
7. tables significantly larger. index is not compressed. more indexes means larger innodb tables. 2-5 X size of myisam. 
8. oracle owns innodb, claims good intentions, but ????
9. innodb_* vars, 
3. falcon - in development alternative to innodb, not stable. early beta q3 07. 
4. archive engine - long term, read only data.
3. Tuning
1. key_buffer size - 30/40% of available ram. all indexes should be cached ideally. 
2. table_cache - doesn't need to be as large, large enough to open tables, each connection requires its own memory. start with arbitrary 1024 then enlarge as tables are no longer cached. 
3. thread_cache - mysql preserves threads for reuse. 
4. query_cache - 
5. max_connections, wait_timeout, connect_timeout
6. idle_connections - reduce this to 15-60 seconds
4. caches
1. query cache - is byte sensetive, so case of query has effect
5. memcached
1. underutilized servers
2. anything with a lot of memory and sufficient network access. cpu/disk not important. 
3. reduces load on web / db servers
4. can cache anything, any bit of data
5. (apc also does generic memory caching but requires redundant copies on each web server)
6. memory required 4+ Meg only
7. memcached doesn't do any access checking. must be behind firewall and be locked down.
6. replication
1. after setup, modify _db_query to detect select/show and redirect to slave. . dries interested in adding this functionality to core, patch rumored to exist. 
2. master - master: not officially supported or part of design. 
3. master -> slave:  
1. ucarp
2. enable binary logging on master and slave
3. slave becomes master on first write

Dries

1. summary of existing cache within drupal. 
1. gzip
2. new aggressive page caching (drupal5). skips init() http://www.zmanda.com/and loads fewer modules. 
3. url alising - itentional. 
2. tools
1. ab
2. jmeter
3. devel module
4. cachegrind / vgrind / etc...

References:

• http://jeremy.zawodny.com/blog/archives/000034.html
• https://www.day32.com/MySQL/ - mysql optimization script
• http://danga.com/memcached/ - 
• http://pecl.php.net/package/memcache - 
• https://www.drupal.org/project/memcache - 
• https://www.zmanda.com:443/ - 
• https://jmeter.apache.org/ -