WEB开发性能随笔

目标：
开发高性能，可扩展的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

评论

1 楼 fast 2010-03-24  

.事物--事务