目标：
开发高性能，可扩展的WEB应用。
1.WEB应用的分层
a.前端
b.后端
a.前端优化的重要性。分析工具GA和YSLOW
1.一个request之前要做的优化。
2.不要紧盯WEB后端优化。尽可能的访问服务器之前，消灭掉request.
前端优化的方法
1.减少http请求。
方法：合并图片：使用CSS或者HTML的MAP标签来定位。
合并脚本和样式表：视情况而定。同一功能的耦合在一个脚本发布。如果是landing page和index页可以考虑使用内联脚 本和CSS的方法
2.缓存图片和脚本.
方法：再web服务器设置Expires头。据统计大概60%以上用户带有完整缓存。要做的就是发布JS，CSS之类的脚本要带有版本号。 应对及时更新。
3.压缩一些组件。
方法：压缩的是XML,JSON。不要压缩图片。图片应该由本身格式来压缩优化如PNG,GIF,JPG。APACHE1.x和2.x配置不同。
4.样式表的位置。
方法：尽可能的放在顶部。LINK要放到HEAD之中，不要使用@import.可能还会最后下载。
5.js脚本放在底部
方法：尽可能的放在底部。视情况而定，有些js控制显示的要放在上面了。增加并行下载的能力。视CPU和带宽来决定。
6.使用外部的CSS和JS
方法：方便缓存。合并压缩CSS.工具有JSMIN和YUI COMPRESSOR。首页和着陆页使用内联较好。
前端技术推荐：CSS框架 960GRID网格展示和JS框架JQUERY。（浏览器兼容性佳）。
b.后端优化。（Java）
本质：web服务器的集群-》分布式缓存-》数据库集群。
1.WEB服务器集群：
选择：nginx,apache,lighttpd 线程模型。
apache：稳定。多进程开销大，并发处理能力低。相对安全。子进程崩溃不影响其他的进程。并发数100左右可以考虑。
高性能推荐：nginx.普及门户高稳定性 介于apache和lighttpd之间。CPU内存占用非常之低。高并发APACHE线程过多导致死掉，只能重启。。lighttpd图片服务器。
使用情况：
nginx:163,renren,douban,sina，qq 版本各异。。。
lighttpd:未知。flickr图片服务器。早期豆瓣。
apache:很多了。
负载均衡：DNS.HAPROXY 4层负载。
2.分布式缓存
没什么疑问了 当下最流行memcached.客户端分布式。设计缓存一定要注意的是缓存是不可靠的。命中率的问题。缓存的扩展为key的md5(十六进制字符串)加密。截取前5位转 十进制，然后取余数。% 值就是服务器编号。
3.数据库(MySQL)
最终思想为读写分离。选择合适的存储引擎（MyISAM,INNODB）。索引的优化。
存储引擎：
选择合适的存储引擎需要如下考虑：1事物。2.并发。
1.事务，如果支持事务的话，不用考虑了直接使用innodb.
2.并发，多查询少写入。最好为MyISAM.多写入多查询那种。适合Innodb。因为Innodb本身是行锁。批量更新。多查询还是MyISAM。
对经常查询的数据库加上缓存设置。线程池的优化。
索引：
1.多查询的表 要加索引。同样的索引带来的副作用就是插入更新的缓慢。再就是占用硬盘空间。
2.要注意索引的顺序。比如 firstname加索引 lastname没有加。如果 lastname在firstname之前索引就失效。
3.要把列单独隔离，不要对列进行操作。如where DATE_FOMAT(reportdate)=?
又出现一个问题。如何避免JOIN查询。
非范式化。KEY-VALUE.数据库。最近研究couchdb apache ab -n1000 -c200 request/s 2590.无优化。优点JSON。直接返回JSON。
MySQL方案。。存储过程+shell
其他选择memcachedb.（memcached协议+伯克利DB），MongoDB。是对关系型数据库的一个弥补。
主从复制+MySQL Proxy 。或者 水平分区。userid%10 垂直分区 。不相关的分库。。Spock Proxy。HiveDB