架构师
今天在QQ群聊天，看到朋友如下说，感觉很好，特摘录：
做架构的首先是去验证这个架构是不是合理，是不是满足需要。
然后再去找相应的工具来实施。至于你用什么工具，这个就是细节了。
首先你要判断，架构是否合适，这个是道，是战略。如果架构都不合适了，那你怎么搞都是偏离了方向。
然后再从器，战术的角度去考虑如果在单点上提高。
架构师掌握的解决问题的方法，或者是思维方式，并不是具体的解决实现。
Updates from 十月, 2008 Toggle Comment Threads | 键盘快捷键
-
bixuan
-
bixuan
-
bixuan
经济危机
这种时候，我们该怎么办？
个人的想法是：
深挖洞，广积粮（多储备点现金）；
慎投资，努力工作（减少被裁的可能性）；
节约衣食住行的开销；
注意饮食穿着，养成良好的生活习惯，减少生病的可能性。确保顺利“过冬”！
-
bixuan
测试repcached
什么是repcached？
官网：http://repcached.lab.klab.org/
“repcached” is patch set which adds data replication feature to memcached 1.2.x.官网如是说。
安装配置
1. 下载：
wget -c
wget -c http://www.danga.com/memcached/dist/memcached-1.2.6.tar.gz
wget -c ‘http://downloads.sourceforge.net/repcached/memcached-1.2.6-repcached-2.1.tar.gz?modtime=1219768302&big_mirror=0′
wget -c ‘http://downloads.sourceforge.net/repcached/repcached-2.1-1.2.6.patch.gz?modtime=1219768312&big_mirror=0′2. 安装
# 要首先安装libevent
tar zxvfp libevent-1.3e.tar.gz
cd libevent-1.3e
./configure –prefix=/dfs/web/libevent
make
make instll
# 如果下面不执行，会提示找不到库的错误。
echo “/dfs/web/libevent/lib” >> /etc/ld.so.conf
ldconfig -v
cd ..# 下面开始安装memcached-repcached:
tar zxvfp memcached-1.2.6-repcached-2.1.tar.gz # 这个已经打了patch的memcached
cd memcached-1.2.6-repcached-2.1或者采用以下的方式安装:
tar zxvfp memcached-1.2.6.tar.gz
gunzip repcached-2.1-1.2.6.patch.gz
cd memcached-1.2.6
patch -p1 < ../repcached-2.1-1.2.6.patch
# 不要同时设置 –enable-replication and –enable-thread 这2个参数./configure –prefix=/dfs/web/memcached-relication –enable-replication –with-libevent=/dfs/web/libevent
make -j 16
make install3. 启动
# master
/dfs/web/memcached-relication/bin/memcached -d -m 512 -l 172.16.10.11 -u nobody -p 11211
# slave
/dfs/web/memcached-relication/bin/memcached -d -m 512 -l 172.16.10.8 -u nobody -p 11211 -x 172.16.10.11 -X 11211简单的测试了下，slave的那台启动后默认是连不上port的，而且master写key进去，slave收不到。不知道什么原因。当master宕机后，slave的port自动激活。
看来repcached还是不成熟，至少我不会用。关注ing。
-
bixuan
查看网卡pps
在linux里查看网卡pps可以通过sar命令来查看，如下：
sar -n DEV
这里看到近1天的数据：
06:10:01 AM IFACE rxpck/s txpck/s rxbyt/s txbyt/s rxcmp/s txcmp/s rxmcst/s
然后自己写个脚本做统计，主要是：rxpck/s(in) txpck/s(out)这2个值。
-
bixuan
六、性能分析
六. 性能分析
诊断问题时，第一步将问题分为五种类别：
l DNS查找时间
l 连接建立时间
l 服务器停止时间
l 传输时间
l 连接关闭时间
这些步骤的顺序总是这样的。
1 通过自己编写脚本找出瓶颈
以下指导原则可以解决可能出现的五种瓶颈：
l 如果DNS是瓶颈所在，那么可能是测试脚本指定的local dns链路不好，或者是我们的域名的DNS链路不好。
l 如果连接时间是瓶颈，则一定是网络存在问题。可能是连接建立时，由于网路设备超载而丢失了一个数据包。路由器、交换机、线缆、网卡也都可能出现问题，都应该进行检查。
l 如果服务器静止时间是瓶颈，则服务器可能会出现某种程度的超载，更换为更好的硬件或使用更加优化的服务器应用程序或数据库即可解决这个问题。
l 如果传输时间是瓶颈，则问题在于客户端连接速度太慢，或者是要传输的内容过大所致。
l 如果连接关闭是瓶颈，则仍然是网络问题。
2 查看连接
另一种了解站点情况的不错的方法是在创建和断开连接时观察连接。可以在Web服务器、中间件或者数据库的某个回路中运行netstat。
3 日志分析
3.1 平均传输大小
3.2 响应大小分布
对服务器的响应大小的分布有一些了解是十分重要的。根据响应大小的分布信息，你可以决定使用多少台服务器、每台服务器针对不同的响应大小这种方式对你是否有意义。
4 点击率
4.1 可变负载和队列长度
4.2 究竟应何时记录访问次数
4.3 谁是访问率最高的用户？
通过日志的分析，就可以很快找到访问频率最高的用户的IP地址。
4.4 哪个进程是我的？
可以用哦个lsof -i:port来识别进程，
或者fuser 80/tcp
4.5 谁在使用该文件
fuser还可以用于找出谁在使用Linux上的特定文件。fuser filename，则可以报告除所有使用该文件的pid。
4.6 我的进程正在使用哪些文件？
只需找到进程ID，然后在/proc下查找该数字即可。在/proc下，将会找到名为fd的目录，在该目录中，每个文件描述符都是到一个真实文件的符号连接。如：我的Web服务器的pid是7428，则有：
# ls -l /proc/7428/fd
total 10
lrwx—— 1 root root 64 Sep 30 21:55 0 -> /dev/null
lrwx—— 1 root root 64 Sep 30 21:55 1 -> /dev/null
lrwx—— 1 root root 64 Sep 30 21:55 2 -> /dfs/web/nginx-0.5.35/logs/error.log
lrwx—— 1 root root 64 Sep 30 21:55 3 -> /dfs/web/nginx-0.5.35/logs/error.log
lrwx—— 1 root root 64 Sep 30 21:55 4 -> /dfs/web/nginx-0.5.35/logs/acc.log
lrwx—— 1 root root 64 Sep 30 21:55 5 -> socket:[7195389]
lrwx—— 1 root root 64 Sep 30 21:55 6 -> socket:[7195392]
lrwx—— 1 root root 64 Sep 30 21:55 7 -> socket:[7195393]
lrwx—— 1 root root 64 Sep 30 21:55 8 -> socket:[7195395]
lrwx—— 1 root root 64 Sep 30 21:55 9 -> socket:[7195396]
4.7 如果数据库挂起，将会出现什么情况？
要知道这个问题的答案，可以简单的将数据库中的一个关键数据表锁住并查看在Web站点上会发生什么情况。
这样做往往会出现以下几种原因：
l 一种原因是为了查看在点击该Web站点的用户达到一定的数量后，数据库中有多少用户请求在列队等待；
l 另外，你使用这种方法来模拟一个过于繁忙的数据库，查看有何影响；
l 还可以用来检验某个特定的页面是否是依赖数据库而存在。
5 更多提示
l 获取一份清晰详尽地标明了所有服务器和连接情况的拓扑结构图。
l 首先应当考虑改变最高层（即体系结构），找到那些可以省去的步骤和机器。最低层的优化应当留到以后再做，因为从低层的优化获得的收益较小，而且在低层优化时的任何变动都有可能造成体系结构的大幅度改变。
l 最有可能产生性能问题的是“自产”的应用程序、高级别的体系结构、数据库、网络和硬盘。
l 尽量在系统上没有其他用户或进程时运行负载测试，一般可能是在晚上，这样可以发现当前配置可能的最佳性能。这有助于清楚地了解差的应用程序和系统上的过渡负载之间的差别。如果在只存在一个没有网路负载的单独用户时性能很差，那么问题可能处在应用程序上。如果性能是间歇性地变差，则应当查找应用程序处理的低效率错误。
l 监控进程的大小，以查找内存泄露。
l 使用日志文件查找错误。
l 检查物理线缆的连接，查找是否因线路纠结或接口处的问题影响性能，比如过于接近荧光灯或无线发送装置。
记住，性能问题的产生即意味着引起某处的用户的不满，成功解决性能问题则意味着使这些用户满意，其满意程度甚至会超过替他们解决所有技术问题所带来的快乐。
6 惯性建议
l 去了解一下哪些工具可用于将活动映射为PID。
l 不要过分相信日志文件的正确性。
l 记住日志文件记录的是响应完成时的时间，而不是响应开始时的时间。
-
rockysays
4.6 我的进程正在使用哪些文件？
用
lsof -p PID
应该比较方便:)
-
-
bixuan
五、负载测试
五负载测试
对Web站点进行负载测试主要有2个目的：
l 对于弄清楚站点能够处理的容量是很有用的。
l 更重要的是，负载测试可以使那些只有在重负载的情况下才会出现的bug有了“露脸”的机会，特别是那些有可能导致死锁或使站点崩溃的问题将会暴露出来。
1 负载测试前的准备工作
一个好的负责测试需要完成一些不太容易办到的准备工作：
l 需要创建测试用的用户帐号
l 数据库表和内容需要与用户生产的系统相兼容
l 用户测试的机器与用于生产的机器之间的系统参数必须同步
l 要为测试收集一组实际的URL
l 模拟客户端连接速度
其实在实际测试中，可以在正式环境中放置iframe来实际模式要上线Web系统的负载，而且这个测试是最真实有效的。
2 测试工具
2.1 同步化负载测试
2.2 随机化负责测试
3 基准规范和基准测试
我们应当对基准规范和基准测试加以区分。
4 关键性建议
l 不要花太多力气在基准上，除非他们与你想做的事紧密相关。
l 记住在生成负载的客户端增加ulimit。
-
bixuan
四、性能监控
四.性能监控
优化Web站点的首要任务就是对该站点进行监控，以便了解其模式和趋势。从监控中可以获知监控是否有助于站点。而且为监控所编写的脚本也可以用于负载测试。
性能参数
每个计算机系统都有4个传统的参数：
l 延迟
l 吞吐量
l 利用率
l 效率
优化系统性能就是要减少延迟、增加其他3个参数的值。尽管这个定义很直观，但优化本身并不直观，因为这些参数彼此之间可以互相消长，而且它们会随时间、服务内容种类已经许多其他环境改变而改变。另外，对某个机构的目标来说，有些性能参数比其他参数重要。
1 延迟和吞吐量
延迟：是指请求与开始看到结果直接的间隔时间。有人选择延迟定义为开始请求和完成该请求直接的时间。
延迟的单位是时间。
吞吐量：是指单位时间内能够处理的传输量。
计算吞吐量的简单方法：累加一段时间内的传输量，然后再将其除以这段的时间。但这样计算可能会产生正确的结果，也容易误导人，因为它忽略了在样本时间内传输速度的变化。最好是采用：每个采用点相除，然后再累加算平均值。
2 度量网络的延迟
注意这里考虑的是网络延迟，不是应用程序的延迟（应用程序的延迟是指运行在网络服务器上的应用程序本身从开始到返回结果需要花费的时间）。
因特网大部分延迟可能是路由器的存储和转发能力决定的。路由器接收一个进入的数据包，并将它放在一个缓冲区里，查看其报头信息，然后决定该数据包下一步将发往何处。即时已经决定发往何处，通常路由器仍然需要等待下一个时隙用户该数据包的发送，于是数据包的延迟在很大程度上取决于Web服务器和用户直接的路由跳数的数目。
也就是说，路由跳数的数目(hops)直接决定了网络的延迟。
那么利用traceroute功能就可以查到上文提到的hops，也可以使用mtr，mtr是结果和traceroute和ping的功能。
Hops越少约好。
Ping的延迟在50ms左右比较理想，超过100ms就不太理想了。
2.1 度量网络延迟和吞吐量
度量延迟和吞吐量最简单的方法是：弄清楚浏览器的高速缓存区的大小和从服务器获得一个特定页面所花的时间。可以使用lynx或者curl命令来获取相关数据。
比如：time lynx -source http://www.51.com/ > /dev/null，这种方法也可以认为是Web性能监控的stopwatch方法。
使用FTP
另一个度量网络吞吐量的方法是，利用FTP在本机和某个远程系统之间来回传输文件。但是使用FTP也有个不足，因为传输文件如果涉及到磁盘操作，那么这样做也是不准确的。
取消任何可能FTP传输引起的访问磁盘的请求。
必须利用大文件，因为每次小文件的创建都需要一个磁盘访问。
不过，可以利用某些版本ftp的将结果输出到/dev/null来达成结果。
ftp> get bigfile > /dev/null
其实用wget、curl等命令也是一样的，都是基于TCP的传输。但是不能清楚的区分网络性能和服务器性能。
以上也可以写成脚本来记录一段时间的运行情况，这样获得的结果会准确。
3 利用率
简单地说，利用率就是实际使用某组件的容量和该组件本身容量的百分比。数学表达式：
利用率 =
为了充分利用所花的钱，都希望组件的利用率为100%，但是实际上并不必须如此。因为当利用率太高时就会出现很大的延迟。就经验而言，许多组件在利用率约为70%时性能最好。
perfmeter工具为监控系统利用率提供了一种很好的图形界面。
4 有效性
有效性 =
（作为比较组件的一个基本方面是有用的，但在其他方面并没有多大用处，因为它仅仅是由其他两个性能参数相除得的结果）
一种更有用的有效性度量是计算单位开销获得的性能，这通常叫成本效率（cost efficiency）。
优化性能就是增加成本效率的艺术，即充分利用所花的每一分钱。实际上，因特网本身所具有的流行性就说明了这样一个事实。比如：email的延迟吞吐量比传统的邮递要快，成本低。
成本效率（cost efficiency）= 单位开销所得的性能
5 使用脚本监控Web性能
面对的庞大的Web数据，如果手动来监控Web性能显然是不可能的，所以这里势必促使我们使用脚本自动来实现，不然perl，python，php，shell等工具。
这里的监控是自动模拟用户登陆的行为，然后记录下各个操作点时间。
通过监控获取日志，然后对日志进行分析，这样就可以得出相关的报表。当然日志也可以保存在数据库里。
注意：过渡的监控对Web站点的运行同样有害！
6 关键性建议
l 不要太依赖基准，除非这些基准与你实际想做的密切相关。
l 不仅监控服务器的负载，而且监控实际的Web性能，并作记录。
l 不要进行过多的监控，否则你将成为制造问题的一份子。
DallWhiliasum is discussing. 
rockysays is discussing. 
DallWhiliasum 15:31 on 2009 年 11 月 14 日 链接地址
I found this site using google.com And i want to thank you for your work. You have done really very good site. Great work, great site! Thank you!
Sorry for offtopic