放翁(文初)的一亩三分地

  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  210 随笔 :: 1 文章 :: 320 评论 :: 0 Trackbacks

2009年12月9日 #

     摘要: Beatles小记(三)-分布式数据流分析中Master的横向扩展  阅读全文
posted @ 2012-01-17 13:21 岑文初 阅读(5108) | 评论 (2)编辑 收藏

     摘要: Beatles小记-分布式数据流分析框架(二),局部代码设计和实现分享  阅读全文
posted @ 2011-12-09 16:44 岑文初 阅读(4678) | 评论 (4)编辑 收藏

     摘要: 分布式流式数据分析设计和代码分析  阅读全文
posted @ 2011-12-07 16:46 岑文初 阅读(9524) | 评论 (7)编辑 收藏

     摘要: java优化设计实现细节分享  阅读全文
posted @ 2011-09-23 14:03 岑文初 阅读(5009) | 评论 (1)编辑 收藏

     摘要: 两个开放平台内部组件开放   阅读全文
posted @ 2011-07-12 11:54 岑文初 阅读(3736) | 评论 (2)编辑 收藏

     摘要: 讨论一下并发消息下行的设计方案和实现  阅读全文
posted @ 2011-06-23 12:16 岑文初 阅读(4483) | 评论 (0)编辑 收藏

     摘要: Jetty内部透明简单实现  阅读全文
posted @ 2011-06-22 17:03 岑文初 阅读(3975) | 评论 (0)编辑 收藏

     摘要: 慢连接&LazyParser  阅读全文
posted @ 2011-06-20 23:47 岑文初 阅读(5311) | 评论 (0)编辑 收藏

     摘要: PipeComet测试  阅读全文
posted @ 2011-06-08 23:58 岑文初 阅读(6892) | 评论 (0)编辑 收藏

     摘要: 一段代码,几句话  阅读全文
posted @ 2011-04-13 23:11 岑文初 阅读(4551) | 评论 (1)编辑 收藏

     摘要: 开放平台的技术问题  阅读全文
posted @ 2011-03-31 00:43 岑文初 阅读(4804) | 评论 (4)编辑 收藏

     摘要: Web容器测试模型选择  阅读全文
posted @ 2011-03-31 00:40 岑文初 阅读(3368) | 评论 (0)编辑 收藏

     摘要: 十年  阅读全文
posted @ 2011-03-08 23:46 岑文初 阅读(2888) | 评论 (6)编辑 收藏

     摘要: 模拟登录看前端门外汉学习  阅读全文
posted @ 2011-03-03 23:26 岑文初 阅读(5524) | 评论 (10)编辑 收藏

     摘要: 逻辑划分线程池  阅读全文
posted @ 2011-03-01 00:32 岑文初 阅读(5138) | 评论 (4)编辑 收藏

     摘要: OAuth2的一些改变  阅读全文
posted @ 2011-02-28 23:01 岑文初 阅读(3396) | 评论 (0)编辑 收藏

     摘要: “淘宝的”开放平台  阅读全文
posted @ 2011-02-23 23:39 岑文初 阅读(5066) | 评论 (4)编辑 收藏

     摘要: 交流分享  阅读全文
posted @ 2011-02-20 23:58 岑文初 阅读(4949) | 评论 (7)编辑 收藏

     摘要: ask & answer  阅读全文
posted @ 2011-01-12 23:22 岑文初 阅读(3854) | 评论 (0)编辑 收藏

     摘要: 耗内存应用优化实际案例  阅读全文
posted @ 2010-12-22 23:40 岑文初 阅读(4287) | 评论 (0)编辑 收藏

     摘要: Local Cache的小TIP   阅读全文
posted @ 2010-12-14 22:34 岑文初 阅读(3387) | 评论 (4)编辑 收藏

     摘要: SD开放平台技术分享  阅读全文
posted @ 2010-12-13 20:35 岑文初 阅读(3186) | 评论 (2)编辑 收藏

     摘要: Facebook优化分享后记  阅读全文
posted @ 2010-12-12 19:43 岑文初 阅读(3433) | 评论 (4)编辑 收藏

     摘要: 这篇文章将会从问题,技术背景,设计实现,代码范例这些角度去谈基于管道化和事件驱动模型的Web请求处理。建议从头看,能够从概念上更多的去理解和碰撞,其中的一些描述和例子也许不是很恰当,也希望得到更多的反馈。  阅读全文
posted @ 2010-11-25 14:44 岑文初 阅读(4092) | 评论 (7)编辑 收藏

     摘要: 这篇文章将会从问题,技术背景,设计实现,代码范例这些角度去谈基于管道化和事件驱动模型的Web请求处理。建议从头看,能够从概念上更多的去理解和碰撞,其中的一些描述和例子也许不是很恰当,也希望得到更多的反馈。  阅读全文
