July 2010 Archives

• 日均访问量(Vistors/Day)：873.71 Visits / Day
• 日均PV：3000
• 平均停留时间：00:03:42

• 浏览器的前三是：
  1. Internet Explorer(33.95%)
  1. 8.0(45.98%)
  2. 6.0(34.74%)
  3. 7.0(19.25%)
  2. Firefox(33.68%)
  3. Chrome(25.61%)
• 操作系统的排名前三是
  1. Windows(82.18%)
  1. XP(69.32%)
  2. 7(24.08%)
  3. Server 2003(3.27%)
  2. Linux(14.13%)
  3. Macintosh(3.22%)
  1. Intel 10.6(87.83%)
  2. Intel 10.5(10.79%)

• 取字符串的长度：${#VAR}

# a="HelloWorld"
# echo ${#a}
10

• 字符串截断：${VAR:POSITION}或${VAR:POSITION:LENGTH}

# a="HelloWorld"
# echo ${a:5}
World
# echo ${a:4:3}
oWo

• 字符串匹配取最短：${VAR#SUBSTRING}和${VAR%SUBSTRING}

# a="HelloWorld"
# echo ${a#*o}
World
# echo ${a%o*}
HelloW

注：#是从前向后，并且*号是紧随着的，而%则是从后向前匹配。*号是放在最后的。

• 字符串匹配取最长：${VAR#SUBSTRING}和${VAR%SUBSTRING}

# a="HelloWorld"
# echo ${a#*o}
rld
# echo ${a%o*}
Hell

• 字符串替换：${VAR//PATTERN/REPLACEMENT}

# a="HelloWorld"
# echo ${a//World/Earth}
HelloEarth

• 确定匹配位置：expr STRING : REGEX

# a="HelloWorld"
# expr $a : ".*o"
7

注：这里的REGEX从名字上就说明了是一个正则表达式。

Update：详细请参考

• Advanced Bash-Scripting Guide: Table B-5. String Operations
• The Geek Stuff: Bash String Manipulation Examples - Length, Substring, Find and Replace

• 革新的步调----革新的步调正在加快。高度关注基础设施的革新可以降低成本、增加可靠性并且减少资源的消费，最终的目的就是降低成本。
• 钱都花哪儿了？----
  • 54%花在服务器上，8%花在网络上，21%花在配电上，13%在电力上还有5%花在其他的基础设施上了。
  • 34%的成本与电力有关。
  • 电力成本有上升的趋势。
• 云效率----服务器的使用率在咱们的工业里是10%到15%。
  • 避免在基础设施中使用漏洞。
  • 把工作拆成小份，并且尽可能的将他们排入队列。
• 配电----11%到12%的电力消耗在了配电的过程中。一些最小化电力消耗的规则
  • 把电力都卖出去，只要电力允许就放置更多的服务器。
  • 避免使用变压器。
  • 增加电力转换的效率。
  • 高压越接近负载越好。
  • 使用效率高的电压整流设备。
  • 高压直流是一个小的潜在利益。
• 机械系统----一个可以节省空调的环节。
  • 什么是可以被改进的？冷却塔，热交换，泵，蒸发器，压缩机，冷凝机等。
  • 上述这些系统的效率取决于对不同温度的需求。
  • 冷热系统分离
  • 增加服务器的运行温度。
    • 通常在61到84
    • 电信标准是104F(40C)，游戏行业要更高一些。
• 温度
• 限制到高温运行的因素
• 避免整体直接澎涨冷却
• 过滤微粒和化学污染
• 网络安排
  目前的网络是超订了
  • 强制放置有序
  • 目标：所有点到数据中心的距离是一致的。

1. 太多的数据库请求

在一个请求或事务中数据库请求太多。具体有三种现象：

• 请求的数据多于实际使用的数据。
• 同样的数据请求多次。
• 多次的请求一个必然的结果集
2. 同步走向死亡

同步是一种保护共享数据的重要机制。但是过度的代码同步就会引发性能问题，这种问题在单机的时候并不明显，但是在一个高负载的环境下就难以持续了，最终的结果就是死亡。如何确定同步问题，可以把程序的CPU时间和总体执行时间在递增负载环境下做测试对比，就会发现CPU时间几乎是一定的，但是总体执行时间是随负载增加而快速增涨的，那就是说这个程序在同步上是有问题的。

3. 过多的远程调用

许多的库都是一些远程调用，对于程序员来说，本地调用和远程调用在程序上并无差别。但是不要忘记了远程调用的额外成本，比如：传输时间、序列化、网络流量以及内存使用等等。

4. 错误的使用ORM

ORM从开发人员手里接过了载入和存储数据的重担。ORM的框架一般都有许多的设置以供优化，在使用时候如果使用了错误的设置，就会导致一些不可预见的性能问题。所以在使用框架的时候对于其设置项要真正的了解其内部的工作方式。

5. 内存泄漏

垃圾回收并不能阻止内存泄漏，所以尽可能快的释放对象引用是非常重要的。

6. 成问题的第三方代码或组件

代码是人写的，是人写的就会有问题，但是问题有多有少。所以在引入第三方代码或组件的时候最好是深入检查一下，以免从A产品的开发人员演变成B组件的捉虫队。

7. 贪婪的占用稀缺资源

像内存、CPU、I/O、数据库啥的都是稀缺资源，所以就别占着矛坑不拉屎（这也是人品中重要的一项，我相信一个人品好的人写代码的时候也会这么做。）。

8. 肥胖的前端

太肥的东西总是要避免的，不管是吃、看还是用。

9. 错误的缓存策略导致额外的垃圾回收

缓存对象到内存是为了避免重复的数据库请求。但是如果把太多的数据都缓存到内存或是数据对象是频繁被更新的，那这样的缓存策略带来的问题就是要做更多的垃圾回收工作。

10. 间断性的问题

这种问题较难发现，通常出现在特别的输入或是某个确定的负载情况下。这只能是尽可能的做全面的测试，从功能到负载和性能都覆盖到，这样就尽可能早的把这种给问题给揪出来，从而不影响到真实用户。

11. （额外送的）昂贵的序列化

在现在的Web应用中序列化随处可见，REST大行其道，数据对象要序列化之后再通过接口才能送出去。有序列化就有反序列化，这种开销是对称的，所以要尽可能快速的处理这两个问题，而且还要考虑到其序列化后数据的大小，内存占用等问题。