qiezi
- 浏览: 491446 次
- 性别:
- 来自: 上海
-
最新评论
-
hypercube：
markin'
配置D语言编程环境 -
qiezi：
qiezi 写道yangyang_08 写道1 ...
我的编程语言学习经历 -
qiezi：
yangyang_08 写道1、现在如果做并发服务器，楼主选用 ...
我的编程语言学习经历 -
yangyang_08：
1、现在如果做并发服务器，楼主选用什么样的语言架构？2、lua ...
我的编程语言学习经历 -
dearplain：
我也是语言爱好者，不过我一直坚持使用c。
我的编程语言学习经历
文章列表
越来越发现自己是个语言控。回想一下，上学期间除了课本里的ASM/C/SQL以外，自己业余时间学习过Basic/C++/AS，当然这些都是实际写过代码的：
Visual Basic是在Corel Draw矢量绘图软件里面编写了一个名片系统，为的是帮助一家大企业 ...
本文中提出的最佳实践，来自于作者多年大规模服务设计和部署的经验，为设计、开发对运营友好的服务提供了一系列良好的解决方案。
■ 文／James Hamilton 译／赖翥翔
引言
本文就设计和开发运营友好的服务的话题进行总结，得出一系列最佳实践。设计和部署大规模服务是一个高速发展的领域，因而随着时间的流逝，任何最佳实践集合都可能成熟并完善。我们的目的是为了帮助人们：
[list]
快速交付运营友好的服务；
避免清早电话铃声的骚扰，帮助备受运营不友好的服务侵扰的客户尽量摆脱窘境。
这篇论文是我们在过去的20年中在大规模以数据为中心的软件系统和互联网级大规模服务的智慧结晶，包括Exchan ...
Erlang 和 Stackless Python 有一定相似之处，都使用轻量级线程和消息传递（Stackless Python 当然也可以使用共享变量）。
简单例子：
# 摘自：http://www.stackless.com/wiki/Channels
import stackless
def Sending(channel):
print "sending"
channel.send("foo")
def Receiving(channel):
print "receiving"
...
- 2009-10-12 10:40
- 浏览 4663
- 评论(4)
一直以来，公司网站主要依赖于人工进行测试，不但无法保证用来监控网站功能异常，也无法进行有效的回归测试。部分频道有单元测试，但跨频道的就很难测试。
最近打算推动网站自动化测试，考察了一些开源、商业的自动化测试系统，发现功能都不是很完备，或者使用不太方便。比如我需要大量测试并行运行，需要对同一频道的每一台服务器进行绑定测试，需要模拟登录等，试用过的几个测试系统都无法完成，也没有精力测试更多了。自动化功能测试平台和单元测试框架有相似之处，所以思考如何借助单元测试框架来完成。
测试系统包括几个部分：
1、用例输入、调试系统
2、用例管理系统
3、与上线系统结合（公司的上线系统管理着每个频道的ip列表 ...
- 2009-09-27 19:28
- 浏览 3408
- 评论(0)
刚看到CSDN新闻：Intel获得Cilk++技术 多核处理器开发将变得更容易，对它本身并不感兴趣，倒是类似在C++代码中插入自己的关键字来生成代码的方式比较喜欢，不过这种方式实现成本太高了，特别是C++中。以前还有一个AspectC++，曾经也迷了一阵子，后来觉得这种旁门左道很难发展。
从Cilk++的描述来看，它是通过扩展编译器来实现，具体如何做的还不知道（正在下载，有空测试一下），这和OpenMP比较相近。这种方式缺点是太封闭，必须有大厂商来实现才好用，我更喜欢一些能够自己定制的、插件式的实现。在C++项目里比较优雅的方式，个人感觉应该是层次分明，底层（运行时、框架等）和逻辑之间关联很小 ...
- 2009-08-05 10:04
- 浏览 2708
- 评论(5)
在wikipedia上瞎逛，看一些Coroutine相关资料，找到Generator，其中的XL例子很吸引我，于是找到了它的主页（XL Programming Language）（不容易找，还有一个同名的）。简单看了一下，感觉是很有趣的一门语言。
它的特色之一是Concept Programming，最大的特色是XL语言分为3层：
XL0 定义了解析树的的文本形式
XL1 基于XL0定义了命令式语言，这些语言可以作为XL的扩展来实现，这部分我没看明白，是把XL代码通过XL编译器生成C/C++/Java这些语言的代码，还是通过这一层来实现直接在XL里解析这些语言代码？如果是后者那就更加激动 ...
- 2009-07-24 08:21
- 浏览 2060
- 评论(1)
和同事讨论了一下，觉得selective receive并非必要功能，而且容易写出低效逻辑。另外在c++中作这种匹配可能还是比较麻烦，能想到的方法有：
1、通用匹配功能，通过消息类型、流水号、发送方pid
2、通过访函数（有lambda就好了）来进行更强的匹配
不过写了点示例代码，用起来不太舒服，功能也比较鸡肋。
- 2009-07-22 11:17
- 浏览 1661
- 评论(0)
还是坚持Actor模型，从Coroutine的实现方案中也看到一些不足，虽然实现相对简单，对效率有一些影响，自动计算并发、并行的关联能力也显得不足。
开始思考基于状态机的并发实现，初步设想是对逻辑块进行代码分割，通过对函数附加一些信处来通知编译器作一些改变。貌似C++很困难。。权当是玩的吧
- 2009-07-21 13:20
- 浏览 3730
- 评论(2)
分布式轻量级线程框架（还没取名）最近几个修改：
1、消息对象采用了引用计数，T1在去年一个贴子中建议过，当时不以为然，后来发现不使用引用计数有很多麻烦，还是加上了。
2、协议buffer的管理，以前是每连接使用一个大缓冲区，对于几百上千个连接来说并不是什么问题，看到有些对外网的系统保持几万个长连接，这部分缓冲区占了上G内存。现在把它改成链式缓冲区了，缓冲区由多个PAGE链接组成，可动态增长和减少，发送接收也改成readv/writev来适应这种buffer，感觉挺好。
以下都是瞎想。
轻量级线程栈的增长问题，由于不能预估栈大小，栈的分配很麻烦。是否可以给每个线程分配较大的栈，没有使用的栈内存 ...
- 2009-07-14 16:11
- 浏览 1777
- 评论(0)
给分布式框架增加了类似 erlang 的 monitor_node 功能，前几个项目都没用到，最近可能要用到了。
还想增加 link 功能，不过跨 node 的 link 行为还不是很清楚。
- 2009-07-13 14:57
- 浏览 1832
- 评论(1)
同事测试了libcoro，它的linux版本可以使用4种模式，切换效率分别为：
asm: 50,000,000 switch/s
setjmp/longjmp: 42,000,000 switch/s
ucontext: 2,400,000 switch/s
pthread: 50,000 switch/s
asm版本保存的寄存器比较少，居然达到了5千万次每秒，可能和测试时线程数较少有关，不过也足够高了，准备再测试一下大量线程切换效率，再把现有项目换上去测试一下~
- 2009-07-13 12:07
- 浏览 2472
- 评论(0)
先比较一下Hadoop。
Hadoop 架构：
Cache Pool 架构：
Cache Server和Hadoop的Data Node是相似的，Cache Manager和Name Node对应，不过也有很多差异：
Cache Pool要承受大并发访问，且每条数据都非常小，因此不可能再做一个Name Node来保存元数据，而是使用Consistent Hashing完成数据定位。
Cache Pool数据量相对较小，一个集群几百GB左右，单台Cache Server只有4-16GB，迁移性能非常高，所以任何一个节点调整都会有1/N数据被迁移，容量约等于单台Server的容量。新 ...
前段时间开发上线了一个Cache池，使用双层Cache池冗余，宕掉一台机器的Cache失效从1/N降到1/N^2。如果2层Cache池分开机器部署，失效率将会降到0。上线不久刚好碰上一次宕机事故，效果很好。该应用有16台Cache服务器，高峰时每秒访问约20万次，平时的命中率约为99.95%，宕掉一台会给8台db造成1.25万次/秒访问（因为命中率很高所以只计算宕机造成的Cache失效率），基本上不可能承受，以往遇到此类问题时，只能干等着高峰慢慢过去、压力降下来、同时Cache命中率缓慢提高，影响时间至少4 小时以上。使用双层冗余Cache池以后，单台Cache宕机给DB造成的压力是1/256， ...
- 2009-06-15 16:10
- 浏览 4367
- 评论(4)
原打算分布式平台先使用异步编程方式来完成的，轻量级线程的实现以后再做个协议兼容的改造，后来发现现有项目的同步逻辑的代码要改成异步回调方式，改的东西太多，所以最近几星期把轻量级线程方式先实现了。测试结果还算理想，ucontext的切换效率在超过200万/秒，erlang在我测试的相同机器上非smp版本720万/秒，smp版本不到200万/秒，切换性能的确有差距，不过目前看来是足够用了。还没有去实现Lock-free的SMP版本，目前用的是线程池来跑多线程逻辑，需要多线程跑的部分只需要主动把当前轻量级线程切到线程池中，运行完那部分再切回来就可以了。IO部分把aio和event系统结合起来了，所以虽然 ...
- 2009-03-01 22:56
- 浏览 2063
- 评论(7)
上次构思了并行/分布式平台的架构，后来觉得还是有些小问题，没有解决：
* 底层组件更新问题（Erlang可以热代码升级，但没办法动态更新VM）
* 通讯底层依赖问题（Erlang也要依赖底层的稳定性）
所以对架构作了调整：
* 通讯层作为一个应用组件来提供，而不是底层平台；
* 通讯层组件作为分布式服务的发布者和远程调用代理，对它进行重启升级只是瞬时的分布式服务暂停，各服务组件不用重启，通讯层组件重启后会重新注册本地服务为分布式服务；
* 应用管理容器的角色是supervisor，它是服务的胶合者/服务定位者/服务更新的通知者，它不是路由，所以它可以自由重启升级；
这样一来，系统中各个组件都 ...
- 2008-08-27 08:56
- 浏览 2278
- 评论(0)