Archive for 二月, 2012
Apple LLVM 4.0的新特性
by Elton on 二.22, 2012, under Mac
最新的LLVM 4.0添加了几个比较有用的特性:
- @synthesize: 自动为@property添加synthesize
- 语法: 创建NSArray, NSDictionary, NSNumber的时候, 可以像NSString那样写 (下面例子解释!)
- 容器下标: 用’[]‘来访问容器(例如NSArray和NSDictionary), 就像你在第一节C语言课上学的”arr[0]“, “arr[1]“那样. 不过这个似乎是允许在’[]‘中填入字符串的(NSDictionary).
下面举例解释下第二条:
NSArray
Previously:
1 | array = [NSArray arrayWithObjects:a, b, c, nil]; |
Now:
1 | array = @[a, b, c]; |
NSDictionary
Previously:
1 | dict = [NSDictionary dictionaryWithObjects:@[o1, o2, o3] forKeys:@[k1, k2, k3]]; |
Now:
1 | dict = @{k1: o1, k2: o2, k3: o3}; |
NSNumber
Previously:
1 2 3 4 5 6 7 8 | NSNumber *number; number = [NSNumber numberWithChar:'X']; number = [NSNumber numberWithInt:12345]; number = [NSNumber numberWithUnsignedLong:12345ul]; number = [NSNumber numberWithLongLong:12345ll]; number = [NSNumber numberWithFloat:123.45f]; number = [NSNumber numberWithDouble:123.45]; number = [NSNumber numberWithBool:YES]; |
Now:
1 2 3 4 5 6 7 8 | NSNumber *number; number = @'X'; number = @12345; number = @12345ul; number = @12345ll; number = @123.45f; number = @123.45; number = @YES; |
引自:http://seymourdev.com/?p=302#more-302
Thrift简析
by Elton on 二.12, 2012, under Web
RPC技术及实现简介
首先思考一下分布式系统中的 RPC (Remote Procedure Call) 问题,一个完整的 RPC 模块需要可以分为三个层次
- 服务层(service):RPC 接口定义与实现
- 协议层(protocol):RPC 报文格式和数据编码格式
- 传输层(transport):实现底层的通信(如 socket)以及系统相关的功能(如事件循环、多线程)
在实际的大型分布式系统中,不同的服务往往会使用不同的语言来实现,所以一般的 RPC 系统会提供一种跨语言的过程调用功能,比如一段用C++实现的客户端代码可以远程调用一个用 Java 实现的服务。实现跨语言 RPC 有两种方法:
- 静态代码生成:开发者用一种中间语言(IDL,接口定义语言)来定义 RPC 的接口和数据类型,然后通过一个编译器来生成不同语言的代码(如C++, Java, Python),并由生成的代码来负责 RPC 协议层和传输层的实现。例如,服务的实现用C++,则服务端需要生成实现RPC协议和传输层的C++代码,服务层使用生成的代码来实现与客户端的通信;而如果客户端用 Python,则客户端需要生成Python代码。
- 基于“自省”的动态类型系统来实现:协议和传输层可以只用一种语言实现成一个库,但是这种语言需要关联一个具备“自省”或者反射机制的动态类型系统,对外提供其他语言的绑定,客户端和服务端通过语言绑定来使用 RPC。比如,可以考虑用 C 和 GObject 实现一个 RPC 库,然后通过 GObject 实现其他语言的绑定。
第一种方法的优点是RPC的协议层和传输层的实现不需要和某种动态类型系统(如GObject)绑定在一起,同时避免了动态类型检查和转换,程序效率比较高,但是它的缺点是要为不同语言提供不同的 RPC 协议层和传输层实现。第二种方法的主要难度在于语言绑定和通用的对象串行化机制的实现,同时也需要考虑效率的问题。
Thrift 是一个基于静态代码生成的跨语言的RPC协议栈实现,它可以生成包括C++, Java, Python, Ruby, PHP 等主流语言的代码,这些代码实现了 RPC 的协议层和传输层功能,从而让用户可以集中精力于服务的调用和实现。Cassandra 的服务访问协议是基于 Thrift 来实现的。
Thrift介绍
Thrift源于大名鼎鼎的facebook之手,在2007年facebook提交Apache基金会将Thrift作为一个开源项目,对于当时的facebook来说创造thrift是为了解决facebook系统中各系统间大数据量的传输通信以及系统之间语言环境不同需要跨平台的特性。所以thrift可以支持多种程序语言,例如: C++, C#, Cocoa, Erlang, Haskell, Java, Ocami, Perl, PHP, Python, Ruby, Smalltalk. 在多种不同的语言之间通信thrift可以作为二进制的高性能的通讯中间件,支持数据(对象)序列化和多种类型的RPC服务。Thrift适用于程序对程 序静态的数据交换,需要先确定好他的数据结构,他是完全静态化的,当数据结构发生变化时,必须重新编辑IDL文件,代码生成,再编译载入的流程,跟其他IDL工具相比较可以视为是Thrift的弱项,Thrift适用于搭建大型数据交换及存储的通用工具,对于大型系统中的内部数据传输相对于JSON和xml无论在性能、传输大小上有明显的优势。
Thrift 主要由5个部分组成:
- 类型系统以及 IDL 编译器:负责由用户给定的 IDL 文件生成相应语言的接口代码
- TProtocol:实现 RPC 的协议层,可以选择多种不同的对象串行化方式,如 JSON, Binary。
- TTransport:实现 RPC 的传输层,同样可以选择不同的传输层实现,如socket, 非阻塞的 socket, MemoryBuffer 等。
- TProcessor:作为协议层和用户提供的服务实现之间的纽带,负责调用服务实现的接口。
- TServer:聚合 TProtocol, TTransport 和 TProcessor 几个对象。
上述的这5个部件都是在 Thrift 的源代码中通过为不同语言提供库来实现的,这些库的代码在 Thrift 源码目录的 lib 目录下面,在使用 Thrift 之前需要先熟悉与自己的语言对应的库提供的接口。
Thrift 官方网站:http://thrift.apache.org
延迟加载图片的jQuery插件-Lazy Load Plugin for JQuery
by Elton on 二.11, 2012, under Javascrip
Lazy Load是一个用Javascript写得jQuery插件。它可以使一个长网页中,不在当前视图中的图片延迟加载,以提高页面的载入速度。
使用方法
在页面头部加入插件
1 2 | <script src="jquery.js" type="text/javascript"></script> <script src="jquery.lazyload.js" type="text/javascript"></script> |
在使用图片的地方,使用下面的设置
1 | <img class="lazy" src="img/grey.gif" alt="" width="640" data-original="img/example.jpg" data-pinit="registered" /> |
src是替换图片,一般使用1*1像素的图片替代。后面data-original才是真正的图片。
然后在你的代码中加入,就可以了
1 | $("img.lazy").lazyload(); |
设置延迟加载参数
1 | $("img.lazy").lazyload({ threshold : 200 }); |
这样,图片就可以在距离显示区域200像素的时候就开始预先加载。这个值可以是负值,表示提前加载。
使用特效
1 2 3 | $("img.lazy").lazyload({ effect : "fadeIn" }); |
默认延迟加载使用show方法来显示图片,可以用这个方法来改变图片的显示方法。
插件主页:http://www.appelsiini.net/projects/lazyload
Nginx使用Linux内存加速静态文件访问
by Elton on 二.05, 2012, under Linux, Web
Nginx是一个非常出色的静态资源web服务器。如果你嫌它还不够快,可以把放在磁盘中的文件,映射到内存中,减少高并发下的磁盘IO。
先做几个假设。nginx.conf中所配置站点的路径是/home/wwwroot/res,站点所对应文件原始存储路径:/opt/web/res
shell脚本非常简单,思路就是拷贝资源文件到内存中,然后在把网站的静态文件链接指向到内存中即可。具体如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 | #! /bin/bash res_path="/opt/web/res" mem_path="/dev/shm/res" lk_path="/home/wwwroot/res" if [ ! -d "$mem_path" ]; then cp -r "$res_path" "$mem_path" fi if [ ! -L "$lk_path" ]; then ln -s "$mem_path" "$lk_path" fi |
===================
更新测试数据
利用上述方法,在公司的测试服务器上做了个测试,速度提升明显,速度几乎翻倍。
测试前提:将测试网站的首页全部内容包括html,图片,js,css等所有元素都拷贝到内存中,并且每次用户请求静态资源文件都不会缓存。使用LoadRunner按照200和100并发分别进行压力测试。
测试结果:
- 在高并发下全部使用磁盘文件200人并发 2分钟 平均每次事务响应时间为19.96秒 每秒处理事务数为9.26个
使用内存200人并发 2分钟 平均每次事务响应时间为11.3秒 每秒处理事务数为15.8个 - 在低并发下全部使用磁盘文件100人并发 2分钟 平均每次事务响应时间为10.27秒 每秒处理事务数为9.32个
使用内存100人并发 2分钟 平均每次事务响应时间为5.84秒 每秒处理事务数为16.17个


