windows media 有 simulator 进行压力测试, 现在介绍如何使用helixapp real simulator 测试helix server的并发能力

摘要:(本文带有一定行业性，为流媒体CDN内容分发网络的范畴) http://blog.lmtw.com/b/peon/archives/2006/39714.html 虽然张翠山已死，但是江湖上的传言愈来愈烈，都说武当派已经得到了屠龙宝刀，而且已经参透了刀中的秘密。张三丰宋远桥对这种谣言自然是嗤之以鼻。来滋事的自然不少，以武当六侠之能全部轻松打发，可是慕名而来的求教者越来越多，有一些资质品德都算不错的人，六侠将之收为门徒，眼下门徒数量越来越多，别说授徒，六侠和宋青书的日常事务也日益繁忙了。      张三丰为此专门开了个会，决定今后六侠处理日常事务和进行研发新的武艺，名义上，张三丰统一教授所有第三代和第4代弟子的武艺 ，弟子有什么问题，可以写纸条给张三丰，或者向www.张三丰.com查询，实际上的武艺教授由宋青书和一些第三代弟子中的佼佼者负责，成立一个武馆，专门负责解答武学问题。     每天，宋青书和其他教师处理给张三丰的纸条和WEB请求，每天都有大量的纸条和WEB查询，宋青书一个人是绝对处理不来的，宋青书检测所有教师的状态，把请求给懂得该问题(拥有请求内容)并且负载最轻的教师处理。     这里，宋青书和其他教师形成了一个本地负载均衡的集群。负载均衡（Load Balance）将大量的并发访问或数据流量分担到多台节点设备上分别处理，减少用户等待响应的时间提高处理能力，负载均衡建立在现有网络结构之上，它提供了一种廉价、有效、透明的方法，来扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。本地负载均衡是指对本地的服务器群做负载均衡，能有效地解决数据流量过大、网络负荷过重的问题，并且不需花费昂贵开支购置性能卓越的服务器，可充分利用现有设备，避免服务器单点故障造成数据流量的损失。    开始的时候，武当派的光大武学的事业进行的很好，随着武当山的弟子继续增加，武当山在山下开了一些别院，求教的弟子络绎不绝。现在不是宋青书他们的武馆忙不过来，反正学生多了多弄老师就行，而是山路变得拥挤起来，而且大多数学生抱怨来回就要一天，严重影响学武效率。 这里，通过的集群服务器(宋青书和许多老师)做本地负载平衡，很好的解决了大量请求的负载问题，但是出现了以下的问题：消耗大量的骨干带宽(山路拥挤不堪)，用户请求网络距离太远，反应缓慢(请教个问题来回要一天)。        武当诸侠也意识到了这个问题，于是就在山下的别院成立了分馆，由别院的一些优秀弟子充当其他弟子的教师。这些别院的信息分中心直接就挂张三丰的名号，www.张三丰.com的牌子也是挂得相当响亮，相应的路标也指好了。山北的弟子顺着路标找张三丰，就自然跑到山北的武馆，山南的弟子则会找到山南的武馆。每个武馆都有门房，根据请教的内容，告知学武者应该找的老师的房间号。学武者自己去找该老师解答问题。    这里为了武当派为了解决响应速度和骨干带宽的问题，引入了全局负载均衡(Global Server Load Balance 有时称为地域负载均衡)，把各地的用户对于资源的访问，根据内容有无，服务器负载，网络带宽和速度，将请求导向到不同的服务器集群进行服务。    这里武当派采取的全局负载均衡策略相当于Internet的智能DNS+内容重定向的方法。    智能DNS: 对于资源访问，采用统一的域名，但是智能DNS根据地域，分别指向边缘服务器进行服务(山北的的路标指到山北武馆，山南的指到山南)。但是智能DNS有粒度太粗的问题，智能DNS服务器无法判断边缘服务器是否拥有该内容，边缘服务器是否健康是否有足够的能力服务。所以常常需要和其他方式配合，比如4/7层交换和内容重定向。 <    内容重定向(可以参考"武当学艺之反向代理"一文)：对于访问请求，有一个内容路由服务器(相当于武馆的门房)信息通过一定的内容导向策略(一般是就近和负载最轻原则)，将其分配给合适的缓存服务器进行服务。重定向需要应用层协议的支持,而且往往有一定的限制，但是可以做的非常的灵活,达到最好的效果。 (后面的文章应该到了介绍PUSH/PULL的分发技术了)...[阅读全文]

