Dev Notes

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

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

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

1
2
3
4
5

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

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

1
2
3
4
5

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

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

来自DynaTrace’s Top 10 Performance Problems Tanken From Zappos , Monster, Thomson and Co。

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

• 请求的数据多于实际使用的数据。

• 同样的数据请求多次。

• 多次的请求一个必然的结果集

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

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

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

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

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

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

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

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

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

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

以前看的时候大多走马观花，补补课，记一笔吧。

• 对于静态内容在HTTP Header中设置过期时间和最大时间，可以有效的使浏览器避免下载已经下载过的文件。
• js,css,图片什么的都是静态内容，都应该考虑cache，但是html不是静态内容。
• Expires和Cache-Control: max-age是资源终身鲜活的Cache控制。浏览器在过期之前不进行资源的鲜活检查。
• Last-Modified 和ETag则是对资源的一种描述，属于启发式的Cache控制，浏览器在检查之后再决定使用Cache与否。
• Expires 和Cache-Control: max-age，作用相同，设置其中一个即可，Last-Modified 和Etag也是冗余的设置，设置其中一个即可。
• 设置Expires，Cache-Control支持率不及Expires。这个值通常设置1个月，不要超过1年。如果不知道过期时间，就设长一点，当发生变化的时候使用URL的指纹。
• 要考虑到代理服务器的Cache情况，使用Cache-Control的public还是private。通常来说要set-cookie的地方就不要让代理Cache，所以设置为Private。
• 代理Cache的情况还有压缩与否的问题，有两种方法，一种是把Cache-Control设置为Private，使代理服务器不Cache这些内容。另一种是设置Vary: Accept-Encoding的Header，这可以使代理Cache两种内容，压缩的与不压缩的。
• 避免Firefox的URL哈希冲突，Firefox的URL哈希算法有8个字符的冲突边界。所以两个资源的URL差异应该在8个字符以上。
• 设置正确的Vary Header，IE对于设置了Vary头的资源是不Cache的，有例外，Vary头的值是Accept-Encoding和User-Agent的时候可以被IE给Cache，所以要么不设Vary头，要么就对Vary头进行裁剪。

HTTP Keep-alive呢，重点看以下几个文档：

High Scalability有篇基于内存构建云的展望。顺手做一下笔记：

• Google的一个查询能够在200ms之内完成，其性能主要来源就是索引信息完全在内存里。数以千记的服务器处理每一个查询，以使搜索结果能立刻返回。
• Linkedin和digg都把自己的社会关系网络给塞到内存里了。
• Facebook使用了800个memcached，存储了25T的数据，并且保持了99%的cache命中率。
• 在基于内存的结构中，内存将是一套存储系统。与基于缓存的结构不同之处是，内存中的数据即是最终数据。
• 缓存系统是以最小化磁盘读取数据的瓶颈为目的，而内存系统则可以定址整个应用的栈。 数据存储在内存里比之传统方式将获得更高的可用性。
• 内存＝高带宽和低传输时间。
• 内存的带宽是5GB/s，硬盘是100MB/s。内存比硬盘快数百倍。
• 硬盘的读传输时间大约在几秒的范围之内，内存则在5纳秒之内。内存比硬盘快了2000倍。
• 内存是新的硬盘。
• 通过网络在内存中提交一个事务要比写在硬盘上快。同样的读内存也要比读硬盘快。
• 所以思想就是要跳过硬盘。
• 硬盘是新内存，内存是新缓存。50个硬盘的集群可以达到与内存相同的带宽。但是传输时间上的问题就要靠组织数据结构和优化算法实现了。

记的比较乱，大概留个映像吧。要让数据靠CPU足够近。

早晨有同事问为什么Python里的datetime模块使用strftime("%W")取出来的Week number不对呢，好象差一周。使用date "+%W"得出的结果与Python的结果是一致的。

有个同事问Python里怎么把字符串按每两个切成一个列表。给了个答案

def splitByNumber(s,n):
  for i in range(0,len(s),n):
  yield s[i:i+n]

用匿名函数可以写成一句话

splitByNumber = lambda s,n: map(lambda x: s[x:x+n],range(0,len(s),n))

结果如下

splitByNumber('fuckgfw',2)
['fu', 'ck', 'gf', 'w']
splitByNumber('fuckgfw',3)
['fuc', 'kgf', 'w']

最近写的一个东东要用python25和python-ldap，但是使用的那台主机是python23、ldap2.2.x和python-ldap2.0.1。安装了一个python25，python-ldap是2.3.8，编译失败，openldap2.2太老了，python-ldap2.3.8不向下兼容了。

设计一个group，可以包含user也可以包含group。user和group都可以被多个group包含。

class Group(models.Model):
users = models.ManyToManyField(User)
groups = models.ManyToManyField('self')

update: ManyToMany对象有一个symmetrical的参数，当为True时的意思是对象间有互相拥有的关系，是双向的，反之为False时就是单向的。

最近写一个django项目的时候犯懒，把admin的login form给简单的扒出来用了用，感觉还不错。

先把display_login_form给扒出来

对比一下FreeBSD和Linux的关于路由表Flags的定义相同的有

U   Up: The route is active.
H   Host: The route destination is a single host.
G   Gateway: Send anything for this destination on to this remote system, which will figure out from there where to send it.

FreeBSD独有的: