上周六(2009.03.21)河北张家口万龙滑雪。
会长的几句点拨，终于让我摆脱了自由落体般的垂直滑落，登上了万龙顶峰。
能自由控制速度，掌握节奏后，滑雪就变的很轻松，山顶上雪花飘舞，需要做的只是，尽情的享受着雪中飞翔带来的快感。

 滑雪是一种有挑战和成就感的运动，推荐给所有真正的男人。

今天,我开发的一系列系统中的两个 并发达到54.15w req/s , connections 340.25w  高峰一小时近20亿实际http请求处理量。 这个量只在奥运的时候有过，记录下，留个纪念。 这只达到了我设计容量的1/3 ，希望用户量增加的更凶猛一些，好校验一下我的想法。

--提升性能的同时为你节约10倍以上成本
From: http://blog.sina.com.cn/iyangjian

一，自选股分析
二，NBA比赛分析
三，播客分析
四，开心网分析
-----------------------------------------------------------------------------------------

下面的图片都是在教育网访问的情况，我故意放大了某些缺陷，这样可以很好的模拟没有部署服务的地区对用户体验的影响。我只能针对我熟悉和了解的项目进行分析，另外还有我们经常访问的网站也会被拿来做素材分析。我们老大也说问题暴露出来，能推动解决的话也很好，大家别拍我。

一，自选股分析


某天我终于在教育网部署了一台行情服务，兴致冲冲的回家一试，貌似没啥变化，该慢还慢。打开页面过程持续了几十秒，然后终于露出了行情，我

--提升性能的同时为你节约10倍以上成本
From: http://blog.sina.com.cn/iyangjian

一，Cache， 王道也
二，Cache 基本原理介绍
三，我划分的３个刷新级别
四，我对HTTP协议做的一点创新(?maxage=6000000)
五，Yslow优化网站性能的14条军规点评
六，上线了 !=  Finished
七，提速度同时节约成本方法汇总
-----------------------------------------------------------------------------------------

一，Cache，王道也

我觉得系统架构不应该仅仅是搭建一个强硬的能承受巨大并发压力的后台，前端页面也是需要架构的而且同等重要，不理解前台的的后台工程师是不合格的。中国人讲究钢柔相济，后台强硬只能说你内功深厚，前端用的巧，那叫四两拨千斤。

一般后台工程师很少关心前端如何使用自己的资源，而前端工程师，不知道自己的一个简单的用法会对后端造成多大影响。我会给出一些数据，来震撼下你的眼球。

二，Cache 基本原理介绍 (参考

--提升性能的同时为你节约10倍以上成本
From: http://blog.sina.com.cn/iyangjian

一，系统部署（高并发,可扩展）
二，负载均衡LVS（高可用,低成本）
三，IDC分布，DNS解析（快速）
-----------------------------------------------------------------------------------------

一，系统部署（高并发,可扩展）

本来想画在手稿上然后扫描上去的，貌似方法太土，在朋友的帮助下费了n个小时用Visio画了个，感觉很好看 ^-^ 。这一篇将主要围绕这个图来讲述。



首先从数据源说起，所谓狡兔三窟，我们数据源也是按三路设计，以保证IDC内部和不同IDC之间实现灾备。源头转发机A,B,C拥有往集群中任何一台服务器同步数据的权限，所以他们三个有一个活着，数据就可以同步更新,而且可以自

--提升性能的同时为你节约10倍以上成本
From: http://blog.sina.com.cn/iyangjian


七，NBA js直播的发展历程

这一节就谈下这个项目发展过程中所遇到的瓶颈，以及如何解决的。
应该是06年吧，当时NBA 比赛比较火,woocall负责高速模式图文直播放，普通模式和动态比分数据等都放在一群破服务器上，大概有十几20台，这些破服务器有些扛不住了。

因为第二天有一场比较大的比赛，我想埋连接在线上测一下效果，于是连夜把财经实时行情server改写成了NBA JS直播server. 当时有两台 Intel(R) Xeon(TM) CPU 3.00GHz 双cpu的服务器，在F5后面。先启用一台服务器，比赛开始前静悄悄的，不一会，迅速串到了20w connections，再往上增长，就慢的几乎不可访问， ethtool eth0  , Speed: 100Mb/s, 网卡出口带宽跑满了（那时候支持千兆的交换机还不多）。迅速把另一台服务器启用，后来又卡了，好象是F5处理能力不足。 后来升级服务器出口带宽为1G，当然这需要交换机支持千兆口，更换网线，服务器也从F5后面转移出来，通过DNS直接轮询。

后来又测试了几次，等到新申请的

--提升性能的同时为你节约10倍以上成本
From: http://blog.sina.com.cn/iyangjian

一，如何节约CPU
二，怎样使用内存
三，减少磁盘I/O
四，优化你的网卡
五，调整内核参数
六，衡量Web Server的性能指标
七，NBA js直播的发展历程
八，新浪财经实时行情系统的历史遗留问题 (7 byte = 10.68w RMB/year)
  -----------------------------------------------------------------------------------------

一，如何节约CPU

1,选择一个好的I/O模型(epoll, kqueue)
3年前，我们还关心c10k问题，随着硬件性能的提升，那已经不成问题，但如果想让PIII 900服务器支撑5w+ connections,还是需要些能耐的。

epoll最擅长的事情是监视大量闲散连接，批量返回可用描述符,这让单机支撑百万connections成为可能。linux 2.6以上开始支持epoll，freebsd上相应的有kqueue，不过我个人偏爱linux，不太关心kqueue。

边缘触发ET 和 水平触发LT 的选择：
早期的文档

--提升性能的同时为你节约10倍以上成本
From: http://blog.sina.com.cn/iyangjian

从基本HTTP协议，服务器编写(只讲思路)，到完整系统搭建(包括负载均衡LVS，IDC分布，DNS解析)，到浏览器缓存的使用(重点讲述)，结合线上实例图文讲解如何以最低廉的成本构建快速，高并发，高可用，可扩展的Web服务。最后将拿本公司一些线上产品做实例分析。

如果能灵活应用这些方法，你也许会发现对于某些网站来说节约10倍成本，其实是个很保守的说法。

提纲：
一，服务器编写篇
二，系统架构篇
三，Cache为王篇
四，实例分析篇

注：本blog所提及的内容并不保证完全正确，若有疏漏，欢迎批评指正。

近年来一直为知识产权的问题所困饶。
也在为技术共享和封闭所困饶。
这几天参加sd2c大会，有幸结识了一些朋友，通过交流，我觉得还是有方法可以实现双赢的。

由于某些个人原因，我离开了曾经工作过三年的财经项目组。
按照我们公司规定，所有在线服务都要提交源代码，而且要做人员备份。
对此我并不反对，在2008.12.01那天我也毫无保留的提交了当时最新代码。
不过只允许极少数人有权限检出，公司难免人员流动，落到竞争对手那里毕竟不是太好。

不过，我觉得这不能很好的保护个人知识产权，抑制了个人创新的积极性。
说实在的，那些代码虽然不多，也许别人觉得不值什么，但确实花费了我不少心血。
我在核心部分的平均每天的代码量不足十行,有时候三五行代码可能要持续一个月去跟踪,甚至睡觉前都一直在想着怎么去实现。


这最初也就是我的一个业余项目，（一开始我提出要为公司开发一个全新的高效服务器的时候，被否决了），所以我也当做个人兴趣做着玩，后来在一个不太重要的项目上应用了，效果不错，才得以推广。
不过还是很感谢公司能给我一个大访问量，高并发的平台，让我