这东西叫 here document

#12 楼 @bhuztez 这。。明显 1.9！= 2 嘛！

#10 楼 @bhuztez 其实和 1.9 差不多。。

看到英文招聘就直接 Pass。。

#8 楼 @bhuztez

ruby 2.0.0dev (2012-06-30 trunk 36257) [x86_64-linux]
total cast time:5.928291172
total cast time:2.927292006

ruby 1.8.7 (2011-02-18 patchlevel 334) [x86_64-linux], MBARI 0x6770, Ruby Enterprise Edition 2011.03
total cast time:12.951016
total cast time:19.63892

真的太烂了吧。。。我的机器开个 Netbeans 都卡还能跑成这样呢，没少零。

呃，，这结果对比也说明了不同 Ruby 实现哪个快是不一定的:-)

Sinatra 不是更可以 Bundler 么？ 好吧，其实 Bundler 是做依赖隔离的，，快速安装只是依赖声明的一个副产品。。 从以前的帖子也可以看出来大部分用 Rails 的也搞不清楚为什么用 Bundler。

#6 楼 @hhuai 其实这个很难从理论上分析哪个快的，不同的 Ruby 实现或许还不一样。。所以根本不用考虑，，，当需要考虑 Ruby 里用 for 还是 while 能提高性能的时候，那么还是别用 Ruby 算了。

#15 楼 @bhuztez 你说的是理想情况。但是目前 CRuby 的 GC 不是 copy on write friendly 的。目前只有 REE 是。

It is observed that a lot of memory in Ruby on Rails applications is taken by AST nodes (of both the Rails framework and the application source). People generally run multiple Rails application instances (application servers) to serve a Rails website. If the different Rails application instances can share the memory of the AST nodes with each other, much like how C/C++ programs/libraries share program code with each other, then it will result in significant reduction of memory usage.

The POSIX API allows one to implement this, by using the fork() system call. On modern Unix implementations (Linux, FreeBSD, MacOS X, whatever), a child process created by fork() shares most of its memory with its parent process. If one forks a 500 MB process, it will not result in 1 GB memory usage, but probably like 500.1 MB. When the child process (or the parent process) writes to a piece of memory, then that memory is copied, preventing the parent and child process from writing to each others' memory. This process is called "copy-on-write".

However, Ruby's garbage collector is not copy-on-write friendly. Its mark-and-sweep algorithm implementation stores the mark bit directly inside objects. A garbage collection cycle will thus result in all objects being written to (or in operating systems jargon: the memory pages of the objects are made dirty). The OS will copy all that memory, thus negating the effect of copy-on-write.

http://ruby-china.org/topics/755

#9 楼 @bhuztez 线程不安全就只能用多进程方式部署啊，没有了共享内存，部署的进程越多浪费的内存越大。 所以现在还有那么多人用 REE 就是因为 CoW。

#6 楼 @leozwa 哇 好萌。

#3 楼 @yggg 这个不错！thx！

#1 楼 @yggg 类似这个。是生成真实的图片，不像这种很难看:-)

1.8.6...

这又有什么意义呢？难道做性能优化的时候要把 each 换成 for，把 for 换成 while？

crop 就行了

什么样的白边？可以传个图上来么

还有，如果想重新创建环境用 bundle exec rake db:schema:load

在生产环境执行这个看看结果： bundle exe rake db:migrate:status

咦，楼主好像在哪见过你。。。

02-08

#13 楼 @xds2000 这个作者貌似一直使用 Rails3.1，不知道现在支不支持 Rails3.2 了。

像 Page cache 和 Action cache 这样的大粒度的缓存很少会在实际环境中用到。 Fragment Cache 是最常用的，不过也要粒度适中，片段 的粒度过大会失效频繁。表结构设计很重要，直接决定了缓存的清理复杂度。常用的过期策略就是基于某个对象的 Etag 和 Last Modified 来保持缓存于实际数据同步。

基于时间的过期策略我不太喜欢用，会有很长一段时间数据是不同步状态的，并且赶上缓存失效那一刻会非常痛，除非需求就是如此，或是不用性能就会达到不可接受的地步。

我觉得在设计的时候就不应该依赖于这种策略。

片段缓存只用于页面。

Rails 里另一个重要的缓存就是 Counter Cache。

几乎有 count 的地方都可以用到 counter cache。不过 counter cache 也不是万能的，对软删除或有状态标识的表也没办法。只能自己去维护 counter。

有一个叫 counter cache with condition 的插件，不过不太好用。大家有兴趣可以一起来搞一个。

ActiveRecord 的 QueryCache，这个属于 Rails 里的一个锁定技能，虽然大家都没有手动使用，但是这东西作用还蛮大的，它能把一个请求内的相同 SQL 查询结果缓存起来，保证一次请求之间相同的 SQL 只执行一次。

还有对象缓存，目前 Iteye 的缓存插件还是用的@quakewang 写的二级缓存插件 。在主键查询的时候自动缓存结果（Read Through），下次查询时先从缓存取记录，在记录更新删除的时候自动过期。

正在开发针对 Rails3 项目的类似 CacheMoney 的实现,一个 Read Through 和 Write Through 的缓存插件，并且比 CacheMoney 轻量级一些。不过还未在线上运行。

还有一些其他的技巧，比如Memoize，用 redis 的 sorted set 做实时积分排名。

还有数据库的冗余列优化，但是冗余字段随着会带来额外的维护成本，最近在开发一个自动维护冗余列的插件。

总之，我在做缓存设计主要考虑的几个因素： 1.缓存粒度一定要小，更小的粒度意味着失效的概率更低，命中率就更大。 2.一定要保持缓存和实际记录的一致性。不一致的缓存会导致很多不必要的问题。 3.不应该依赖缓存，缓存的过期频率是不可预测的，上一秒存进去的东西你都不能保证下一次取的时候在不在。 4.查询和排序优先考虑利用索引，实在没办法才考虑缓存。

@fleuria 你房子找到没有？可以和楼上合租哇。。

#91 楼 @jasl 自愿加班。。你们好高尚～

render

"%.1f" % 99.90000000000001