• 各类工具的性能分析都能看到我楼上说的这篇论文中提到的解决问题的思路,Oracle的自带的性能分析工具自然不必说;Openresty作者经常会发的火焰图也是一个例子;Percona Toolkit里面的pt-query-digest出来的结果也是这种思路;甚至于最简单的strace工具加上-c的参数也会做一个花费时间从高到低的统计结果给你。大家可以先看下上面提到的论文,然后在看下我上面提到的这几个工具,自己去试用一下,然后你就知道我在说什么了。

    下面给个strace -cp <pid>做nginx分析的输出给大家感受下:

    ~# strace -cp 1926
    Process 1926 attached - interrupt to quit
    ^CProcess 1926 detached
    % time     seconds  usecs/call     calls    errors syscall
    ------ ----------- ----------- --------- --------- ----------------
     89.10    0.000711           0      2989           epoll_wait
      5.89    0.000047           0       802           close
      2.63    0.000021           0       552           writev
      1.38    0.000011           0      3014      1305 read
      1.00    0.000008           0      2203           epoll_ctl
      0.00    0.000000           0      2036           write
      0.00    0.000000           0       100         2 open
      0.00    0.000000           0         6           stat
      0.00    0.000000           0        98           fstat
      0.00    0.000000           0         3           mmap
      0.00    0.000000           0         3           munmap
      0.00    0.000000           0       394           ioctl
      0.00    0.000000           0        65           pread
      0.00    0.000000           0       414           readv
      0.00    0.000000           0        12           sendfile
      0.00    0.000000           0       394           socket
      0.00    0.000000           0       394       394 connect
      0.00    0.000000           0       829        21 recvfrom
      0.00    0.000000           0         1           shutdown
      0.00    0.000000           0       272           setsockopt
      0.00    0.000000           0       397           getsockopt
      0.00    0.000000           0      2989           gettimeofday
      0.00    0.000000           0         1         1 futex
      0.00    0.000000           0       298           accept4
    ------ ----------- ----------- --------- --------- ----------------
    100.00    0.000798                 18266      1723 total
    
  • 我看了半天也没找到有价值的信息

    同意这句话,要解决性能问题,首先要做的就是找到性能瓶颈,然后针对瓶颈的地方进行分析,看看这个瓶颈的问题是否可以解决,而不是在这里猜测是不是没有用连接池?还是rails性能差?或者服务器的问题等等。找瓶颈的思路也不难,对于程序级别就是埋点分析每一步的执行时间,看看哪一步占的时间长。

    请大家研究性能问题之前一定好好的读几遍性能分析的圣经级别的论文《Thinking Clearly about Performance》,由Oracle大牛Cary Millsap在10年左右写的通俗易懂的关于分析性能问题思路的。相信我,看完这论文之后肯定对于性能分析有一个更清晰的思路和认知。

  • 让爬虫轻松一点~(一) at 2013年12月22日

    楼主这是先在前面使劲的刨一个大坑,然后纵身往下一跃……

    不得不赞一个

  • 很遗憾看到imax.im关了,我年初也有尝试类似项目想法,研究的过程中发现了imax.im已经把我想做的事情都做了,然后就放弃了。尽管项目停了,不知道@huacnlee 同学能不能分享下运营imax.im的经验,让大家学习下。

  • 数据库都设计有数据缓存的机制,倾向是你给多少内存就用多少的,所以不能单以占用内存大小来判断是否正常。

  • 根据个人经验来说抽筋的原因其实很简单:运动太少了。解决方法就是经常锻炼就好了。

    多年以前第一次徒步10KM的时候脚抽筋到要死掉的感觉,那会儿游泳半小时必抽筋。当时各种找抽筋原因,补钙啊,运动前热身什么的,没用。后来坚持运动,现在跑步10KM很轻松,游泳也不再抽筋。

    当然运动之前拉伸一下能更好的防止运动受伤。

    ---补充一下---- 大部分抽筋实际上是人体对于超出自己舒适范围的运动的正常反应,告诉你该休息了。比如说一个人经常跑5KM,那他的运动舒适区可能会在5~10KM之间,如果猛然去跑20KM的时候也会抽筋的。所以一般在进行远远超出舒适区的运动的时候都要逐步训练提高运动量,比如说对于经常跑10KM的人来说如果要跑马拉松的话那他必须要从2~3个月前开始逐步提高每次的跑量,最后必须在马拉松跑前几周内跑一次35KM左右的训练这样在跑马拉松的时候脚才不容易抽筋。

  • jQuery只是一个库而已,只能让你简化一些操作,即使是在使用了jQuery的情况下会js也是必须的,严格来说写Chrome插件和做网页写js是不会有太大的差别的,只是在写Chrome插件的时候需要遵循一些特定的规则和使用一些特定的api接口。 现在Chrome商店里面看到的插件基本都用到了jQuery,因为这东西能让工作变得简单很多。 正确的方法是按照你的需求去学,在写插件的过程中如果jQuery能解决的用jQuery解决,如果不行则自己用js解决,没有必要把js的东西都仔细学一遍,也没有必要吧jQuery的东西都仔细学一遍。 在实践中学习。

  • 请进来跪拜朝鲜程序员.... at 2013年04月26日

    这……

    显然是个推广贴。。。

  • 感谢楼上回复。

    看来问题的关键还是在于application.css里面的require_tree .,这东西会造成stylesheets里面的各种css重复加载,从而导致错误的产生。

    在这里找到一个说明Customizing Twitter Bootstrap On Rails 3

  • #1楼 @yesmeck 感谢你提供的代码,试了一下关键不是import两个文件的位置,而是需要在bootswatch.less中增加

    @import "twitter/bootstrap/bootstrap";
    @import "variables";
    

    不过我还是不明白这些东西的处理顺序是什么,为什么要这么加。