Quantcast
Channel: IT社区推荐资讯 - ITIndex.net
Viewing all 15843 articles
Browse latest View live

要想提高工作效率,请拒绝做这7种事

$
0
0

编者注:此文是 CamMi Pham 的文章,原文发表在 Medium上。作者通过自身经历和一些科学证据说明,有时候努力工作未必是通往成功的正确路径。成功的关键不是努力而是巧干。因为时间是稀缺商品,有时候少干反而收效更佳。

忙未必就说明你有生产力。要想有生产力,更多的是要管理好你的精力而不是时间。要经营好你的生活。我们需要学会花费最小的精力得到最大的收益。不干以下 7 件事,我把每周的工作时间从 80 小时缩短到了 40 小时,但是完成的工作却多了很多。

1、不加班效率高

每周 5 天,每天 8 小时的工作制是福特在 1926 年的发现。实验表明,把每天工作时间从 10 小时降至 8 小时,每周工作时间从 6 天降至 5 天后,生产力反而提升了。

1980 年由商业圆桌会议发布的《建筑项目的加班效应》指出,无论从短期还是长期来看,工作越多,效率和生产力都会下降:

若每周工作时间超过 60 小时的情况持续超过两个月,生产力下降的累积效应将导致完工日期推迟,而同样的人数每周只工作 40 小时甚至还会更早完工。

美国军方研究表明,“每天少睡 1 小时持续一周会导致相当于 0.1 血醇水平的认知退化”。

《睡眠的秘密世界》指出:

熬夜之后无论白天你干得有多好,情绪不会太高。更重要的是前瞻性思考和行动的意愿、对冲动的抑制、乐观程度、同理心、情商等也会下降。

所以保证充足的睡眠对于维持高水平的生产力十分重要。

很多名人的经验是白天多小睡。达芬奇、拿破仑、爱迪生、罗斯福夫人、吉恩•奥特里、肯尼迪、洛克菲勒、丘吉尔、林顿•约翰逊、里根等都有小睡的习惯。

2、不要老说“好的”

根据 20/80 原理(帕累托原理),20% 的努力创造出 80% 的结果;但反过来 20% 的结果消耗了 80% 的努力。因此我们应该把精力集中在能产出 80% 结果的事情上,然后放弃其他的事情。如此就能把更多的时间集中在最重要的任务上。我们应该对低产出甚至无结果的任务停止说“yes”。

成功人士和非常成功人士的区别在于后者几乎对所有事情说“不”

——巴菲特

这就引出一个问题:我们该对哪些事情说“yes”,对哪些事情说“no”呢?如果想不出哪些事情值得花时间,不妨来个简单的分离测试。跟踪自己所做的一切事情然后尽可能优化。

我们中的大多数往往都说了太多的“yes”,因为这比拒绝要容易得多。没人想当坏人。

2012 年的消费者杂志发表了一项研究,研究人员把 120 人分成了 2 组。一组人训练成说“我不能(I can’t)”,另一组则说“我不(I don’t)”。结果很有趣:

告诉自己“我不能吃 X”的学生在 61% 的时间内选择了吃巧克力糖,而告诉自己“我不吃 X”的只在 36% 的时间里抵挡不住诱惑。在说法上作这么简单的一个变化就能显著改善健康食品的选择。

所以,下次需要避免说 yes 的时候,直接说“我不”。

另一个避免不必要活动的技巧是 20 秒规则:对于不应该做的事情多给自己 20 秒的时间考虑。

3、不要事必躬亲

我曾经管理过一个非常大的社区,试图一个人做完所有事情,最后发现我干不了。我筋疲力尽,最后社区接管了自我管理的工作。令人惊奇的是大家做得比我还好。我因而领悟到了社区的力量。

我们必须意识到,在需要的时候可以去寻求帮助,这一点很重要。让做得更好的人接管你的一些工作对你来说更好。这可以让你花更多的时间在自己最重要的任务上。不要把时间浪费在自己解决问题上,让专家帮助你。

很多时候,哪怕朋友不能帮你,他们的陪伴也能让你更有生产力。

4、不要完美主义

达尔豪斯大学的心理学教授 Simon Sherry 的完美主义与生产力研究发现,完美主义是生产力的绊脚石:

完美主义者完成任务需要花费更多的时间

完美主义者因此等待完美时刻而耽搁。就商业而言,如果你等到了完美时刻时间已经太迟。

完美主义往往因为一叶障目而不见泰山,因为过于关注小事情而错失了大场面。

最好的完美时刻就是现在。

5、不要做重复工

根据 Tethys Solution 的一项研究,一支 5 人团队,如果把 3%、20%、25%、30% 和 70% 时间花在重复性工作上,经过 2 个月的生产力强化(引入自动化软件)后,时间相应降至 3%、10%、15%、15% 和 10%。

现在只要我需要重复做一件事情 5 次以上,我就会要求自己找个程序来替我做。不会编程没关系,如果不懂开发,那就去买程序。

人们往往不记得时间就是金钱。他们手工做的原因通常是因为这么做比较容易,不需要研究。处理 30 张图片似乎没有问题,但是如果是 30000 张呢?你只能靠软件去处理了。记住,你需要花钱去挣钱,而时间是你最有价值的商品。

6、决策不靠猜测

如果网站可以 SEO,那么生活也能。不要靠胡乱猜测做决定,要用数据支持你的决策。

不同领域有许多研究可供参考。比方说,你是否知道下午 4 点的时候人最容易分心?这是宾州大学助理教授 Robert Matchock 领导的一项研究。哪怕你找不到需要的数据,进行分离测试也不需要话太多的时间。

要不断问问自己,你打算如何去衡量和优化自己所做的一切事情 ?

7、不要老是工作

大多数人没有意识到,如果我们过于专注在某件事情上,就会画地为牢,跳不出框框。时不时从工作中脱身出来独处一下非常重要。按照《孤独的力量》的说法,独处的时间对于大脑和精神很有益处:

哈佛研究表明,如果某人相信自己正在独自体验某件事情时,其记忆会更持久更精确。另一项研究表明,一定时间的独处可令人更具同理心。尽管没人会质疑早期过多的孤僻生活是不健康的,但一定时间的独处可令青少年改善情绪提高成绩。

给反省留点时间很重要。当我们不去寻找解决方案时,后者却往往不期而至。

当然,我们不能一夜之间就能变得更有生产力。跟生活中的每一件事情一样,这也需要努力。守株待兔是等不到变化的。我们都需要多了解自己的身体,找到精力分配的最佳方式,这样才能拥有更成功更幸福的生活。


Python 性能分析入门指南

$
0
0

虽然并非你编写的每个 Python 程序都要求一个严格的性能分析,但是让人放心的是,当问题发生的时候,Python 生态圈有各种各样的工具可以处理这类问题。

分析程序的性能可以归结为回答四个基本问题:

  1. 正运行的多快
  2. 速度瓶颈在哪里
  3. 内存使用率是多少
  4. 内存泄露在哪里

下面,我们将用一些神奇的工具深入到这些问题的答案中去。

用  time 粗粒度的计算时间

让我们开始通过使用一个快速和粗暴的方法计算我们的代码:传统的 unix  time 工具。

 $ time python yourprogram.py
real    0m1.028s
user    0m0.001s
sys     0m0.003s

三个输出测量值之间的详细意义在这里  stackoverflow article,但简介在这:

  • real — 指的是实际耗时
  • user — 指的是内核之外的 CPU 耗时
  • sys — 指的是花费在内核特定函数的 CPU 耗时

你会有你的应用程序用完了多少 CPU 周期的即视感,不管系统上其他运行的程序添加的系统和用户时间。

如果 sys 和 user 时间之和小于 real 时间,然后你可以猜测到大多数程序的性能问题最有可能与  IO wait 相关。

用  timing context 管理器细粒度的计算时间

我们下一步的技术包括直接嵌入代码来获取细粒度的计时信息。下面是我进行时间测量的代码的一个小片段

timer.py

import time

class Timer(object):
    def __init__(self, verbose=False):
        self.verbose = verbose

    def __enter__(self):
        self.start = time.time()
        return self

    def __exit__(self, *args):
        self.end = time.time()
        self.secs = self.end - self.start
        self.msecs = self.secs * 1000  # millisecs
        if self.verbose:
            print 'elapsed time: %f ms' % self.msecs

为了使用它,使用 Python 的  with 关键字和  Timer 上下文管理器来包装你想计算的代码。当您的代码块开始执行,它将照顾启动计时器,当你的代码块结束的时候,它将停止计时器。

这个代码片段示例:

from timer import Timer
from redis import Redis
rdb = Redis()

with Timer() as t:
    rdb.lpush("foo", "bar")
print "=> elasped lpush: %s s" % t.secs

with Timer() as t:
    rdb.lpop("foo")
print "=> elasped lpop: %s s" % t.secs

为了看看我的程序的性能随着时间的演化的趋势,我常常记录这些定时器的输出到一个文件中。

使用  profiler 逐行计时和分析执行的频率

罗伯特·克恩有一个不错的项目称为  line_profiler , 我经常使用它来分析我的脚本有多快,以及每行代码执行的频率:

为了使用它,你可以通过使用  pip 来安装它:

pip install line_profiler

安装完成后,你将获得一个新模块称为  line_profiler 和  kernprof.py 可执行脚本。

为了使用这个工具,首先在你想测量的函数上设置  @profile 修饰符。不用担心,为了这个修饰符,你不需要引入任何东西。 kernprof.py 脚本会在运行时自动注入你的脚本。

primes.py

@profile
def primes(n): 
    if n==2:
        return [2]
    elif n<2:
        return []
    s=range(3,n+1,2)
    mroot = n ** 0.5
    half=(n+1)/2-1
    i=0
    m=3
    while m <= mroot:
        if s[i]:
            j=(m*m-3)/2
            s[j]=0
            while j<half:
                s[j]=0
                j+=m
        i=i+1
        m=2*i+3
    return [2]+[x for x in s if x]
primes(100)

一旦你得到了你的设置了修饰符  @profile 的代码,使用  kernprof.py 运行这个脚本。

kernprof.py -l -v fib.py

-l 选项告诉  kernprof 把修饰符  @profile 注入你的脚本, -v 选项告诉  kernprof 一旦你的脚本完成后,展示计时信息。这是一个以上脚本的类似输出:

Wrote profile results to primes.py.lprof
Timer unit: 1e-06 s

File: primes.py
Function: primes at line 2
Total time: 0.00019 s

Line #      Hits         Time  Per Hit   % Time  Line Contents
==============================================================
     2                                           @profile
     3                                           def primes(n): 
     4         1            2      2.0      1.1      if n==2:
     5                                                   return [2]
     6         1            1      1.0      0.5      elif n<2:
     7                                                   return []
     8         1            4      4.0      2.1      s=range(3,n+1,2)
     9         1           10     10.0      5.3      mroot = n ** 0.5
    10         1            2      2.0      1.1      half=(n+1)/2-1
    11         1            1      1.0      0.5      i=0
    12         1            1      1.0      0.5      m=3
    13         5            7      1.4      3.7      while m <= mroot:
    14         4            4      1.0      2.1          if s[i]:
    15         3            4      1.3      2.1              j=(m*m-3)/2
    16         3            4      1.3      2.1              s[j]=0
    17        31           31      1.0     16.3              while j<half:
    18        28           28      1.0     14.7                  s[j]=0
    19        28           29      1.0     15.3                  j+=m
    20         4            4      1.0      2.1          i=i+1
    21         4            4      1.0      2.1          m=2*i+3
    22        50           54      1.1     28.4      return [2]+[x for x

寻找  hits 值比较高的行或是一个高时间间隔。这些地方有最大的优化改进空间。

它使用了多少内存?

现在我们掌握了很好我们代码的计时信息,让我们继续找出我们的程序使用了多少内存。我们真是非常幸运, Fabian Pedregosa 仿照 Robert Kern 的  line_profiler 实现了一个很好的内存分析器  [memory profiler][5]

首先通过 pip 安装它:

$ pip install -U memory_profiler
$ pip install psutil

在这里建议安装  psutil 是因为该包能提升  memory_profiler 的性能。

想  line_profiler 一样,  memory_profiler 要求在你设置  @profile 来修饰你的函数:

@profile
def primes(n): 
    ...
    ...

运行如下命令来显示你的函数使用了多少内存:

$ python -m memory_profiler primes.py

一旦你的程序退出,你应该可以看到这样的输出:

Filename: primes.py

Line #    Mem usage  Increment   Line Contents
==============================================
     2                           @profile
     3    7.9219 MB  0.0000 MB   def primes(n): 
     4    7.9219 MB  0.0000 MB       if n==2:
     5                                   return [2]
     6    7.9219 MB  0.0000 MB       elif n<2:
     7                                   return []
     8    7.9219 MB  0.0000 MB       s=range(3,n+1,2)
     9    7.9258 MB  0.0039 MB       mroot = n ** 0.5
    10    7.9258 MB  0.0000 MB       half=(n+1)/2-1
    11    7.9258 MB  0.0000 MB       i=0
    12    7.9258 MB  0.0000 MB       m=3
    13    7.9297 MB  0.0039 MB       while m <= mroot:
    14    7.9297 MB  0.0000 MB           if s[i]:
    15    7.9297 MB  0.0000 MB               j=(m*m-3)/2
    16    7.9258 MB -0.0039 MB               s[j]=0
    17    7.9297 MB  0.0039 MB               while j<half:
    18    7.9297 MB  0.0000 MB                   s[j]=0
    19    7.9297 MB  0.0000 MB                   j+=m
    20    7.9297 MB  0.0000 MB           i=i+1
    21    7.9297 MB  0.0000 MB           m=2*i+3
    22    7.9297 MB  0.0000 MB       return [2]+[x for x in s if x]

line_profiler 和  memory_profiler 的 IPython 快捷命令

line_profiler 和  memory_profiler 一个鲜为人知的特性就是在 IPython 上都有快捷命令。你所能做的就是在 IPython 上键入以下命令:

%load_ext memory_profiler
%load_ext line_profiler

这样做了以后,你就可以使用魔法命令  %lprun 和  %mprun 了,它们表现的像它们命令行的副本,最主要的不同就是你不需要给你需要分析的函数设置  @profile 修饰符。直接在你的 IPython 会话上继续分析吧。

In [1]: from primes import primes
In [2]: %mprun -f primes primes(1000)
In [3]: %lprun -f primes primes(1000)

这可以节省你大量的时间和精力,因为使用这些分析命令,你不需要修改你的源代码。

哪里内存溢出了?

cPython的解释器使用引用计数来作为它跟踪内存的主要方法。这意味着每个对象持有一个计数器,当增加某个对象的引用存储的时候,计数器就会增加,当一个引用被删除的时候,计数器就是减少。当计数器达到0, cPython 解释器就知道该对象不再使用,因此解释器将删除这个对象,并且释放该对象持有的内存。

内存泄漏往往发生在即使该对象不再使用的时候,你的程序还持有对该对象的引用。

最快速发现内存泄漏的方式就是使用一个由 Marius Gedminas 编写的非常好的称为  [objgraph][6] 的工具。
这个工具可以让你看到在内存中对象的数量,也定位在代码中所有不同的地方,对这些对象的引用。

开始,我们首先安装  objgraph

pip install objgraph

一旦你安装了这个工具,在你的代码中插入一个调用调试器的声明。

import pdb; pdb.set_trace()

哪个对象最常见

在运行时,你可以检查在运行在你的程序中的前20名最普遍的对象

pdb) import objgraph
(pdb) objgraph.show_most_common_types()

MyBigFatObject             20000
tuple                      16938
function                   4310
dict                       2790
wrapper_descriptor         1181
builtin_function_or_method 934
weakref                    764
list                       634
method_descriptor          507
getset_descriptor          451
type                       439

哪个对象被增加或是删除了?

我们能在两个时间点之间看到哪些对象被增加或是删除了。

(pdb) import objgraph
(pdb) objgraph.show_growth()
.
.
.
(pdb) objgraph.show_growth()   # this only shows objects that has been added or deleted since last show_growth() call

traceback                4        +2
KeyboardInterrupt        1        +1
frame                   24        +1
list                   667        +1
tuple                16969        +1

这个泄漏对象的引用是什么?

继续下去,我们还可以看到任何给定对象的引用在什么地方。让我们以下面这个简单的程序举个例子。

x = [1]
y = [x, [x], {"a":x}]
import pdb; pdb.set_trace()

为了看到持有变量 X 的引用是什么,运行  objgraph.show_backref() 函数:

(pdb) import objgraph
(pdb) objgraph.show_backref([x], filename="/tmp/backrefs.png")

该命令的输出是一个 PNG 图片,被存储在  /tmp/backrefs.png,它应该看起来像这样:

backrefs (1)

 

盒子底部有红色字体就是我们感兴趣的对象,我们可以看到它被符号 x 引用了一次,被列表 y 引用了三次。如果 x 这个对象引起了内存泄漏,我们可以使用这种方法来追踪它的所有引用,以便看到为什么它没有被自动被收回。

回顾一遍,objgraph 允许我们:

  • 显示占用 Python 程序内存的前 N 个对象
  • 显示在一段时期内哪些对象被增加了,哪些对象被删除了
  • 显示我们脚本中获得的所有引用

Effort vs precision

在这篇文章中,我展示了如何使用一些工具来分析一个python程序的性能。通过这些工具和技术的武装,你应该可以获取所有要求追踪大多数内存泄漏以及在Python程序快速识别瓶颈的信息。

和许多其他主题一样,运行性能分析意味着要在付出和精度之间的平衡做取舍。当有疑问是,用最简单的方案,满足你当前的需求。

Python 性能分析入门指南,首发于 博客 - 伯乐在线

美国专家建议:70岁再退休好处多多

$
0
0

美国专家建议:70岁再退休好处多多

根据美国退休研究中心发布的最新全国退休风险指数显示,目前有一半多的美国人没有存够足够的退休金。这已经不是什么新生现象,只不过从经济衰退以来,更为严重罢了。为什么美国人的退休金持续短缺?原因其实不难看出。

报告称,35岁的美国人如果想要晚年过得舒适,需要将15%的年薪作为养老金投入。低收入人群的养老金比例要低一些,但是无论如何,为了退休生活有保障,养老金是一定要交的。现在大多数的美国人养成了储蓄的习惯,他们有的是为了预防突发事件、教育、首付款、房屋改造等等原因。根据2010消费者金融调查的数据显示,只有53%的美国人完全不存任何钱,更别提15%的退休金储蓄了。

但是,15%的推荐储蓄率的基础是在65岁时退休。如果你觉得这个数字太高不能承受,没关系,只要工作到70岁,你每年只需要存年收入的6%。

延迟退休年龄的好处是双向的,一方面延长了储蓄养老金的年限,另一方面,减少了养老金的使用年限,一切看上去都很公平。其实65岁退休和70岁退休的区别,更在于养老保险。我们假设一个35岁的美国人,他一年能挣4.9万美元,这个数字在他这个年龄段属于中等水平。如果他65岁退休,每年能从养老保险中得到18200美元;70岁退休,一年就有26500美元,增幅达到45%。

把钱放在养老保险里,回报比储蓄和投资更高。如果放在401(k)基金和个人养老账户(IRA)里,钱会随着市场行情的涨跌而涨跌,所以不建议美国人这样做。国家养老保险只看工资水平,不看市场行情。——专家建议说。

美国专家也表示,推迟退休年龄也有风险。70岁之前你能不能保证正常的工作能力还不一定,不但失业的风险提高,在工作中患病或残疾的风险也大大提高。特别是对身体要求较高的工作岗位和新入职工资较低的岗位。

但是美国专家还是建议大家推迟退休,因为好处要比坏处多——存钱压力小,能花的钱也多了。蛤蛤蛤

[ 王大发财 via Businessweek]








品读:与今日头条反向而行

$
0
0

1

尽管个性化阅读软件“ 今日头条”此前面临来自《新京报》、搜狐等合作媒体以及国家版权局的压力,但作为一家新闻资讯推荐公司,北京旭宁信息技术有限公司CEO徐屾屾认为,“从其产品来说,今日头条推荐的新闻还是很准确。”

徐屾屾的团队一起合作了很多年,这是一个有多年开发经验的老团队。2009年初,他们做的第一款手机应用Daily Finance iPhone App就成为美国最受欢迎的金融应用,之后又连续做了4款游戏。这些产品都在全球下载榜上长期保持不错的成绩。之后,这个团队开始做开发外包,开发了不少知名的产品,业务一直做得顺风顺水。2012年初,他们停止了外包业务,开始专注于产品研发。

品读”是徐屾屾的团队开发的一款全新理念的个性化阅读类产品,这款产品的iPad,iPhone及网站版已经上线,并且推出了相应的浏览器插件。

尽管都主推个性化阅读,但品读的推荐机制并非完全基于类似今日头条所用的“大数据”。在徐屾屾看来,机器推荐可以算出用户的兴趣,但很难算出内容本身的品质。

品读更像是一个基于内容的Zaker跟Pocket的合体。品读的内容主要来自用户收集,部分来自合作媒体。

品读的文章被聚合在一个个代表不同主题的本子里,它们由用户创建,由用户整理。用户在品读里可以按照兴趣阅读这些本子,同时可以使用品读在移动端、PC端将喜欢的文章收集到本子里,创建新的本子,而品读会将这其中的精品按照大家的阅读兴趣推荐给用户。

基于移动端的阅读需求很大。根据CNNIC发布的第34次《中国互联网络发展状况统计报告》,从2013年12月到2014 年 6 月,网络新闻用户规模超过5亿,使用率达到79.6%。时下最为热门的手机资讯软件 今日头条发布的数据显示,其日活跃用户有1300多万,月度活跃用户4000万,下载并启动过手机的累计激活数据是1.2亿。

3

 

品读的用户都是多大年纪的?

品读的用户年龄分布很广泛,从17、18岁到40多岁都有。用户创建的本子从情感类美文到中国文字字体研究应用尽有。有一个名为“蒸汽博客”的本子,主要是收集蒸汽朋克的内容,这位本子的主人是一位文身师。

今日头条已经做得很好了,你为什么还要做一个?

跟今日头条提供新闻不同,品读上提供的新闻很少。我们希望给用户提供能沉淀下来的内容。坚持看10年新闻可能也不会有太大收获。我们的产品相当于一个内容众包版的Flipboard。

你的内容主要来自用户收集,用户真的有收集的欲望吗?

这其实是还原了一种古老的需求。以前收集剪报,只是现在放到手机、电脑上且能分享。

除了从网上收集之外,PC版的品读还提供博客功能,供用户发布自己原创的内容。用户可以通过这些资讯结识自己最想认识的人。在没有社交功能的情况下,用户的收集不会产生价值。

你的盈利模式是怎样的?

品读的盈利模式跟今日头条、Flipboard一样,瞄准的是广告主。不过,品读提供的广告方式可能不只是目前普遍的横幅模式。我更希望能切入主题类广告,这类广告占据广告界利润的最大比例。

6

采访手记

品读从今年6月上线至今,已得到了大量用户的认可。徐屾屾介绍,“每个人的兴趣都有很多,因此一个用户可能就有几个不同兴趣点的本子。”

让用户订阅其他用户的本子,除了为用户提供精品内容以外,这也是激励用户收集本子的一个动力。一些用户在用过一段时间Pocket之后,便再也不会点开也很少分享。徐屾屾认为,这正是因为Pocket只利于收集,不利于分享传播,在没有社交功能的情况下,用户的收集不会产生价值。

徐屾屾自己就是一个典型的用户案例。他在品读上建立了一个关于科技新闻的本子,在演示如何使用本子收集资讯时,他突然说了一句:“不能随便收集,这体现我的品味。”

 

本文 品读:与今日头条反向而行来自 动点科技.

python 代码自动生成的方法 (代码生成器)

$
0
0

python 代码自动生成的方法 (代码生成器)

遇到的问题

工作中遇到这么一个事,需要写很多C++的底层数据库类,但这些类大同小异,无非是增删改查,如果人工来写代码,既费力又容易出错;而借用python的代码自动生成,可以轻松搞定;
(类比JAVA中的Hibernate自动生成的数据库底层操作代码)
下面介绍使用python字符串替换的方法;

Python字符串替换的几种方法

1. 字符串替换
将需要替换的内容使用格式化符替代,后续补上替换内容;

template = "hello %s , your website  is %s " % ("大CC","http://blog.me115.com")
print(template)

也可使用format函数完成:

template = "hello {0} , your website  is {1} ".format("大CC","http://blog.me115.com")
print(template)

注:该方法适用于变量少的单行字符串替换;

2. 字符串命名格式化符替换
使用命名格式化符,这样,对于多个相同变量的引用,在后续替换只用申明一次即可;

template = "hello %(name)s ,your name is %(name), your website  is %(message)s" %{"name":"大CC","message":"http://blog.me115.com"}
print(template)

使用format函数的语法方式:

template = "hello {name} , your name is {name}, your website  is {message} ".format(name="大CC",message="http://blog.me115.com")
print(template)

注:适用相同变量较多的单行字符串替换;

3.模版方法替换
使用string中的Template方法;

from string import Template
tempTemplate = string.Template("Hello $name ,your website is $message")
print(tempTemplate.substitute(name='大CC',message='http://blog.me115.com'))

有了模版方法后,就可以将模版保存到文件单独编辑,在生成的地方替换为需要的变量;

示例:代码生成

这个示例使用以上讲到的第三种方法;
建立一个模版文件,里面需要替换的内容使用${}变量替换;
dao_cpp.template

///
/// @class ${CLASSNAME}
/// @brief Redis底层接口类 操作${TABLE_NAME}表
/// TABLE ${TABLE_NAME_UPPER}
/// @author dao_cpp_generator.py
/// @generate date: ${GENE_DATE}
/// [注:本文件为自动生成,不需要人为编辑,若有修改,请通过配置py脚本来重新生成.]

#include "${CLASSNAME}.h"
#include "include/${TABLE_NAME}_t.h"
#include "RedisManager.h"
#include "common/LogMacros.h"
#include "common/StringUtility/OtherStringFunc.h"
#include "common/DateTime.h"

namespace redisdao{

#define PRIMARY_KEY "${PRIMER_KEY}"
const string ${CLASSNAME}::TABLE_NAME = "${TABLE_NAME}";
const string ${CLASSNAME}::TABLE_ID = "${TABLE_ID}"; //在数据库中的表的唯一性标识符
const string ${CLASSNAME}::KEY_SEPARETER = "${KEY_SEPARETER}";

${CLASSNAME}::${CLASSNAME}(void)
{
    if ( 0 == m_reHandler.EnsureConnect())
        m_bRedisConnected = true;
    else
        m_bRedisConnected = false;
}

${CLASSNAME}::~${CLASSNAME}(void)
{
}

int ${CLASSNAME}::InsertRecord(const string& strVal)
...

python代码生成程序:
cpp_generator.py

#! /usr/bin/env python
#coding=utf-8
#Redis底层操作类CPP文件生成程序(*RedisDao.cpp)
#author me115@126.com 2014-7-22
import os,sys,re,traceback
from datetime import datetime
from string import Template

class DaoCppGenerator:

    def generate(self):
        tableName = 'students'
        className = '%sRedisDao' %  tableName.capitalize()
        filePath = r'include/%s.cpp' % className
        class_file = open(filePath,'w')

        lines = []

        #模版文件
        template_file = open(r'dao_cpp.template','r')
        tmpl = Template(template_file.read())

        #模版替换
        lines.append(tmpl.substitute(
                    CLASSNAME = className,
                    TABLE_NAME = tableName,
                    TABLE_NAME_UPPER = tableName.upper(), 
                    GENE_DATE = datetime.now().strftime('%Y-%m-%d %H:%M:%S'),
                    TABLE_ID = '115',
                    EXPIRE_DATE = '06JUN14'))

        # 0.将生成的代码写入文件
        class_file.writelines(lines)
        class_file.close()

        print 'generate %s over. ~ ~' % filePath

有了这个程序,再配合一堆XML配置文件,就可以轻松生成各种C++程序代码了;

Posted by: 大CC | 25JUL,2014
博客: blog.me115.com [ 订阅]
微博: 新浪微博

关于MySQL数据库的数据类型发生隐形转换的问题咨询

$
0
0

网友的问题:

1.MySQL对于int类型索引使用问题,如:tb中有主键id,普通索引tid,在执行SQL:select * from tb where id = 2 order by id 时,
extra为空,这里的id值没带引号,如果带上引号extra也为空。

2.当 select * from tb where tid = 2 order by tid,tid为普通索引,这时tid的值带引号和不带引号就会有区别,带引号时extra会提示额外的排序,不带引号时extra为空,这是怎么一回事?
zhdba

mysqlops的回答:

1.当字段类型为:INT;

2. 传入的值为:字符串类型;

3.WHERE条件中的整型字段的传入值用单引号或双引号;

上述描述的前提条件下,会对把传入的 值类型 转换为 字段定义的数据类型,故WHERE 条件是可以使用到索引的,但从数据

库表读出到内存块后的值会被 转换为 传入值的数据类型,从而导致ORDER BY无法使用到索引解释为何ORDER BY ID没有外

部排序 或extra的内容为空,那是因为WHERE ID=’2′ 按主键查询只能查到唯一的一条记录,故不需要排序;

ORDER BY tid 时,WHERE tid=’2′ 按普通索引去查找的话,能查找到的数据条数会大于1条,加上数据类型隐形转换了,为

此需要再额外进行排序和extra部分有内容显示;

总结:

数据库中要尽量避免发生数据隐形转换的危险,极端情况下可能会发生偶尔的WHERE条件都无法使用到索引,故开发规范

非常重要。

再谈SOA和ESB总线平台价值

$
0
0
关于SOA的咨询实施方法论,SOA平台和云平台的融合,SOA咨询方法论和EA企业架构思想的融合在前面很多文章都有谈到。在多年的SOA咨询和实施中,经常遇到的一个问题就是SOA是不是已经过时了?而这个问题追溯本源还是客户没有真正理解SOA咨询方法论,SOA组件化架构带来的好处,而是把SOA或ESB理解为了一个简单的接口平台或数据交换平台,如果一开始的思维方式或规划就是错误或偏差的,那么最终效果自然大打折扣。

对于SOA平台带来的价值,从以下几个方面进行阐述:

首先是集成模式方面的,传统企业内部业务系统之间往往是通过点对点的网状集成模式,接口类型很多,数据库直接连接,存储过程,视图,JAVA API,文件接口等;同时接口本身没有相对严格的接口规范和设计契约。导致后续的接口管理和运维都相当复杂。在转成总线式集成后,所有接口转化为服务,直接接入到ESB总线上,服务遵循严格的规范规范和契约文档,以形成企业内应用集成架构的标准管控环境。

从这个意义上讲,部分人会有进一步的疑惑,即如果原来的业务系统间已经通过标准的Web Service服务进行集成,原来点对点模式也没有发现明显的问题,整个集成过程中也没有类似传统消息中间件的大量消息协议转换工作要做,那么为何还要接入到ESB服务总线而多一个中间步骤?对于这个问题主要分两方面阐述:

其一,原来点对点做服务的时候,往往每个服务都需要考虑日志记录,服务审计,服务的访问安全,传输安全和数据安全,服务的路由分发等一系列问题。而这些内容本质是可复用的,在ESB总线中可以统一接管,并通过灵活可配置的模式进行设置。既统一的SOA服务管控和治理的标准,也减轻了原生服务的设计开发工作量。

其二,ESB含了消息中间件的全部功能,正是有了异步消息处理机制后,可以实现业务系统间真正的松耦合架构,如果ESB平台全部集成的是同步服务,则很难算得上完整意义上的松耦合架构。这个是ESB总线另外一个强大的功能,但是我们在进行服务识别和服务设计的时候往往忽略。

其次,在复用层面,如果仅仅将SOA或ESB理解为一个集成平台,那么SOA平台本身的价值将大打折扣。SOA的核心思想一直在强调就是要找到可以复用的服务,这些服务满足离散,松耦合,无状态,粗粒度等特点,同时这些服务可以组装和编排,灵活满足业务变更的需要。

复用的难点在服务架构规划和服务识别上,当前很多做SOA咨询和实施的厂家基本来说都没有这个系统能力来做这个事情。这个不是简单的理论指导实践的事情,更像我上篇文章谈到的,是必须通过大量的SOA咨询和实施实践,再反向抽取出来的经验和方法论。而我们的SOA架构咨询优化能力就在于融合了EA企业架构,云平台,软件工程和组件化开发,IT管控和治理,BPM业务流程分析和业务建模多方面的知识总结出来的,实际可以操作落地的方法论和最佳实践。再简单点来说就是从端到端流程分析和建模入手,遵循业务驱动IT的核心思想,围绕业务流程,数据,应用,技术,集成核心维度,形成完整的服务架构规划和服务目录梳理。

SOA的实施最终要形成企业可复用的IT和服务资产库,这个是企业很重要的无形资产,在配合服务目录库和服务视图的可视化展示,真正让SOA的价值显性化出来。这个资产库积累的越成熟,那么我们后续做新建系统,功能模块或变更的工作量越小,越标准化。真正形成一个可持续发展的内部IT治理生态环境。

最后即SOA实施后灵活敏捷响应变化的能力,这种敏捷性主要体现在两个方面,一个方面是服务本身可复用而不需要重新进行大量的设计开发工作;其次是服务本身可以灵活的组合组装和编排,以满足一个完整的业务流程的需要。对于第二点对应到我们常说的BPEL和BPM工具环境层面,但是实际效果来看,理想化的BPM业务流程管理平台应用的并不好,同时大量的人工工作流引擎平台号称是BPM平台。这个实施不好的原因也从两方面分析:

其一,当前的很多套装BPM工具往往要求企业原来是白纸一张,即所有的思路和方法都完全按照我们BPM平台和工具的要求来做,这个对很多企业很难,毕竟很多企业原来已经建设和实施了大量的业务系统。如果要保留原来的,在单纯的服务层面容易整合和集成,但是到了BPM流程和完整功能层面,就很难做集成。同时BPM思想做出来的业务应用本身就是跨传统多个业务系统思想的,这种应用最终是体现在门户平台上,那么应用最终的管理和认责部门究竟是谁?这些都是很现实的问题。

其二,BPM要用好又包括两个方面的内容,首先是要有很深厚的业务流程规划和建模能力,这种人既要懂业务又要懂技术,类似BPMN2.0语言等都是衔接业务和技术两端的,业务和技术都懂你才能够建模出来。这比原来单纯的画业务流程图,梳理业务流程难的多,一般人都很难真正胜任;还有就是流程建模的内容最终是要通过调用底层ESB服务目录中的服务进行组装和编排,但是真正需要调服务的时候你才发现ESB上的服务很少或者原来实施的服务根本无法复用,实施一个BPM最终变成首先要协调大量的开发厂商,实施大量的服务封装和接入工作,而这些都是相当难以协调的,也导致理想化的BPM很难真正推广下去。

简单总结下,SOA在咨询和规划阶段的难点在于SOA服务的识别,SOA在实施阶段的难点是SOA集成商如何整体协调甲方和各个开发商资源,构建SOA治理和管控环境。前者的重点在要懂企业架构和信息化规划,懂业务;后者的重点在既要懂SOA治理和管控方法,又要有很强的项目群管理能力。

  青春就应该这样绽放   游戏测试:三国时期谁是你最好的兄弟!!   你不得不信的星座秘密

用java程序把本地的一个文件拷贝到hdfs上并显示进度

$
0
0
把程序打成jar包放到Linux上
转到目录下执行命令 hadoop jar mapreducer.jar /home/clq/export/java/count.jar  hdfs://ubuntu:9000/out06/count/
上面一个是本地文件,一个是上传hdfs位置

成功后出现:打印出来,你所要打印的字符。

package com.clq.hdfs;

import java.io.BufferedInputStream;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.net.URI;
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.FSDataOutputStream;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.fs.Path;
import org.apache.hadoop.io.IOUtils;
import org.apache.hadoop.util.Progressable;

public class FileCopyWithProgress {
//********************************
//把本地的一个文件拷贝到hdfs上
//********************************
	public static void main(String[] args) throws IOException {
		String localSrc = args[0];
		String dst = args[1];
		InputStream in = new BufferedInputStream(new FileInputStream(localSrc));
		Configuration conf = new Configuration();
		FileSystem fs = FileSystem.get(URI.create(dst), conf);
		FSDataOutputStream out = fs.create(new Path(dst), new Progressable() {
			@Override
			public void progress() {
				System.out.print(".");
			}
		});
		IOUtils.copyBytes(in, out, conf, true);
	}

}

可能出现异常:
Exception in thread "main" org.apache.hadoop.ipc.RemoteException: java.io.IOException: Cannot create /out06; already exists as a directory
        at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.startFileInternal(FSNamesystem.java:1569)
        at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.startFile(FSNamesystem.java:1527)
        at org.apache.hadoop.hdfs.server.namenode.NameNode.create(NameNode.java:710)
        at org.apache.hadoop.hdfs.server.namenode.NameNode.create(NameNode.java:689)
        at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:587)
        at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1432)
        at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1428)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.Subject.doAs(Subject.java:415)
说明你这个路径在hdfs上已经存在,换一个即可。
作者:u012516914 发表于2014-7-25 16:58:14 原文链接
阅读:113 评论:0 查看评论

简单、高效加密算法TEA

$
0
0
TEA(Tiny Encryption Algorithm)是一种分组加密算法,它的实现非常简单,通常只需要很精短的几行代码。

应用领域
(1)客户端桌面程序或手机程序与服务端接口交互,可以使用TEA来进行加密,保证传输信息的私密性。
如:OICQ的数据安全采用了TEA算法,QQ通讯也大量使用了TEA算法。

(2)存储在本地的用户私密信息,可以采用TEA加密算法。
如:QQ存储在本地的msg信息等。


附QQ使用TEA的情况,从网上转载的:


QQ是如何利用TEA进行加密的?
TEA算法被广泛应用于QQ的数据加密中,QQ采用16轮的TEA算法加密,在这时采取16轮加密时而不采取标准的32轮加密时为了减少验证服务器的压力。QQ在数据加密前采用了密码学中的常用的填充及交织技术,减少加密数据的相关性,增加破译者的破解难度。

下表列出了QQ 应用TEA算法几个方面
序号 应用  相关文件
1 通讯报文的加密/解密
2 消息记录的加密/解密 MsgEx.db
3 本地消息密码、首次登录时间、提示内容验证密码 Matrix.db
4 消息备份文件 *.bak






已有 0人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



Vim_Mysql的101个调节和优化的提示

$
0
0

MySQL是一个功能强大的开源数据库。随着越来越多的数据库驱动的应用程序,人们一直在推动MySQL发展到它的极限。这里是101条调节和优化 MySQL安装的技巧。一些技巧是针对特定的安装环境的,但这些思路是通用的。我已经把他们分成几类,来帮助你掌握更多MySQL的调节和优化技巧。

MySQL 服务器硬件和操作系统调节:

1. 拥有足够的物理内存来把整个InnoDB文件加载到内存中——在内存中访问文件时的速度要比在硬盘中访问时快的多。

 

2. 不惜一切代价避免使用Swap交换分区 – 交换时是从硬盘读取的,它的速度很慢。

 

3. 使用电池供电的RAM(注:RAM即随机存储器)。

 

4. 使用高级的RAID(注:Redundant Arrays of Inexpensive Disks,即磁盘阵列) – 最好是RAID10或更高。

 

5. 避免RAID5(注:一种存储性能、数据安全和存储成本兼顾的存储解决方案) – 确保数据库完整性的校验是要付出代价的。

 

6. 将操作系统和数据分区分开,不仅仅是逻辑上,还包括物理上 – 操作系统的读写操作会影响数据库的性能。

 

7. 把MySQL临时空间和复制日志与数据放到不同的分区 – 当数据库后台从磁盘进行读写操作时会影响数据库的性能。

 

8. 更多的磁盘空间等于更快的速度。

 

17. 使用 XFS 文件系统 – 一种比ext3更快、更小的文件系统,并且有许多日志选项, 而且ext3 已被证实与MySQL有双缓冲问题。

 

18. 调整 XFS 文件系统日志和缓冲变量 – 为了最高性能标准。

 

19. 在 Linux 系统中, 使用 NOOP 或者 DEADLINE IO 定时调度程序 – 同 NOOP 和 DEADLINE定时调度程序相比,这个 CFQ 和 ANTICIPATORY 定时调度程序 显得非常慢。

 

20. 使用64位的操作系统 – 对于MySQL,会有更大的内存支持和使用。

 

21. 删除服务器上未使用的安装包和守护进程 – 更少的资源占用。

 

22. 把使用MySQL的host和你的MySQL host放到一个hosts文件中 – 没有DNS查找。

 

23. 切勿强制杀死一个MySQL进程 – 你会损坏数据库和正在运行备份的程序。

 

24. 把服务器贡献给MySQL – 后台进程和其他服务能够缩短数据库占用CPU的时间。

 

MySQL 配置:

 

25. 当写入时,使用 innodb_flush_method=O_DIRECT 来避免双缓冲。

 

26. 避免使用 O_DIRECT 和 EXT3 文件系统 – 你将序列化所有要写入的。

 

27. 分配足够的 innodb_buffer_pool_size 来加载整个 InnoDB 文件到内存中– 少从磁盘中读取。

 

28. 不要将 innodb_log_file_size 参数设置太大, 这样可以更快同时有更多的磁盘空间 – 丢掉多的日志通常是好的,在数据库崩溃后可以降低恢复数据库的时间。

 

29. 不要混用 innodb_thread_concurrency 和 thread_concurrency 参数– 这2个值是不兼容的。

 

30. 分配一个极小的数量给 max_connections 参数 – 太多的连接会用尽RAM并锁定MySQL服务。

 

31. 保持 thread_cache 在一个相对较高的数字,大约 16 – 防止打开连接时缓慢。

 

32. 使用skip-name-resolve参数 – 去掉 DNS 查找。

 

33.如果你的查询都是重复的,并且数据不常常发生变化,那么可以使用查询缓存。但是如果你的数据经常发生变化,那么使用查询缓存会让你感到失望。

 

34.增大temp_table_size值,以防止写入磁盘

 

35.增大max_heap_table_size值,以防止写入磁盘

 

36.不要把sort_buffer_size值设置的太高,否则的话你的内存将会很快耗尽

 

37.根据key_read_requests和key_reads值来决定key_buffer的大小,一般情况下key_read_requests应该比key_reads值高,否则你不能高效的使用key_buffer

 

38.将innodb_flush_log_at_trx_commit设置为0将会提高性能,但是如果你要保持默认值(1)的话,那么你就要确保数据的完整性,同时你也要确保复制不会滞后。

 

39.你要有一个测试环境,来测试你的配置,并且在不影响正常生产的情况下,可以常常进行重启。

 

MySQL模式优化:

40. 保持你的数据库整理性。

 

41. 旧数据归档 – 删除多余的行返回或搜索查询。

 

42. 将您的数据加上索引.

 

43. 不要过度使用索引,比较与查询.

 

44. 压缩文字和BLOB数据类型 – 以节省空间和减少磁盘读取次数.

 

45. UTF 8和UTF16都低于latin1执行效率.

 

46. 有节制地使用触发器.

 

47. 冗余数据保持到最低限度 – 不重复不必要的数据.

 

48. 使用链接表,而不是扩展行.

 

49. 注意数据类型,在您的真实数据中,尽可能使用最小的一个.

 

50. 如果其他数据经常被用于查询时,而BLOB / TEXT数据不是,就把BLOB / TEXT数据从其他数据分离出来.

 

51.检查和经常优化表.

 

52. 经常重写InnoDB表优化.

 

53. 有时,当添加列时删除索引,然后在添加回来索引,这样就会更快.

 

54. 针对不同的需求,使用不同的存储引擎.

 

55. 使用归档存储引擎日志表或审计表-这是更有效地写道.

 

56.  会话数据存储在缓存(memcache)的而不是MySQL中 – 缓存允许自动自动填值的,并阻止您创建难以读取和写入到MySQL的时空数据.

 

57.存储可变长度的字符串时使用VARCHAR而不是CHAR – 节省空间,因为固定长度的CHAR,而VARCHAR长度不固定(UTF8不受此影响).

 

58. 逐步进行模式的变化 – 一个小的变化,可以有巨大的影响.

 

59.在开发环境中测试所有模式,反映生产变化.

 

60. 不要随意更改你的配置文件中的值,它可以产生灾难性的影响.

 

61. 有时候,在MySQL的configs少即是多.

 

62.有疑问时使用一个通用的MySQL配置文件.

 

MySQL metrics widget

 

查询优化:

 

63. 使用慢查询日志去发现慢查询。

 

64. 使用执行计划去判断查询是否正常运行。

 

65. 总是去测试你的查询看看是否他们运行在最佳状态下 –久而久之性能总会变化。

 

66. 避免在整个表上使用count(*),它可能锁住整张表。

 

67. 使查询保持一致以便后续相似的查询可以使用查询缓存。

 

68. 在适当的情形下使用GROUP BY而不是DISTINCT。

 

69. 在WHERE, GROUP BY和ORDER BY子句中使用有索引的列。

 

70. 保持索引简单,不在多个索引中包含同一个列。

 

71. 有时候MySQL会使用错误的索引,对于这种情况使用USE INDEX。

 

72. 检查使用SQL_MODE=STRICT的问题。

 

73. 对于记录数小于5的索引字段,在UNION的时候使用LIMIT不是是用OR.

 

74. 为了 避免在更新前SELECT,使用INSERT ON DUPLICATE KEY或者INSERT IGNORE ,不要用UPDATE去实现。

 

75. 不要使用 MAX,使用索引字段和ORDER BY子句。

 

76. 避免使用ORDER BY RAND().

 

77。LIMIT M,N实际上可以减缓查询在某些情况下,有节制地使用。

 

78。在WHERE子句中使用UNION代替子查询。

 

79。对于UPDATES(更新),使用 SHARE MODE(共享模式),以防止独占锁。

 

80。在重新启动的MySQL,记得来温暖你的数据库,以确保您的数据在内存和查询速度快。

 

81。使用DROP TABLE,CREATE TABLE DELETE FROM从表中删除所有数据。

 

82。最小化的数据在查询你需要的数据,使用*消耗大量的时间。

 

MySQL 备份过程:

 

87. 从二级复制服务器上进行备份。

 

88. 在进行备份期间停止复制,以避免在数据依赖和外键约束上出现不一致。

 

89. 彻底停止MySQL,从数据库文件进行备份。

 

90. 如果使用 MySQL dump进行备份,请同时备份二进制日志文件 – 确保复制没有中断。

 

91. 不要信任LVM 快照 – 这很可能产生数据不一致,将来会给你带来麻烦。

 

92. 为了更容易进行单表恢复,以表为单位导出数据 – 如果数据是与其他表隔离的。

 

93. 当使用mysqldump时请使用 –opt。

 

94. 在备份之前检查和优化表。

 

95. 为了更快的进行导入,在导入时临时禁用外键约束。

 

96. 为了更快的进行导入,在导入时临时禁用唯一性检测。

 

97. 在每一次备份后计算数据库,表以及索引的尺寸,以便更够监控数据尺寸的增长。

 

98. 通过自动调度脚本监控复制实例的错误和延迟。

 

99. 定期执行备份。

 

100. 定期测试你的备份。

 

最后 101: 执行MySQL 监控: Monitis Unveils The World’s First Free On-demand MySQL Monitoring.

 

83。考虑持久连接,而不是多个连接,以减少开销。

 

84。基准查询,包括使用服务器上的负载,有时一个简单的查询可以影响其他查询。

 

85。当负载增加您的服务器上,使用SHOW PROCESSLIST查看慢的和有问题的查询。

 

86。在开发环境中产生的镜像数据中 测试的所有可疑的查询。



已有 0人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



CAP 理论

$
0
0

CAP理论被很多人拿来作为分布式系统设计的金律,然而感觉大家对CAP这三个属性的认识却存在不少误区。从CAP的证明中可以看出来,这个理论的成立是需要很明确的对C、A、P三个概念进行界定的前提下的。在本文中笔者希望可以对论文和一些参考资料进行总结并附带一些思考。

一、什么是CAP理论

CAP原本是一个猜想,2000年PODC大会的时候大牛Brewer提出的,他认为在设计一个大规模可扩放的网络服务时候会遇到三个特性:一致性(consistency)、可用性(Availability)、分区容错(partition-tolerance)都需要的情景,然而这是不可能都实现的。之后在2003年的时候,Mit的Gilbert和Lynch就正式的证明了这三个特征确实是不可以兼得的。

二、CAP的概念

Consistency、Availability、Partition-tolerance的提法是由Brewer提出的,而Gilbert和Lynch在证明的过程中改变了Consistency的概念,将其转化为Atomic。Gilbert认为这里所说的Consistency其实就是数据库系统中提到的ACID的另一种表述:一个用户请求要么成功、要么失败,不能处于中间状态(Atomic);一旦一个事务完成,将来的所有事务都必须基于这个完成后的状态(Consistent);未完成的事务不会互相影响(Isolated);一旦一个事务完成,就是持久的(Durable)。

对于Availability,其概念没有变化,指的是对于一个系统而言,所有的请求都应该‘成功’并且收到‘返回’。

对于Partition-tolerance,所指就是分布式系统的容错性。节点crash或者网络分片都不应该导致一个分布式系统停止服务。

三、基本CAP的证明思路

CAP的证明基于异步网络,异步网络也是反映了真实网络中情况的模型。真实的网络系统中,节点之间不可能保持同步,即便是时钟也不可能保持同步,所有的节点依靠获得的消息来进行本地计算和通讯。这个概念其实是相当强的,意味着任何超时判断也是不可能的,因为没有共同的时间标准。之后我们会扩展CAP的证明到弱一点的异步网络中,这个网络中时钟不完全一致,但是时钟运行的步调是一致的,这种系统是允许节点做超时判断的。

CAP的证明很简单,假设两个节点集{G1, G2},由于网络分片导致G1和G2之间所有的通讯都断开了,如果在G1中写,在G2中读刚写的数据, G2中返回的值不可能G1中的写值。由于A的要求,G2一定要返回这次读请求,由于P的存在,导致C一定是不可满足的。

四、CAP的扩展

CAP的证明使用了一些很强的假设,比如纯粹的异步网络,强的C、A、P要求。事实上,我们可以放松某些条件,从而达到妥协。

首先 —— 弱异步网络模型

弱异步网络模型中所有的节点都有一个时钟,并且这些时钟走的步调是一致的,虽然其绝对时间不一定相同,但是彼此的相对时间是固定的,这样系统中的节点可以不仅仅根据收到的消息来决定自己的状态,还可以使用时间来判断状态,比如超时什么的。

在这种场景下,CAP假设依旧是成立的,证明跟上面很相似。

不可能的尝试 —— 放松Availability或者Partition-tolerance

放弃Partition-tolerance意味着把所有的机器搬到一台机器内部,或者放到一个要死大家一起死的机架上(当然机架也可能出现部分失效),这明显违背了我们希望的scalability。

放弃Availability意味着,一旦系统中出现partition这样的错误,系统直接停止服务,这是不能容忍的。

最后的选择 —— 放松一致性

我们可以看出,证明CAP的关键在于对于一致性的强要求。在降低一致性的前提下,可以达到CAP的和谐共处,这也是现在大部分的分布式存储系统所采用的方式:Cassandra、Dynamo等。“Scalability is a bussness concern”是我们降低一致性而不是A和P的关键原因。

Brewer后来提出了BASE ( Basically Available, Soft-state, Eventually consistent),作为ACID的替代和补充。

五、战胜CAP

1,2008年9月CTO of atomikos写了一篇文章“ A CAP Solution (Proving Brewer Wrong)”,试图达到CAP都得的效果。

这篇文章的核心内容就是放松Gilbert和Lynch证明中的限制:“系统必须同时达到CAP三个属性”,放松到“系统可以不同时达到CAP,而是分时达到”。

Rules Beat CAP:

1) 尽量从数据库中读取数据,如果数据库不能访问,读取缓存中的数据

2) 所有读都必须有版本号

3) 来自客户端的更新操作排队等候执行,update必须包括导致这次更新的读操作的版本信息

4) 分区数量足够低的时候排队等待的update操作开始执行,附带的版本信息用来验证update是否应该执行

5) 不管是确认还是取消更新,所有的结构都异步的发送给请求方

证明:

1) 系统保证了consistency,因为所有的读操作都是基于snapshot的,而不正确的update操作将被拒绝,不会导致错误执行

2) 系统保证了availability,因为所有的读一定会返回,而写也一样,虽然可能会因为排队而返回的比较慢

3) 系统允许节点失效

缺点:

1) 读数据可能会不一致,因为之前的写还在排队

2) partition必须在有限的时间内解决

3) update操作必须在所有的节点上保持同样的顺序

2, 2011年11月Twitter的首席工程师Nathan Marz写了一篇文章,描述了他是如何试图打败CAP定理的: How to beat the CAP theorem

本文中,作者还是非常尊重CAP定律,并表示不是要“击败”CAP,而是尝试对数据存储系统进行重新设计,以可控的复杂度来实现CAP。

Marz认为一个分布式系统面临CAP难题的两大问题就是:在数据库中如何使用不断变化的数据,如何使用算法来更新数据库中的数据。Marz提出了几个由于云计算的兴起而改变的传统概念:

1) 数据不存在update,只存在append操作。这样就把对数据的处理由CRUD变为CR

2) 所有的数据的操作就只剩下Create和Read。把Read作为一个Query来处理,而一个Query就是一个对整个数据集执行一个函数操作。

在这样的模型下,我们使用最终一致性的模型来处理数据,可以保证在P的情况下保证A。而所有的不一致性都可以通过重复进行Query去除掉。Martz认为就是因为要不断的更新数据库中的数据,再加上CAP,才导致那些即便使用最终一致性的系统也会变得无比复杂,需要用到向量时钟、读修复这种技术,而如果系统中不存在会改变的数据,所有的更新都作为创建新数据的方式存在,读数据转化为一次请求,这样就可以避免最终一致性的复杂性,转而拥抱CAP。

具体的做法这里略过。

总结:

其实对于大规模分布式系统来说,CAP是非常稳固的,可以扩展的地方也不多。

它很大程度上限制了大规模计算的能力,通过一些设计方式来绕过CAP管辖的区域或许是下一步大规模系统设计的关键。

————— 参考文献 ———————–

[1] Seth Gilbert and Nancy Lynch. 2002. Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services. SIGACT News 33, 2 (June 2002), 51-59. DOI=10.1145/564585.564601 http://doi.acm.org/10.1145/564585.564601

[2] Guy Pardon, 2008, A CAP Solution (Proving Brewer Wrong), http://blog.atomikos.com/2008/09/a-cap-solution-proving-brewer-wrong/

[3] Werner Vogels, 2007, Availability & Consistency, http://www.infoq.com/presentations/availability-consistency

[4] Nathan Marz, 2011, How to beat the CAP theorem, http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html

苹果被曝提取iPhone个人数据

$
0
0

  据路透社 报道,苹果近日首次承认可以通过未公开的技术,提取用户个人深层数据,包括短信、联系人列表和图片等。技术人员可以将设备连接到“受信任”的电脑,从而绕开备份加密,在用户不知情的前提下,轻松进入联网的iPhone手机。专家表示,窃取用户信息的行为严重侵犯人权,危害全球网络安全。

  安全专家Jonathan Zdziarski近日在纽约举办的黑客大会上,展示了如何利用存在于iOS系统的“后门”,从苹果iPhone中提取大量数据。Jonathan Zdziarski说,提取数据过程中,iPhone用户并不知情,而且无法禁用。这一发现,引发业界关于苹果是否与美国国家安全局合作的猜测。

  苹果否认为情报机构创建了任何“后门”。

  苹果回应称,公司设计这一功能,是向企业IT部门、开发者和苹果维修人员提供所需信息;但在获取受限数据前,需要用户解锁设备,同时需要在iPhone上点击“信任”某一台电脑,以获得电脑的授权,经过授权后的电脑也只能访问有限的诊断数据,苹果并没有为任何情报部门创建“后门技术”。

苹果被曝光提取iPhone个人数据

  Jonathan Zdziarski表示,他不相信苹果的这项服务是用于间谍用途,但是他表示,苹果提取的信息比公开披露的要多很多。

  安全分析师Rich Mogull表示,Zdziarski的说法其实言过其实,但从技术上看是准确的。他表示,苹果收集超出许可的这些信息应该是为了安全性的妥协。

  Mogull也认同Zdziarski的一些观点,如果苹果的后门工具存在,那么执法者将这个工具用于那些针对个人被没收的台式电脑,从里面拿到一些数据,这也许会为他们创造法律上的优势。

  苹果公司对于是否存在这种提供给执法者使用的工具,并没有立即回应。

  此前苹果手机被广泛地认为比其竞争对手谷歌的Android系统更为安全,因为苹果能够经常发布BUG修复补丁,而谷歌并没有权限直接发送软件补丁到指定的设备。

评论《苹果被曝提取iPhone个人数据》的内容...

相关文章:


微博: 新浪微博 - 微信公众号:williamlonginfo
月光博客投稿信箱:williamlong.info(at)gmail.com
Created by William Long www.williamlong.info

用于数据挖掘的分类算法有哪些,各有何优劣?

$
0
0
尝试将quora上的这个回答翻译了下。第一次翻译,不好之处请见谅。
What are the advantages of different classification algorithms?

以下是我这些年总结的指南

训练集有多大?

如果你的训练集很小,高偏差/低方差的分类器(如朴素贝叶斯)比低偏差/高方差的分类器(如K近邻或Logistic回归)更有优势,因为后者容易过拟合。但是随着训练集的增大,高偏差的分类器并不能训练出非常准确的模型,所以低偏差/高方差的分类器会胜出(它们有更小的渐近误差)。

你也可以从生成模型与鉴别模型的区别来考虑它们。

某些分类器的优势

朴素贝叶斯(Naive Bayes, NB)
超级简单,就像做一些数数的工作。如果条件独立假设成立的话,NB将比鉴别模型(如Logistic回归)收敛的更快,所以你只需要少量的训练数据。即使条件独立假设不成立,NB在实际中仍然表现出惊人的好。如果你想做类似半监督学习,或者是既要模型简单又要性能好,NB值得尝试。

Logistic回归(Logistic Regression, LR)
LR有很多方法来对模型正则化。比起NB的条件独立性假设,LR不需要考虑样本是否是相关的。与决策树与支持向量机(SVM)不同,NB有很好的概率解释,且很容易利用新的训练数据来更新模型(使用在线梯度下降法)。如果你想要一些概率信息(如,为了更容易的调整分类阈值,得到分类的不确定性,得到置信区间),或者希望将来有更多数据时能方便的更新改进模型,LR是值得使用的。

决策树(Decision Tree, DT)
DT容易理解与解释(对某些人而言——不确定我是否也在他们其中)。DT是非参数的,所以你不需要担心野点(或离群点)和数据是否线性可分的问题(例如,DT可以轻松的处理这种情况:属于A类的样本的特征x取值往往非常小或者非常大,而属于B类的样本的特征x取值在中间范围)。DT的主要缺点是容易过拟合,这也正是随机森林(Random Forest, RF)(或者Boosted树)等集成学习算法被提出来的原因。此外,RF在很多分类问题中经常表现得最好(我个人相信一般比SVM稍好),且速度快可扩展,也不像SVM那样需要调整大量的参数,所以最近RF是一个非常流行的算法。

支持向量机(Support Vector Machine, SVM)
很高的分类正确率,对过拟合有很好的理论保证,选取合适的核函数,面对特征线性不可分的问题也可以表现得很好。SVM在维数通常很高的文本分类中非常的流行。由于较大的内存需求和繁琐的调参,我认为RF已经开始威胁其地位了。

回到LR与DT的问题(我更倾向是LR与RF的问题),做个简单的总结:两种方法都很快且可扩展。在正确率方面,RF比LR更优。但是LR可以在线更新且提供有用的概率信息。鉴于你在Square(不确定推断科学家是什么,应该不是有趣的化身),可能从事欺诈检测:如果你想快速的调整阈值来改变假阳性率与假阴性率,分类结果中包含概率信息将很有帮助。无论你选择什么算法,如果你的各类样本数量是不均衡的(在欺诈检测中经常发生),你需要重新采样各类数据或者调整你的误差度量方法来使各类更均衡。

但是。。。

更好的数据往往比更好的算法更重要,提取好的特征也需要很大的功夫。如果你的数据集非常大,那么分类算法的选择可能对最后的分类性能影响并不大(所以可以根据运行速度或者易用性来选择)。

如果你很在意分类的正确率,那么你得尝试多种分类器,根据交叉验证的结果来挑选性能最好的。或者,学习下Netflix Prize和Middle Earth, 使用某种集成的方法来组合多个分类器。

— 完 —
本文作者: Jason Gu

【知乎日报】 你都看到这啦,快来点我嘛 Σ(▼□▼メ)

此问题还有 1 个回答,查看全部。
延伸阅读:
数据挖掘与算法是什么关系?
数据分析和挖掘有哪些公开的数据来源?

解密推动全球市场最核心的6个领域——王煜全系列演讲(四)

$
0
0

《富足》作者为人类的未来描绘了一幅激动人心的美好愿景,之前我们谈到人与科技的关系、实现富足的4大力量,那么对未来发展影响力最大的核心领域都有什么?这是各行各业最关注的话题。

一、工业互联网的建立

大量的人工智能和大量的传感器的运用,使得我们对工厂的控制,工厂和工厂之间的协作,以及工厂的柔性制造都达到前所未有的水平。我们在跟美国一些机构沟通一个设想,希望通过工业互联网的控制,让世界上每一个创新者都拥有中国的工厂,任何一个不管多么疯狂的主意,都可以用设计软件传到车间上生产,产量要多少有多少,让任何一个小公司都可以瞬间变成大公司,因为在未来的开放式创新进程中,小公司才是真正的主导者。这也许会成为我们中国成为人类富足贡献者的大机遇。

二、纳米科技