posted @ 2010-11-24 01:26 岑文初 阅读(3349) | 评论 (4)编辑 收藏

     摘要: 图片是大纲,先抛出来,后续会有更详细的文章分享  阅读全文
posted @ 2010-11-17 01:00 岑文初 阅读(2633) | 评论 (2)编辑 收藏

     摘要: 如果关注开放平台或者关注平台的一些内容,这篇文章应该有点内容可看  阅读全文
posted @ 2010-10-11 23:42 岑文初 阅读(2908) | 评论 (1)编辑 收藏

     摘要: 美国JavaOne之行内容,需要看直播请关注微博  阅读全文
posted @ 2010-09-22 15:55 岑文初 阅读(1660) | 评论 (1)编辑 收藏

     摘要: 代码背后的点滴,通过一些设计理念来分享技术的积累  阅读全文
posted @ 2010-09-09 02:05 岑文初 阅读(4281) | 评论 (8)编辑 收藏

     摘要: 面试有感  阅读全文
posted @ 2010-09-02 11:31 岑文初 阅读(2381) | 评论 (4)编辑 收藏

     摘要: 对同学性能优化总结的一点回复  阅读全文
posted @ 2010-08-23 16:58 岑文初 阅读(2272) | 评论 (0)编辑 收藏

     摘要: ppt分享  阅读全文
posted @ 2010-08-10 07:48 岑文初 阅读(3623) | 评论 (2)编辑 收藏

     摘要: 在概念篇介绍完以后,开始实际的对TOP开始做技术改造。(这篇东西更像是对短期工作的总结和汇报,写的不是很详实,后续会有一个ppt来深化异步化的一些思想)下面将第一阶段的工作做个总结,第一阶段主要做了以下几个方面的事情  阅读全文
posted @ 2010-08-06 00:38 岑文初 阅读(4194) | 评论 (0)编辑 收藏

     摘要: 淘宝一年陈  阅读全文
posted @ 2010-07-24 00:34 岑文初 阅读(2820) | 评论 (7)编辑 收藏

     摘要: Web服务的重放攻击的一点想法  阅读全文
posted @ 2010-07-07 00:40 岑文初 阅读(3173) | 评论 (0)编辑 收藏

     摘要: Web服务请求异步化介绍  阅读全文
posted @ 2010-06-30 08:41 岑文初 阅读(5215) | 评论 (4)编辑 收藏

     摘要: Web服务请求异步化测试  阅读全文
posted @ 2010-06-13 14:35 岑文初 阅读(4406) | 评论 (9)编辑 收藏

     摘要: 访问TOP链接超时和重置问题  阅读全文
posted @ 2010-06-09 13:34 岑文初 阅读(1698) | 评论 (1)编辑 收藏

     摘要: 对TOP高并发的一点回答  阅读全文
posted @ 2010-06-07 21:22 岑文初 阅读(1748) | 评论 (0)编辑 收藏

     摘要: TOP的价值所在  阅读全文
posted @ 2010-06-01 08:49 岑文初 阅读(3513) | 评论 (5)编辑 收藏

     摘要: 开放平台两三点感悟(下)  阅读全文
posted @ 2010-06-01 02:53 岑文初 阅读(3272) | 评论 (4)编辑 收藏

     摘要: 开放平台两三点感悟  阅读全文
posted @ 2010-05-28 02:29 岑文初 阅读(4349) | 评论 (6)编辑 收藏

http://t.sina.com.cn/fangweng

posted @ 2010-05-24 21:54 岑文初 阅读(1275) | 评论 (0)编辑 收藏

     摘要: ModJK与tomcat消息传递出现的串消息问题  阅读全文
posted @ 2010-05-11 20:00 岑文初 阅读(2756) | 评论 (0)编辑 收藏

     摘要: 异步模式下的Web请求(技术介绍篇)  阅读全文
posted @ 2010-04-20 08:50 岑文初 阅读(4222) | 评论 (1)编辑 收藏

     摘要: Q1技术点滴  阅读全文
posted @ 2010-04-02 02:26 岑文初 阅读(3099) | 评论 (5)编辑 收藏

     摘要: 普通程序员的2009  阅读全文
posted @ 2010-01-29 01:34 岑文初 阅读(2138) | 评论 (4)编辑 收藏

 

优化杂谈

Author :放翁

Bloghttp://blog.csdn.net/cenwenchu79/

         当应用遇到规模化问题的时候,就是考虑性能优化的时候了。今天同事和我聊起了NIO在客户端的使用与BIO有什么优势,也勾起了我前一阵子和其他同学交流优化的一些想法,纯粹个人的一点想法。

CPU利用率和Load

         在过去做压力测试的时候,我们经常会关注两个指标,CPULoad。有同学觉得CPU利用率上去了Load肯定也上去了,Load上去了CPU利用率同样会上去。但是在一些需要优化的场景下,常常会看到Load很高,CPU利用率却可能比较低(多核更是可能出现分配不均的情况)。Load其实就是等待处理的任务队列,当你的应用在等待同步消息返回处理的同时,CPU还是会将时间切片分配给这些线程,而真正需要CPU的线程,却不得不在到了时间片以后暂时放弃工作被挂起。因此在程序设计的时候就要考虑如何利用好CPU的这个资源,如何均匀的将压力分摊到各个CPU上(有时候就一个线程在不断循环,导致单个CPU负荷很高)。

NIO在客户端的使用

         Http消息设置keepalive和采用NIO的方式复用信道、BIO结合连接池的方式,最基本的目的就是降低建立TCP产生握手的成本,最大限度的复用已有的资源,但是否NIO就只有复用信道这点呢?

         NIOBIO在数据传输和处理的模式上有不同,NIO采用的是BufferPacket+Channel的模式,这其实和操作系统本身的传输模式很类似,而BIOStream的模式是Java自己独特的模式。在采用NIO的这种数据传输模式以后,可以充分利用操作系统本身对传输的优化,因此这是一方面好处。另一方面异步和事件机制的使用,可以降低对于昂贵的资源申请,在高并发下提高处理能力。

NIO客户端的编程模型最大特点:依赖反置,松耦合带来性能提升。在请求流程协议中支持“票根”,也就是我们说的回执。例如,你今天面试完了,不需要你在阿里巴巴前台等着结果,直接留个电话,有消息就会直接通知,电话就是通知结果和服务请求者的关联手段。(此时阿里巴巴前台和会议室就会有足够的空间给其他人来面试,这就是资源)

         服务端使用NIO就不多说了,这里主要说一下在客户端的使用场景。两者是否真的有很大的差别,是否NIO有绝对的优势,其实还是和场景有关。简单说来就一个判断标准:应用对于通道的利用率是否够高。下面列了4种场景:

1. 一次请求数据量很少,服务处理速度很快。

2. 一次请求数据量很多,服务处理速度很快。

3. 一次请求数据量很少,服务处理速度很慢。

4. 一次请求数据量很多,服务处理速度很慢。

场景1,传输效率很高,服务处理速度很快,一次请求很快就被完成,采用NIOBIO,在性能优势上除了操作系统对NIO的优化以外,BIO连接池不输于NIO。在易用性上,BIO更加容易处理。(NIO的异步机制,就要求消息传输协议需要有会话码来提供异步处理入口选择如何处理)

场景2,传输过程比较长,消耗时间比较多,服务处理速度很快,因此交互的时间大部分都还是在数据通道传输上,由于NIO在传输过程中依然是串行化的,因此BIO的连接池优于NIO,同时NIO一个客户端只有一个通道,因此BIO开的连接池越大,并行处理能力越强,因此BIO效率比较好一些。

场景3,传输量比较少,服务处理比较慢,很明显这是通道利用率低的表现,NIO有绝对的优势,特别是在高并发下。信道和服务端客户端资源被充分利用。

场景4,传输量比较多,服务处理也比较慢,这时候可以发现信道利用率取决于服务事件和传输消耗时间的比例,这类场景某些情况下BIO也会优于NIO

单线程和多线程

         在使用多线程来优化程序的时候,是否考虑过多线程的使用场景,多线程不是万能药,在某些情况下还可能是毒药。使用多线程的过程中,需要考虑这么几个因素:

1. 资源竞争,复杂度增加。

为什么前面提到的NIO客户端在处理数据流发送和读取的时候都是采用单线程,数据流的发送和读取都是在一个数据通道上的,而读取和发送本身时间消耗是固定的(不论是多线程还是单线程),同时增加了复杂度(需要处理数据包整合问题)。这其实就是在资源上的串行化操作直接导致了任务的串行化,因此任务多线程反而起到了反作用。

2. 是否是关键路径的工作,占关键路径的比例。

首先,在优化以前需要考虑优化的内容是否是关键路径的工作,如果不是,那么增加复杂度实现的多线程模式,就没有价值。其次就是看是否是在关键路径中占有比较大的比例,同样的,还是投入产出比例(多线程带来的复杂度以及在高并发下的一些资源保护措施都需要很多的维护成本)。