摘要: 主要阐述helix server的安装使用和一些技巧 http://www.helixapp.com/down/view_26.html...[阅读全文]

摘要:http://blog.lmtw.com/b/peon/archives/2006/39703.html 对于CDN的内容管理，有一个基本定律，就是大家常说对于内容的访问遵循80/20原则，也就是20%的内容，会占有80%的访问量。 这是一个定性的原则，定量来说，内容访问近似符合Zipf定律(Zipf's law), 这个定律是美国语言学家Zipf发现的，他在1932年研究英文单词的出现频率时，发现如果把单词频率从高到低的次序排列，每个单词出现频率和它的符号访问排名存在简单反比关系： 这里 r 表示一个单词的出现频率的排名，P(r)表示排名为r的单词的出现频率. (单词频率分布中 C约等于0.1, a约等于1) 后人将这个分布称为齐夫分布，这个分布是一个统计型的经验规律，描述了这样一个定理：只有少数英文单词经常被使用，大部分的单词很少被使用。这个定理也在很多分布里面得到了验证，比如人们的收入，互联网的网站数量和访问比例，互联网内容和访问比例(其他分布两个常数有所不同,a越大，分布越密集,对于VOD来说某些时候符合双zipf分布)。 下面是某个系统VOD内容的访问分布，第一幅图是访问频率曲线，Y轴是内容的访问次数，X轴是内容根据访问次数的排名, 我们可以看到，多数访问集中于少量内容上: 第二幅图是对数轴的访问频率曲线，源数据和上图一致,可以看到近似为一条直线： 从曲线的斜率可以计算出，这里的内容访问频率分布，a约等于0.6(不同种类的内容a的大小也不一样)。...[阅读全文]

摘要:CDN是内容分发网络的缩写，主要解决网络骨干带宽耗用和用户访问Qos问题，大家使用Google搜索一把就可以找到大量的资料。 文章贴在我另外一个BLOG: http://blog.liumeiti.org/peon/archive/2004/12/07/320.aspx 文章的几个人物都是相熟的朋友，调侃他们一把:D   今天晚上看ACE又泡汤了 另外，开心的CLR is everywhere 说明微软在数据库和企业开发方面的成功，另外windows2003也在服务器领域攻城略地，不仅联想到微软在IPTV领域近期发生的一些动向： SBC同微软签订4亿美元 IPTV产品合同 微软与汤姆逊推出IPTV机顶盒在瑞士试播 微软在做了大量投入以后，开始大举进入这个领域，虽然有人说“跟着微软走没有错”，而且微软投入的力量(号称历时10年，100亿美元)和技术实力也非常惊人，不过这个领域毕竟不同于通用软件和开发者社区，结局如何，我们拭目以待；另外，不知道微软何时大举进军通信领域:D...[阅读全文]