国内发展纳米技术的方式,一向是从国外挖优秀的人才。但是往往人才回到国内,受科研环境等因素的影响,科研成果会减少很多。将人才放在国外更适合他们做学术研究的土壤中培养,然后能将成果输出到国内就好。对于纳米技术,我们目前的程度距繁荣还早得很,因此还是需要嫁接在全球科研的生态体系上。

 

三、生物技术和生物信息

基因工程、基因组测序是最典型的例子,人类2003年才完成对一个人的完整基因组测序,我们人类所有的基因组在03年才知道,到今天十年的时间就做到了什么地位了?《富足》这本书就是讲的这个故事。对一个人的基因组完成测序大概需要1到2周的时间,5000美金,有人预测在五年之内这个数可能就降到500美金了,就意味着我们每个人对自己的了解有空前的增加,小孩一生出来就知道他可能在50岁的时会得心脏病,有了预防措施,人类的寿命会得到大幅度延长,长命百岁就不再只是美好的愿望。

 

四、神经科学的突破

过去30年神经科学有一个最大的突破,它叫做神经可塑性,我们以前认为,人一过了青春期,大脑的所有结构都固定了,如果某一部分坏死了也没有办法将它替换掉。如今这不是不可能的事,神经可塑性的一位创始人有个特别传奇的故事,他的父亲是美国很著名的诗人,突然有一天中风瘫痪了。家人为了帮他重新站起来,把老人接回家,让他像一个婴儿一样学习爬行。最开始他们甚至遭到邻居投诉,认为他们虐待老人。然而三年时间过去,老人从爬到坐,从走到跑,都恢复了正常。儿子看到爸爸的病情很受触动,就去学了医。父亲去世后,他请一个朋友给爸爸做了解剖,结果非常惊人——老人的的脑干97%坏死,按理说应该终身瘫痪,但是为什么恢复了?肯定是大脑的其他部分替代了他的功能,后来他就成为了神经可塑性最早的发现人之一。

除此之外他还提出,是否可以利用大脑可塑性,让身体其他器官代替受损伤的大脑功能?答案是,盲人真的能通过舌头看到世界了。我们的眼睛把外部的光信号输送进大脑视神经后,再转换成电信号,然后由我们大脑的电去解读。盲人看不见了是因为光电转换的部门失灵了,而大脑依然能解读,那么只要在体外完成光电转换就可以了。所以他用一个摄像头来采集光线,然后用计算机进行光电转换,这个时候,人的舌头代替了眼睛,将有电信号的电片含在舌头上。由于大脑的神经可塑性,当视觉区是空白的时候,舌头传进来的信号就能到视觉区做处理,这样盲人就能看到外部世界了。我们可以在网上查到一个产品叫做BrainPort,那个演示一定让你震惊——一个全盲的人戴着眼镜可以在屋里走,可以绕开桌椅障碍物,可以识别标志,可以跟小孩玩猜拳。我们特别有幸跟这个产品签了投资协议,会成为他在中国的投资人。

 

五、社交网络

如今我们能通过网络的算法做大数据预测,美国人靠大数据成功的预测了股票的大趋,他们通过监测推特上一些关键词提及的数量涨跌的数据,就能够预测大趋。哪个词是最标志性的呢?是calm,它高频出现意味着整个社会相对比较平静,这个时候股市就涨,这个词出现得少了,人心就相对浮躁一些,股市就会下跌。它能够预测一周的股市行情,准确率达80%。

 

六、电力新能源

英剧《黑镜》中关于无线充电的预言

我想用一个例子说明,叫做远程通电。我们都知道特斯拉还需要拿插销去充电,可是如果忘了拿插销就开出去,或者回家忘了充电第二天开不走,怎么办?最好的方式是车开在路上,就能自动充电。现在已经有了充电盘,只要把手机放在上面就能开始充电,还有超距离的远程充电,在屋里架一个设备,在一定范围内,所有用电设备都能不用电线进行对充。

现在很多交通监测用无人直升机,但它的飞行时间是有限的,但如果我是远距离的点对点供电,无人直升机就能永远飞着。因此未来的电力能源是革命性的,而且有巨大的市场。

未来我们的投资、教育等等的发展都应该密切关注这六个核心领域。《富足》一书所体现的正是今日美国的主流思想,绘出了一幅通向未来的地图。我们要实现富足就得走出去,去看看那些机会是不是真的存在,并且还要努力把机会拿回来,真正参与到富足的进程中去。

来源:湛卢文化

猜您喜欢:

观点 | 未来是“人人合作,人机协作”的时代——王煜全系列演讲(一)

观点 | 未来人类实现“富足”的四大力量——王煜全系列演讲(二)

观点 | 发挥创造力,带着机器往前走——王煜全系列演讲(三)

旅游业二级市场商机,Roomer帮用户拿回取消酒店房间的预付款

杀价王,抓住消费心理的拍卖网站
无觅

本文版权属于- 商业不靠谱 Bukop.com -转载请务必保留版权信息。
商业不靠谱(bukop.com)致力于汇聚全球新兴的商业模式与创新趋势,在全球范围内整合优秀商业创意和案例,并将这些好点子提供给具有企业家头脑的创业者,以及对创新和挖掘新商机有兴趣的朋友。

Swap对响应时间敏感应用的影响

$
0
0
源:http://blog.hesey.net/2014/05/swap-impact-on-rt-sensitive-apps.html
评:


最近排查的一个线上应用load高的问题,和GC以及Swap有关系。

现象是机器load突然升高,查看占用CPU的线程发现是JVM自己的线程。

jstat发现一个奇怪的现象,Eden Gen到了100%之后会持续好几秒,但Old Gen没有明显增大,说明并不是Eden Gen不够用promote到Old Gen了,感觉似乎是Young GC出了问题。

进一步查看GC Log,发现一次Young GC要1秒多,正常情况下20~30ms都应该结束了。

然而仔细去看那条log会发现CPU消耗并不高:

    [Times: user=0.23 sys=0.00, real=1.31 secs]

多出来的时间如果不在CPU上,那就是耗在了I/O上了,GC的I/O不会在网络上,只能是磁盘了。

free -m看了下,果然Swap的空间快被用满了都。

在排查到最终的内存原因前,先把Swap关掉:

sudo swapoff -a

对于Web应用等对响应时间(rt)非常敏感的系统来说,关闭Swap通常都是一个好的实践。

因为一般来说宁愿应用OOM挂掉也不愿意导致rt飙高,使得应用hang在那里的。

另外建议开启这两个参数:

    -XX:+HeapDumpOnOutOfMemoryError
    -XX:HeapDumpPath=path

帮助你在发生OOM时dump heap,一般这时候的heap dump质量都比较高:)
Written by Hesey Wang in: Java,Linux,技术 |
一条评论 »

    diwayou

    swap绝对是隐患啊,线上一般都是关闭的

    [回复]

已有 0人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐




Java Code Review清单

$
0
0

整洁的代码

清单项目分类
使用可以表达实际意图(Intention-Revealing)的名称有意义的名称
每一个概念只用一个词有意义的名称
使用方案/问题领域名称有意义的名称
类应该是比较小的!
函数应该是比较小的!函数
只做一件事函数
DRY(Don’t Repeat Yourself)原则,(拒绝重复)函数
用代码来解释自己的做法(译者注:即代码注释)注释
确定应用了代码格式化格式
使用异常而不是返回码异常
不要返回Null异常

*参考自: http://techbus.safaribooksonline.com/book/software-engineering-and-development/agile-development/9780136083238

安全

清单项目分类
如果不用于继承,使类为final基础
避免重复代码基础
权限限制:程序应该运行在保证功能正常的最小权限模式下。基础
最小化类和成员的可访问性基础
注释出安全相关的信息基础
系统的输入必须检查是否有效和在允许范围内拒绝服务(Denial of Service)
避免对于一些不寻常行为的过分日志拒绝服务(Denial of Service)
在任何情况下都释放资源(流,连接等等)拒绝服务(Denial of Service)
从异常中清除敏感信息(暴露文件路径,系统内部相关,配置)P私密信息(Confidential Information)
不要把高度敏感的信息写到日志私密信息(Confidential Information)
考虑把高度敏感的信息在使用后从内存中清除私密信息(Confidential Information)
限制包,类,接口,方法和域的可访问性可访问性的扩展(Accessibility Extensibility)
限制类和方法的可扩展性(通过使它为final)可访问性的扩展(Accessibility Extensibility)
检验输入(有效的数据,大小,范围,边界情况等等)输入检验(Input Validation)
把从不可信对象得到的输出作为输入来检验输入检验(Input Validation)
为native方法定义包装类(而不是定义native方法为pulibc)输入检验(Input Validation)
把从不可信对象得到的输出作为输入来对待可变性
使public static域为final(避免调用方(caller)修改它的值)可变性
避免暴露敏感类的构造函数对象构造
避免安全敏感类的序列化序列化反序列化(Serialization Deserialization)
通过序列化来保护敏感数据序列化反序列化(Serialization Deserialization)
小心地缓存潜在的特权操作结果序列化反序列化(Serialization Deserialization)
只有在需要的时候才使用JNI访问限制

*参考自: http://www.oracle.com/technetwork/java/seccodeguide-139067.html

性能

清单项目分类
避免过分的同步并发
保持同步区域比较小并发
知道string连接的性能情况综合编程
避免创建不需要的对象创建和销毁对象

*参考自: http://techbus.safaribooksonline.com/book/programming/java/9780137150021

综合(译者注:原文中的作者把checklist和category对应的列搞错了,译文中已修正)

清单项目分类
对可以恢复的情况使用已受检异常(checked exceptions),对于程序错误使用运行时异常(runtime exceptions)异常
更多地使用标准异常异常
不要忽略异常异常
检查参数的有效性方法
返回空数组或集合,而不是null方法
最小化类和成员的可访问性类和接口
在pulibc类中,使用访问器方法(accessor methods)(译者注:访问器方法即我们平常用的get/set方法)而不是public域类和接口
最小化本地变量的范围综合编程
通过接口引用对象综合编程
遵循广泛接受的命名规则综合编程
避免使用finalizer创建和销毁对象
当你重写equals时总是重写hashCode综合编程
总是重写toString综合编程
使用枚举来代替int常量枚举和注解(Annotations)
使用标记接口(marker interface)(译者注:标记接口是一种没有任何行为的接口,实现它只是为了让实现类属于某种类型,如JDK中的Serializable,Cloneable等)来定义类型枚举和注解(Annotations)
对共享可变的数据使用同步访问并发
使用executors而不是task和thread并发
注释中描述线程安全情况并发
存在有效的JUnit/JBehave测试用例测试

*参考自: http://techbus.safaribooksonline.com/book/programming/java/9780137150021

静态代码分析

清单项目分类
查看静态代码分析器的报告来进行类的添加和修改静态代码分析

可能感兴趣的文章

LoadRunner录制Web协议的脚本

$
0
0

录制Web协议的脚本

1、  打开虚拟用户生成器,选择File----New,会出来一个对话框,如下

    

 

选择Web(HTTP/HTML)协议,点击OK。

2、  点击工具栏内的“Start Record”按钮开始录制。

 

 

3、  在跳出来的对话框中输入要录制的url地址,如 http://www.51testing.com,然后点击OK正式开始录制。

4、  这时会自动打开 http://www.51testing.com主页面,在页面上方显示一个录制工具条(如下图)。此时我们发给服务器的所有请求都会被记录在脚本中。

 

 

5、  输入用户名,密码,点击登录。说明我们的请求已经被记录在脚本中了。

6、  登陆成功后,页面上会显示登陆成功的页面,而且录制工具条上的事件个数会动态增加,说明我们的登陆请求已经被记录在脚本中了。下图是登陆成功的页面,页面上显示“****您好!”

 

 

7、  点击工具条上的停止录制按钮,结束录制,回到脚本中。

8、  现在录制就完成了,为了检查脚本是否可用,点击工具栏上的运行按钮,让脚本自动跑一遍。

9、  为了在回放时能实时看到页面的内容,需要设置浏览器的显示开关。打开General Options对话框,选择Display标签页,把Show  Browse during replay选项打勾。

10、              运行完成后,我们会看到运行结果页面,如下图,说明运行成功。

 

 

 

 

 11、              如果运行结束后看不到结果页面,那么可以选择“View”菜单栏的“Test Results”进行查看。

 

参数化

参数化:可以理解为开发语言中的变量的意思。在脚本中,如果不使用参数,那么所有的测试数据是跟脚本绑定在一起的,如果需要测试不同的数据,需要运行一次,改一下,再运行。如果使用了参数化,可以把多个测试数据保存起来,测试时脚本自动选择测试数据运行。