3. 任务的合理切分。

NIO的客户端,接受数据的事件将会写得很轻量级,但是接受到数据然后分析数据还原成业务对象,则会通过线程池的方式来分别处理。就好比监听连接到来,和实际的去建立连接分成了两个阶段的任务,让事件型的任务单纯,快速执行,让与业务相关的部分通过多线程并行的方式提高处理效率。总的来说就是把任务划分成为系统性的任务和业务性的任务,前者消耗时间少,设计尽量简单高效,采用单线程处理即可,后者通常情况下在处理流程和资源上不冲突的情况可以通过多线程并行提高效率。

         优化应用关注点:

A.关键路径是否可以优化,关键路径的任务拆分。

B.关键路径上的单个任务是否可以拆分并行执行。(是否有资源竞争,是否会有流程上的前后依赖,是否增加复杂度引入新的不稳定因素)

C.系统资源和依赖外部系统是否会成为瓶颈。(单机的CPU,IO都会在一定的压力下成下降趋势,并行执行反而降低了处理能力)

因此,可以看到不论是MapReduce设计下的Hadoop,还是Erlang语言级别的特性,都尽量的希望任务之间可以并行执行,相互之间低耦合,通过异步事件消息通知方式来交互,同时数据没有共享,防止资源竞争导致无法并行高效处理。系统设计还是要根据场景来判断使用什么方式优化,越简单越好。

posted @ 2010-01-27 01:45 岑文初 阅读(3647) | 评论 (1)编辑 收藏

     摘要: 基于MapReduce的配置型日志分析组件  阅读全文
posted @ 2010-01-12 21:58 岑文初 阅读(3845) | 评论 (5)编辑 收藏

     摘要: TOP团队招贤纳士  阅读全文
posted @ 2009-12-11 15:52 岑文初 阅读(1893) | 评论 (0)编辑 收藏

    中午左右收到一个看我blog的朋友的邮件,最近他在研究mapreduce,然后想用hadoop来做一些工作,不过遇到了一些问题,我这边也贴一下他的几个问题,同时觉得自己把自己的一些看法分享一下,当然只是自己的一些想法,也许对新学习的同学有帮助。

   问题:

  1. 从Map(K,V)的方式来看,难道mapreduce只能做统计?
  2. 目前我想除了日志分析之类的功能外,还想做一个全文检索的功能,类似windows查询一下,通过关键字查询文件的位置即可(可能还要根据匹配度做排序),这个我很迷茫不知道怎么下手,痛苦ing
  3. 你的实践是一个单机模式,如果用户把一个1G的log已经上传到hdfs了,此时分割工作已经完成,只需要从client那里得到文件基本信息和块的location就可以了,那mapreduce怎么进行下去呢?

   我给回复的邮件内容:

   首先,MapReduce的思想和Hadoop的MapReduce的架构不是一个概念,说的具体一点也就是Hadoop的架构设计只是MapReduce的一个子集思想的实现。每个人都可以根据自己对MapReduce的理解去实现业务处理,简单来说多线程处理就是MapReduce的一种最简单的实现,复杂来说多机协调工作就是一种复杂的实现。

   MapReduce的思想里面最值得借鉴的:

   a.问题分而治之。(找到流程的关键路径,优化可以并行处理的工作)

   b.计算靠近数据。(这也是hdfs存在的最重要的特点,计算的转移往往要比数据转移廉价,特别是对海量数据的处理)

   c.数据规模化随着并行处理成数量级递减。

   剩下的内容就是各个框架对于非业务性需求的处理,例如容灾,如何尽量少穿数据协调处理等等。

   针对他提出的三个问题:

    1. Hadoop的mapreduce从架构上来说最适合的就是统计分析计算。做其他方面的工作需要考虑是否适合,而不是为了技术而技术,先有需求再有技术选型。
    2.  对于你这个需求直接用搜索技术实现就可以了,不一定要硬套在mapreduce上。
    3. 对于海量数据是否一定要到hdsf上,或者就简单得数据物理或者逻辑切割来直接处理,根据自己业务场景选择。hdfs的特点就是对文件切割,容灾,数据逻辑存储和物理存储无关性(便于扩容管理,同时也是计算靠近数据的技术保证)。

    是否使用MapReduce框架,HDFS存储关键还是看你是否真的需要,当现有框架对自己来说并不合适的时候可以对小规模问题定制MapReduce的处理,最简化就是你去多线程或者多进程处理问题,需求决定技术选型。

  

posted @ 2009-12-09 13:09 岑文初 阅读(2576) | 评论 (1)编辑 收藏