摘要:上集和相关内容请见：http://blog.joycode.com/peon/articles/16504.aspx 接下来发生了一些事情，张翠山夫妇双双自尽，他们的儿子张无忌又被打伤，张三丰和武当诸侠都忙于给张无忌疗伤，无暇顾及各自弟子的武学，而且为了诸侠和张老道的安全，给他们的问题不再直接交到他们手里，每人选了一个得意的弟子，代替自己解答问题，这些弟子的记忆力和反应都不错，可以解答大部分的问题，假如遇到不会的问题，就先向师父请教，然后回答给提问题的弟子，这样不仅大大减轻了诸侠的负担，而且防止了一些危险，比如在在便条上下毒，保护了诸侠的安全（徒弟的命就不值钱了？）。 在这种关系里，武当诸侠和他们的代理弟子构成了反向代理(Reverse Proxy)的关系，反向代理一般作用有三：减轻源服务器负载，保障源服务器安全，对源服务器进行负载均衡(Load Balance)。 一般反向代理置于源服务器的前端，配备大容量的内存和高速磁盘，缓存客户的请求，所以反向代理又称为服务器加速(Server accelerate)。源服务器一般不再和客户直接通讯，当客户请求没有缓存的内容或者动态内容时，反向代理向源服务器发送请求，然后把回应转发给客户，在这种情况下，反向代理服务器通常要为一个请求同时维护两个会话。和普通的代理不同，反向代理一般只代理一台或者有限的几台服务器，对于客户而言，反向代理服务器对于他们就相当于源服务器，对于源服务器而言，反向代理服务器通常就是唯一的客户，因为一般客户不和源服务器直接通信。典型情况下，源服务器对于客户或者客户对于源服务器，都是不可见的。 过了一段时间，张三丰觉得无法根治张无忌的体内的玄冥寒气，决定带他下山到少林寺去碰碰运气，为了让请教张三丰的弟子不至于得不到解答，宋远桥和俞莲舟暂时代替张三丰答题，凡是有请教张三丰的问题，宋青书就轮流送到宋远桥或者俞莲舟的住所。 张老道不在山上，可是他负责的服务不会中断，这种情况可以称为离线缓存(Offline Caching)，宋青书的所作的相当于把一个域名交替解析到两个或者以上的地址上去，这个就是DNS轮询。 张三丰所学太过渊博，单凭宋或者俞任何一人都难以回答所有的问题，两个人的知识加起来才可以勉强做到，但是宋青书却有时候把宋远桥不会的问题送到宋远桥那里，俞莲舟也常常遇到这种尴尬(说明宋青书到底还是少了根筋)。这两位到底是高人，一合计，决定视情况采取以下三种办法之一:1.假如宋远桥收到自己不会的，就写回复说自己很忙，而且这个问题俞莲舟很有研究，叫弟子另外写纸条问俞莲舟，俞也是如此这般。2.宋远桥把纸条给俞莲舟解答，然后自己把解答给弟子。3.宋远桥把纸条给俞莲舟解答，俞把解答给弟子。 第一种方法称为内容转向(URL Redirection)，就是当服务器发送给客户端一个特殊回应和新的URL，表示客户应该在其他的地方取得内容，然后客户向新的URL提出请求以获取内容，很多的协议都支持，开发过web的人对redirection和302 code应该都很熟悉。 第二种方法中，问问题的弟子，宋远桥，俞莲舟，还有张三丰构成了多重代理关系，宋相当于俞的反向代理，俞又是张三丰的反向代理。这个过程，对客户是完全不可见的。 第三种方法称为三角传输，宋，俞，弟子的请求应答构成了一个三角形，这种方式中，客户向A服务器发起请求，A服务器把请求转发到B服务器，然后根据客户的控制由B服务器向客户发送内容。 这三种方式各有优缺点，内容转向比较灵活，但是需要应用协议的支持(目前HTTP,MMS,RTSP支持)，而且转向次数一般有限制。多重代理构造复杂，而且因为代理需要维持双倍的会话，服务器负担很重。三角传输适合于请求流量小而回应内容流量多（比如流媒体）的情况，但是需要特殊网络设备(radware wsd)的支持，某些情况下，三角传输的前端还易于成为瓶颈。...[阅读全文]