以上面录制的脚本为例,介绍参数化的使用方法,实现10个用户分别登陆51testing。

1、  打开脚本,找到登陆动作对应的代码。

 

2、  我们看到,录制时的用户名是“测试”,密码是“111111”(此处的用户名和密码都是虚构)。

3、  首先对用户名进行参数化:选中用户名,点击鼠标右键,在出现的快捷菜单中选择“Replace with a parameter”,如下图。

 

4、  在弹出的对话框中输入参数名和参数类型,参数名是自己起的,参数类型选择“File”,点击OK。

 

5、  对密码进行同样的操作。

6、  参数化完成后,我们需要给增加一些测试数据。点击工具栏上的Param List按钮打开参数设置页面。选择UserName,点击“Add Row”按钮增加行,然后在行中输入其他可以登陆的用户名。完成后的效果如下图:

 

7、  对密码参数做同样的操作,按顺序输入和用户名对应的密码,完成后的效果如下图:

 

8、  设置脚本取参数的顺序。假设我们想让脚本在运行时以顺序方式取这5个用户登陆,那么对用户名的设置:Select next row:Sequential;Update value on:Each iteration。意思是每一次迭代时按顺序取下一个参数。

 

9、  对密码的设置,因为密码和用户名是一一对应的。所以对密码的设置是“Same line as UserName”。意思是和用户名称取相同的行的数据。这样就可以保证一一对应了。

 

 

10、              因为我们有5个用户,所以需要让脚本跑5遍。打开“Run-time Setting”对话框,设置脚本运行5次。

 

11、              为了验证每次脚本迭代是否取到了预期的参数,可以调整一下日志内容,显示每次取的参数的内容。设置如下:

 

12、              运行脚本,查看日志。日志中的蓝色部分显示的是每次迭代使用的参数内容。



已有 0人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



机器学习之路

$
0
0

自从答应简二毛博士将自己的机器学习历程和心得分享给大家至今,转眼间半年已经过去了,感谢简博士分享和开源精神的鼓舞,这也正是本系列关于机器学习介绍博客的动力来源。

之前有些网友,师弟们问我,学习机器学习怎么入手,从看什么书开始。这里说一下个人见解:

如果你只愿意看一本书,那么推荐Bishop的PRML,全名Pattern Recognition and Machine Learning. 这本书是机器学习的圣经之作,尤其对于贝叶斯方法,介绍非常完善。该书也是众多高校机器学习研究生课程的教科书,如Deep Learning的开山鼻祖Hilton在多伦多大学教授机器学习课程(CSC2515)时也选择了这本书。该书电子版在Bishop个人网页提供直接下载。不过提前说明一下,这本书如果看了半年,看完三遍才能理解透,也属于正常。第一遍看不懂很正常,所以需要持之以恒。

http://research.microsoft.com/en-us/um/people/cmbishop/prml/

intel_prml

第二本书就是ESL(The Elements of Statistical Learning)。中文翻译叫统计学习基础,其实这个翻译不够准确,Statistical Learning并非statistics,叫机器学习基础更加准确。该书数学推导,理论系统很完备,结合后面的exercise用R语言自己联系一下,对于理解机器学习的基本方法很有帮助,如:Logistic,Ridge regression等。这本书同样可以在作者网站上直接下载到电子版。

http://statweb.stanford.edu/~tibs/ElemStatLearn/

intel_esl

有了理论基础,再结合一些教授的课程进行学习,效果更好。目前很流行的斯坦福大学机器学习公开课,在网易公开课中甚至都有中文版字幕出来,是非常不错的入门教程。不过个人更喜欢Hilton的机器学习课程。因为你看了上述两本书之后,基础知识基本都OK了,再看Stanford公开课还是基础。而Hilton的课程更加贴近目前的学术研究热点,比如对于Neural network,Deep Belief Nets的介绍,他的课程中包括了最早期的RBM的实现 http://www.cs.toronto.edu/~hinton/MatlabForSciencePaper.html 。值得一看。他老人家的课程地址: http://www.cs.toronto.edu/~hinton/csc2515/lectures.html 特别推荐做一做其中的assignments: http://www.cs.toronto.edu/~hinton/csc2515/assignments.html

intel_hinton

 

下面说一下数据集,孔子云“学而时习之”,光说不练是学习的大忌,练习就需要数据集,配合上述课程的数据集是mnist data, http://yann.lecun.com/exdb/mnist/ 这个链接中也可以看到众多大牛在该数据集上的突破。

本系列机器学习之路的内容主要参考来源于:PRML,ESL和Hilton CSC2515。

 

关于软件,是使用Matlab还是R。很难说哪个软件好,哪个不好,只有适不适合自己。R更适合做学术研究,有众多的包和data可以使用,方便快速地实现自己的算法原型。不管是在内置函数的数量还是质量上,尤其处理大量数据时R的确要强于Matlab。同时R还有CRAN,里面基本可以找到绝大多数我们需要的算法,介绍,教程等。

而Matlab强项在于矩阵运算,Matlab也有很多工具箱,里面的算法相对很成熟,Matlab的图形绘图性能也强于R。

二者的区别其实在于商业软件和自由软件的区别。Matlab庞大,成熟,美观,官方文档齐全,当然还有价格不菲。R免费,论坛强大,算法包更新快,紧贴研究的最前沿等等。当然二者可以相互转换,我记得Matlab有执行R语言程序的工具箱,同样R也有运行Matlab程序的包。

总结就是工程人员,更适合Matlab,学术研究还是用R更自由。详细的对比

http://www.math.umaine.edu/~hiebeler/comp/matlabR.pdf

 

机器学习方法

谈到机器学习,一堆概念和方法很容易混淆,比如:VC dimension, least squares, maximum likelihood maximum conditional likelihood,maximum penalized (conditional) likelihood,back propagation,Recurrent networks,Newton and Quasi-Newton Methods,Conjugate Gradients,Constrained Optimization,Mixtures of Experts,Hierarchical mixtures of experts EM Algorithm,PCA, Factor Analysis , Independent Components Analysis,Deep Belief Nets,Restricted Boltzmann Machines,Markov Chain Monte Carlo,Gibbs Sampling,Kernel Methods,kernel density,Association Rules Apriori,Sparse Kernel Machines,Graphical Models

Approximate Inference 等等。

 

在分类这些方法之前,首先描述一下几个概念:

  1. 回归和分类(Regression and Classification), 给定一组输入X和输出Y的数据集S,我们通过回归或者分类方法来拟合数据集S,得到拟合模型F, 当有新的数据输入Xi时,通过拟合模型F来预测输出Yi的值。
  2. 求解方法:在上述拟合模型F的过程中,我们怎么知道什么样的模型是好的,什么样的模型是不好的呢,那么就需要评价函数,有了评价函数之后,我们就需要对该评价函数进行参数求解,使得我们的误差最小,注意,这里的误差最小是针对训练集的数据。
  3. 校验方法:通过上述求解方法得到了我们的求解出的拟合模型F,那么在真实数据中,是否也能够实现误差最小化呢,这里的误差最小是针对真实的测试数据,这个时候我们就需要使用校验方法。
  4. 有些数据集,我们预先知道,或者预先假设好它的分布模型,再进行模型拟合,这个过程叫做有监督的学习(或者针对给定的输入,我们又给定的输出与之相对应)。比如,中国男生身高分布,我们预先设定好其为高斯分布,再进行参数拟合,或者对不同收入阶层的人进行购买力的统计和预测,我们预先假设其满足线性可分,采用线性分类方法,这些都属于有监督的学习。无监督的学习是指给定一组输入,我们没有预先设定的输出和预先设定的模型分布。根据输入变量内在关系进行学习的方法。典型的就是聚类,统计出一组用户的购买物品参数,根据这些参数对用户进行聚类分析,得出其属于重度购买用户还是轻度用户等等。还有如关联规则学习中著名的啤酒与尿布apriori 算法都属于非监督学习算法。
  5. 数据加工方法:如今一个炒作非常火爆的一个概念叫做大数据,凡是和统计学沾边的都自称做大数据的,一个很小的互联网网址做后来数据处理的,也自称做大数据的,如今的社会风气实在让人无语,忍不住吐槽一下。回到正题,当数据量很大,部分数据不够完整,数据维数很高的时候,我们就需要借助于强有力的数据加工方法,其中包括提取有效的主成分,提取相似度高的输入因子等等。
  6. 数据采集方法Sampling:现代计算机的方法,使得产生随机数几乎不需要成本,这就导致了Sampling方法的重大突破。当我们一直模型分布的时候,进行数据采集很方便,预先设定好模型,进行计算机随机数采集跳转获得相应的分布数据即可。但是当模型很复杂,或者我们根本不知道是什么模型的时候,很难适应计算机预先设定好模型进行采集,那么,我们如何获得和真实数据项一致的分布数据进行学习计算呢,这个时候就需要我们的Sampling方法派上用场了。

有了上述基本概念之后,我们就对一堆机器学习的概念机械归纳和分类:

  1. 回归和分类模型有:Liner  regression,Logistic regression, Ridge regression, Lasso, Linear Discriminant Analysis,Basis Expansions,Smoothing Splines, Kernel Methods, Additive Models, Trees,Nearest-Neighbors Methods, SVM 等等,这些只是大致的方法,里面还包括了各种细致的算法,如Trees中包括 Classification trees, Random Forest 等等
  2. 求解方法:最常见的Least Square,在这上面依次有maximum likelihood,EM, Gradient Descent等。其中Gradient Descent又包括Classic Newton methods, Quasi-Newton Methods等等。
  3. 校验方法最常见是交叉验证(Cross Validation),其中包括留一验证(LOOCV),K-Fold CV, Boostrap 等等。
  4. 无监督的学习方法主要有:关联规则,聚类,自组网,主成分分析,因子分析,独立成分分析,已经如今很热门的Page Rank, deep Learning都属于无监督学习的一种。大多是的分类和回归模型都是有监督的学习或者半监督的学习。
  5. 数据加工的方法主要有: 如收缩法的Ridge regression , Lasso, 降维法的PCA,ICA特征提取的因子分析等
  6. 数据采样方法有:Bagging,Boosting,MCMC(Markov Chain Monte Carlo), Gibbs Sampling等
  7. 神经网络,之所以把神经网络单独分类主要是因为神经网络包罗万象,既可以属于有监督学习,有可以属于无监督学习,既可以是分类,也可以是回归,很难将其分在哪一类,所以干脆以后单独介绍。

声明

本系列介绍系本人的学习体会,难免有不足和错误,还望广大网友指正。比如也有的地方将Boosting总结为基于树的分类模型,只是个人觉得Boosting的思想更像是Sampling,所以将其归纳在采样方法中。开篇介绍到此,之后有空本系列会陆续更新,力求简要介绍各种常见的学习方法和学习策略。也欢迎广大网友共同探讨。

本系列参考:

http://research.microsoft.com/en-us/um/people/cmbishop/prml/

http://statweb.stanford.edu/~tibs/ElemStatLearn/

http://www.cs.toronto.edu/~hinton/csc2515/lectures.html

 

本文转载自: https://software.intel.com/zh-cn/blogs/2014/07/28

drbd性能测试及调优

$
0
0
今天在qq群里,有个哥们说千万不要用drbd做mysql的HA,说对性能影响非常大,drbd对性能有影响是肯定的,把数据通过网络发送给对端备库必定有性能损耗,而我正好有一套drbd,借此测试一把,看看drbd对性能的影响到底有多大,也给网友一个参考。

我测试的是一套两节点的drbd+pacemaker+corosync的mysqlHA高可用集群,主机都是普通的过时的pc机,内存2g,cpu 2核。

1.首先使用sysbench对正常状态的集群初始化数据:
[root@topdb ]# sysbench --test=oltp --oltp-table-size=5000000 --mysql-host=192.168.1.163 --mysql-port=3306 --mysql-user=root --mysql-password=123456 --mysql-db=mcldb --db-driver=mysql prepare
初始化的时候可以用dstat命令看看主备的压力:
主库:
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw 
  5   4  41  51   0   0|  80k   19M| 959k 9388k|   0     0 |5697    13k
  4   5  44  47   0   1|  88k   15M| 963k 9474k|   0     0 |4845    10k
  7   4  36  53   0   0|   0    16M| 326k 9048k|   0     0 |5324    12k
  8   3  41  47   0   1|   0    18M| 939k 8708k|   0     0 |5963    12k
  7   4  30  59   0   0|   0    21M| 975k 9659k|   0     0 |5763    14k
...
  6   5  42  48   0   0|   0    17M|1389k 7702k|   0     0 |5524    13k
 10   3  39  48   0   0|   0    17M| 380k   10M|   0     0 |5198    11k
  4   3  45  48   0   1|   0    19M| 950k 8993k|   0     0 |6003    14k
  5   4  43  48   0   0|   0    13M| 991k   10M|   0     0 |4863    11k
   
--备库:
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw 
  9   5  86   0   0   1|   0  8580k|9114k  319k|   0     0 |  12k   14k
  4   3  92   0   0   1|   0  7572k|7992k  280k|   0     0 |9422    12k
  0   3  96   0   0   1|   0  8348k|8842k  309k|   0     0 |  10k   14k
  0   2  97   0   0   1|   0  7544k|7988k  279k|   0     0 |9351    12k
  0   3  96   0   0   1|   0  9164k|  10M  345k|   0     0 |  12k   14k
  0   3  97   0   0   1|   0  8180k|8232k  293k|   0     0 |9662    13k
 ...
  0   3  97   0   0   1|   0  8544k|9036k  314k|   0     0 |  10k   14k
  0   3  96   0   0   1|   0  7672k|8123k  285k|   0     0 |9543    12k
  0   3  97   0   0   1|   0  8888k|9448k  327k|   0     0 |  11k   14k^C
可以看出,主库每秒要写10几兆左右,网络发送也要将近10M,从库写每秒7M-9M左右,网络接收也和写操作的速率差不多
查看下sysbench的测试表的大小:
[root@db163 mcldb]# du -sh sbtest.*
12K sbtest.frm
1.2G sbtest.ibd

2.测试drbd集群状态的性能:
采用复合模式,即增删改查模式:
[root@topdb ~]# sysbench --oltp-auto-inc=off --max-requests=0 --max-time=60 --num-threads=4 --test=oltp --db-driver=mysql --mysql-host=192.168.1.163 --mysql-port=3306 --mysql-user=root --mysql-password=123456 --mysql-db=mcldb --oltp-test-mode=complex run
sysbench 0.4.10:  multi-threaded system evaluation benchmark

WARNING: Preparing of "BEGIN" is unsupported, using emulation
(last message repeated 3 times)
Running the test with following options:
Number of threads: 4

Doing OLTP test.
Running mixed OLTP test
Using Special distribution (12 iterations,  1 pct of values are returned in 75 pct cases)
Using "BEGIN" for starting transactions
Not using auto_inc on the id column
Threads started!
Time limit exceeded, exiting...
(last message repeated 3 times)
Done.

OLTP test statistics:
    queries performed:
        read:                            11130
        write:                           3975
        other:                           1590
        total:                           16695
    transactions:                        795    (13.21 per sec.)
    deadlocks:                           0      (0.00 per sec.)
    read/write requests:                 15105  (251.06 per sec.)
    other operations:                    1590   (26.43 per sec.)

Test execution summary:
    total time:                          60.1639s
    total number of events:              795
    total time taken by event execution: 240.4650
    per-request statistics:
         min:                                100.55ms
         avg:                                302.47ms
         max:                                889.42ms
         approx.  95 percentile:             614.07ms

Threads fairness:
    events (avg/stddev):           198.7500/3.90
    execution time (avg/stddev):   60.1163/0.03
可以看出,1分钟内请求了16695次查询,tps为13.21(不足为奇,我的机子就比较烂)

3.测试单机状态的性能:
把备库离线:
[root@db162 ~]# crm 
crm(live)# status
Last updated: Mon Jul 28 18:23:32 2014
Last change: Sat Jul 26 10:05:58 2014 via cibadmin on db163
Stack: classic openais (with plugin)
Current DC: db163 - partition with quorum
Version: 1.1.10-14.el6_5.3-368c726
2 Nodes configured, 2 expected votes
7 Resources configured
Online: [ db162 db163 ]
 Master/Slave Set: ms_drbd_mysql [drbd_mysql]
     Masters: [ db163 ]
     Slaves: [ db162 ]
 Resource Group: g_mysql
     fs_mysql (ocf::heartbeat:Filesystem): Started db163 
     p_ip_mysql (ocf::heartbeat:IPaddr2): Started db163 
     mysqld (lsb:mysqld): Started db163 
 Clone Set: cl_ping [p_ping]
     Started: [ db162 db163 ]
crm(live)# node standby db162 

再来看下主库drbd的状态:
[root@db163 mcldb]# cat /proc/drbd
version: 8.4.4 (api:1/proto:86-101)
GIT-hash: 599f286440bd633d15d5ff985204aff4bccffadd build by phil@Build64R6, 2013-10-14 15:33:06
 0: cs:WFConnection ro:Primary/ Unknown ds:UpToDate/ DUnknown C r-----
    ns:6074648 nr:0 dw:6075004 dr:294960 al:466 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:308  
确实已经不在同步数据了,下面再来测试:
[root@topdb ~]# sysbench --oltp-auto-inc=off --max-requests=0 --max-time=60 --num-threads=4 --test=oltp --db-driver=mysql --mysql-host=192.168.1.163 --mysql-port=3306 --mysql-user=root --mysql-password=123456 --mysql-db=mcldb --oltp-test-mode=complex run
sysbench 0.4.10:  multi-threaded system evaluation benchmark

WARNING: Preparing of "BEGIN" is unsupported, using emulation
(last message repeated 3 times)
Running the test with following options:
Number of threads: 4

Doing OLTP test.
Running mixed OLTP test
Using Special distribution (12 iterations,  1 pct of values are returned in 75 pct cases)
Using "BEGIN" for starting transactions
Not using auto_inc on the id column
Threads started!
Time limit exceeded, exiting...
(last message repeated 3 times)
Done.

OLTP test statistics:
    queries performed:
        read:                            16394
        write:                           5851
        other:                           2340
        total:                           24585
    transactions:                        1169   (19.45 per sec.)
    deadlocks:                           2      (0.03 per sec.)
    read/write requests:                 22245  (370.14 per sec.)
    other operations:                    2340   (38.94 per sec.)

Test execution summary:
    total time:                          60.0990s
    total number of events:              1169
    total time taken by event execution: 240.2136
    per-request statistics:
         min:                                 73.11ms
         avg:                                205.49ms
         max:                                741.33ms
         approx.  95 percentile:             432.89ms

Threads fairness:
    events (avg/stddev):           292.2500/3.34
    execution time (avg/stddev):   60.0534/0.03
确实有drbd的话,性能损耗了(1-16695/24585)= 32%,但目前drbd没有调优,下面调整下drbd的参数,再来测试
4.调优drbd后测试性能:
先还原drbd备库:
[root@db162 ~]# crm
crm(live)# node online db162
crm(live)# status
Last updated: Mon Jul 28 18:45:16 2014
Last change: Mon Jul 28 18:45:30 2014 via crm_attribute on db162
Stack: classic openais (with plugin)
Current DC: db163 - partition with quorum
Version: 1.1.10-14.el6_5.3-368c726
2 Nodes configured, 2 expected votes
7 Resources configured


Online: [ db162 db163 ]

 Master/Slave Set: ms_drbd_mysql [drbd_mysql]
     Masters: [ db163 ]
     Slaves: [ db162 ]
 Resource Group: g_mysql
     fs_mysql (ocf::heartbeat:Filesystem): Started db163 
     p_ip_mysql (ocf::heartbeat:IPaddr2): Started db163 
     mysqld (lsb:mysqld): Started db163 
 Clone Set: cl_ping [p_ping]
     Started: [ db162 db163 ]

[root@db162 ~]# cat /proc/drbd 
version: 8.4.4 (api:1/proto:86-101)
GIT-hash: 599f286440bd633d15d5ff985204aff4bccffadd build by phil@Build64R6, 2013-10-14 15:33:06
 0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----
    ns:0 nr:38064 dw:38064 dr:0 al:0 bm:18 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
可以看出,drbd又还原回来了,现在又开始了数据同步。
调整优化drbd参数:
[root@db163 ~]# vim /etc/drbd.d/global_common.conf 
 disk {
                on-io-error detach;
                disk-flushes no;
        }
        net {
                max-buffers 8000; #增大缓存区为8000
                max-epoch-size 8000;
                sndbuf-size 0; #是sendbuffer自动调整
        }
        syncer {
        rate 10M; #我的是百兆带宽,所以调整10M就行了
        al-extents 257; #增大活动日志区为257个
        }
common {
        protocol C; #协议仍采用C,即主要把数据发送到从的tcp缓存区才算完成,这是最安全严格的方式了。
 }
把文件也拷贝到从上面:
[root@db163 ~]# scp /etc/drbd.d/global_common.conf db162:/etc/drbd.d/
global_common.conf                                                                                 100% 2181     2.1KB/s   00:00    
主备都在线调整下配置文件:
[root@db163 ~]# drbdadm adjust all
[root@db162 ~]# drbdadm adjust all
再来测试:
[root@topdb ~]# sysbench --oltp-auto-inc=off --max-requests=0 --max-time=60 --num-threads=4 --test=oltp --db-driver=mysql --mysql-host=192.168.1.163 --mysql-port=3306 --mysql-user=root --mysql-password=123456 --mysql-db=mcldb --oltp-test-mode=complex run
sysbench 0.4.10:  multi-threaded system evaluation benchmark

WARNING: Preparing of "BEGIN" is unsupported, using emulation
(last message repeated 3 times)
Running the test with following options:
Number of threads: 4

Doing OLTP test.
Running mixed OLTP test
Using Special distribution (12 iterations,  1 pct of values are returned in 75 pct cases)
Using "BEGIN" for starting transactions
Not using auto_inc on the id column
Threads started!
Time limit exceeded, exiting...
(last message repeated 3 times)
Done.

OLTP test statistics:
    queries performed:
        read:                            16366
        write:                           5845
        other:                           2338
        total:                           24549
    transactions:                        1169   (19.45 per sec.)
    deadlocks:                           0      (0.00 per sec.)
    read/write requests:                 22211  (369.46 per sec.)
    other operations:                    2338   (38.89 per sec.)

Test execution summary:
    total time:                          60.1174s
    total number of events:              1169
    total time taken by event execution: 240.1222
    per-request statistics:
         min:                                 70.51ms
         avg:                                205.41ms
         max:                                685.97ms
         approx.  95 percentile:             413.63ms

Threads fairness:
    events (avg/stddev):           292.2500/5.45
    execution time (avg/stddev):   60.0306/0.05
这次测试的tps为19.45,和单机测试的tps是一样的,也就是drbd对性能几乎没有影响了。

5.dd测试:
由于数据库都是小io,多随机读写,对吞吐量测试不了,我再测试下大数据块的写入及传输速度:
[root@db163 data]# dd if=/dev/zero of=/data/dd.test bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB) copied, 341.432 s, 12.6 MB/s
其中/data是我的drbd磁盘,在drbd网络传输的情况下,速度为12.6MB/s
下面关闭备节点,再来测试:
[root@db162 ~]# crm node standby
[root@db163 data]# cat /proc/drbd 
version: 8.4.4 (api:1/proto:86-101)
GIT-hash: 599f286440bd633d15d5ff985204aff4bccffadd build by phil@Build64R6, 2013-10-14 15:33:06
 0: cs:WFConnection ro:Primary/Unknown ds:UpToDate/DUnknown C r-----
    ns:10309484 nr:0 dw:10407952 dr:533640 al:1514 bm:18 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:65724
[root@db163 data]# dd if=/dev/zero of=/data/dd.test2 bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB) copied, 81.3911 s, 52.8 MB/s
速度为52MB/s,不过这也是正常的,因为单机情况下dd都是写到缓存中了,drbd集群状态下速度为12.6M/s已经是网络带宽的最大容量了,因此写入速度受限于带宽而不是磁盘。如果在生产者用千兆内网,网络应该不成问题,对主库性能应该不会造成多少影响。而且将来drbd模块会集成到linux内核中,所以drbd确实性能还是可以的。

移动应用开发者之间的中间阶级已经消失

$
0
0
市场研究公司VisionMobile的调查显示,全世界290万应用开发者开发了约200万应用,但绝大部分开发者收入几乎为零,几乎全部收入都被最流行的应用囊括,中间阶级已经消失,应用经济就像是华尔街的镜像。42%的应用开发者使用HTML5开发应用,其次是Java的38%;50%的iOS 开发者和64%的Android开发者每月收入低于500美元;33%的开发者制作的是游戏,但其中57%的游戏每月收入低于500美元;6%的Android开发者和11%的iOS开发者每月收入超过2.5万美元。一位应用开发者称,他开发的最赚钱的应用是十多年前功能机上运行的BREW应用。






Viewing all 15843 articles
Browse latest View live