摘要:续集和相关内容请见：http://blog.joycode.com/peon/articles/16504.aspx 话说武当山上，张三丰老道开创武当一派，收了七个弟子，分别是:宋远桥、俞莲舟、俞岱岩、张松溪、张翠山、殷梨亭、莫声谷七人，号称武当七侠。七弟子中，宋远桥是掌门，精研易理，同时对于相面算命很有研究。俞莲舟武功最强，太极拳很厉害，殷梨亭擅长剑术，其他弟子也各有所长。 张三丰常年闭关，钻研武学，而这七个弟子又收了一些弟子，其中宋远桥的儿子宋青书是武当第三代弟子中的佼佼者。 依照武当的规矩，各个弟子(Client)可以向七位师傅(Server)讨教，可以把练功中的疑难写在纸上（Request），送到各位师父的住处，然后由各个师傅解答(Response)。 这种关系，就是最直接的服务器-客户机关系。 但是，这样存在一些问题，武当七侠住在不同的地方，有的地方很艰险，不是所有的弟子都可以到达的，这样，宋远桥就叫宋青书跑腿(Proxy Server)，每个弟子只要知道宋青书的住处(设定代理地址)，把疑难写在纸条上，再写上要请教的师父的姓名，再交给宋青书，就可以了。宋青书将纸条转交给七侠之一，将答复的纸条给各个弟子。 对于宋青书而言，各个弟子向他投递纸条，由他转交各位师父，在这种关系里，宋青书相当于师父(Server)，各位弟子是徒弟(Client),然后宋青书向七侠请教，这种关系里，宋青书是Client,七侠是Server，中间的过程，就叫代理(Proxy),宋青书就相当于代理服务器。 这种代理关系里面，各个弟子需要知道宋青书的地址(设定代理地址)，这种关系叫做显式代理(Explicit Proxy)，IE,MediaPlayer都可以设置代理。 经过一段时间，各个弟子也觉得这种方法虽然避免了很多的麻烦，但是很慢。宋青书也对这种跑腿的事情感到厌烦，他发现大多数人问的问题集中在几个问题上(80%的访问集中在20%的内容上)，于是，宋青书就把这几个问题的答案记在自己的IBM笔记本上(缓存)，以后凡是弟子们问到这几个问题，宋青书不需要再去问七侠，直接找出答案回复给各个弟子，这样各个弟子得到答复的速度快多了，武当七侠也有更多的时间干点其他事情(减轻了Server的负担)。宋青书的脑袋比较灵活，他还写了个程序，统计各个问题被问到的频率，随时记下新的热门问题，淘汰不再热门的问题(缓存替换算法)。 过了一段时间，宋远桥偷偷告诉宋青书，说准备把他作为掌门继承人，让他好好表现。宋青书于是改变工作作风，不再让各个弟子把纸条交给他，而是跑来跑去收集纸条，交给武当七侠。很多新弟子只是知道把纸条写好放在门口，自然会得到武当七侠的指导，大家都忘了宋青书干的这份事情，但是张三丰老道对宋青书可是十分的赞赏，立他为武当掌门继承人。 这种关系，叫做隐式代理(Implicit Proxy)，客户意识不到代理服务器的存在，也不需要设定代理服务器的地址，但是客户请求和服务器回应都会经过代理服务器，对于客户而言，代理服务器是透明的(transparent)。 续集: http://blog.joycode.com/peon/archive/2004/03/21/16756.aspx...[阅读全文]

摘要:大家比较一下： http://www.windowsmedia.cn http://www.microsoft.com/windows/windowsmedia/default.aspx www.liumeiti.cn 的 annie 干的,真的挺佩服的。 顺便提一下annie 的 http://www.smilchina.com/...[阅读全文]

摘要:看了题目不要想歪 用Windows XP应该有不少人了吧！想没有想过几段视频，几张相片，搞点东西和大家一起欣赏一下？看看使用 Windows Movie Maker 制作电影吧！非常简单，简直和拷贝一个笑话发给朋友差不多。 微软提供了很多例子：http://www.microsoft.com/china/windowsxp/moviemaker/videos/samples/default.asp 这里还有一个网友做的她的BLOG宣传片：http://home.liumeiti.org/sandblog.wmv 下载：http://www.microsoft.com/downloads/details.aspx?displaylang=zh-cn&FamilyID=82887484-6f21-43e2-b4e2-051f72c11a77  ...[阅读全文]

摘要:MMS和RTSP都是用于通过网络进行流媒体服务的协议(mms是微软的私有协议，和那个手机的MMS没有关系的)。 前两天在内容重定向上碰到了问题：http://blog.joycode.com/peon/posts/14725.aspx 今天看了这篇文章：http://msdn.microsoft.com/library/en-us/dnwmt/html/mmsfirewall.asp 提到微软的mms协议关于NAT的问题，终于对这个问题有了初步的头绪：mms协议和rtsp协议都把流分为控制流和数据流，当使用udp作为数据流时候一般这样： client连接到server的一个固定端口比如1755,一切就绪后，然后发送自己的ip地址和端口号给server，server就向这个IP和端口发送数据流。 但是经过NAT时，NAT修改IP包的端口和IP地址，但是NAT并不了解MMS协议，当然不知道修改client发送给server的信息了,于是server发出的数据就无法到达client,类似的还有FTP采用主动模式的情况。 原来一直没有意识到这个问题，因为我是采用的mms的方式，当使用这两种协议描述字的时候，其实client和server私下里会协商采用mmst(走tcp通道)或者mmsu(通过udp发送数据)，这个过程称为协议翻转,通过NAT以后，一般都采用了tcp的方法(就是mmst)，这种方法似乎数据流和控制流使用了同一个连接，对于NAT是友好的。 今天才意识到mmsu协议其实不是NAT友好的。 然后Client在重定向以后再协议翻转的时候(mms->mmst)，出了问题，为什么会出问题，原因仍然不是很清楚，MediaPlayer可没有源代码看 :D...[阅读全文]