|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-03-28
RoR技术上是不错的，但是，这种版本管理方式，只能给RoR使用者带来应用风险。
随随便便的release是不应该的。。。 还是年轻气盛啊。。。 |
| 返回顶楼 | |
|
发表时间：2009-03-29
robbin 写道 murainwood 写道 Rails是个好东西，开发团队不行，如果能被大公司收购，会不会能好些？
rails core team的能力没的说，创新能力非常出众，每次新版本都会有令用户意想不到但是非常有用的创新功能推出，而且能够连续多年，持续高产的创新，这本身就是惊人的成就。rails在web框架领域的创新能力，总是让我想起苹果在消费电子领域的创新能力。可以这样说，在web开发框架领域，rails把其它所有竞争对手，包括python的那些知名框架，甩开了不知有多少条街的差距，是无可争议的王者。任何想要选择web快速开发框架，重视生产力的开发者，rails都是唯一的选择。 当然rails并不完美，不过对我来说都还可以接受，真正让人受不了的是core team对新版本升级无比的热衷，但是对老版本的维护却不闻不问。这样的话对于一些强调稳定性、兼容性和高负载的web应用，就必须自己亲自解决一些rails框架升级速度过快带来的维护方面的缺失。 要解决这个问题在于core team自己的态度，是不是可以拿出更多的精力放在老版本维护上面，放慢一些版本创新和升级的速度呢？我觉得以现在的rails的功能性来说，已经超越其它web框架若干年的水准了，没必要再玩命的创新和升级了，这样做固然把竞争对手甩的越来越遥远，但是也把自己的用户玩死了，多花点精力维护老版本，对rails本身的应用普及更有好处。 我有点想说，玩死你们 |
| 返回顶楼 | |
|
发表时间：2009-03-29
ychael 写道 robbin 写道 murainwood 写道 Rails是个好东西，开发团队不行，如果能被大公司收购，会不会能好些？
rails core team的能力没的说，创新能力非常出众，每次新版本都会有令用户意想不到但是非常有用的创新功能推出，而且能够连续多年，持续高产的创新，这本身就是惊人的成就。rails在web框架领域的创新能力，总是让我想起苹果在消费电子领域的创新能力。可以这样说，在web开发框架领域，rails把其它所有竞争对手，包括python的那些知名框架，甩开了不知有多少条街的差距，是无可争议的王者。任何想要选择web快速开发框架，重视生产力的开发者，rails都是唯一的选择。 当然rails并不完美，不过对我来说都还可以接受，真正让人受不了的是core team对新版本升级无比的热衷，但是对老版本的维护却不闻不问。这样的话对于一些强调稳定性、兼容性和高负载的web应用，就必须自己亲自解决一些rails框架升级速度过快带来的维护方面的缺失。 要解决这个问题在于core team自己的态度，是不是可以拿出更多的精力放在老版本维护上面，放慢一些版本创新和升级的速度呢？我觉得以现在的rails的功能性来说，已经超越其它web框架若干年的水准了，没必要再玩命的创新和升级了，这样做固然把竞争对手甩的越来越遥远，但是也把自己的用户玩死了，多花点精力维护老版本，对rails本身的应用普及更有好处。 我有点想说，玩死你们 真正玩死人的是不能把事干掉的东西. |
| 返回顶楼 | |
|
发表时间：2009-03-30
其实很多开源项目都有类似的版本升级太快，旧版本维护不力的问题。
因此应用一个开源产品（特别是那种由社区推动的开源产品）的时候，很重要的一点就是参与到这个社区，理解这个社区的文化。 很多年前，因为一个项目的需要第一次开始写Linux内核驱动，那个时候天天在骂娘，怎么内核API老在变，怎么就不能考虑向下兼容呢？....当后来逐渐理解内核开发社区的文化之后就再也没有抱怨了。 我相信rails社区肯定也存在某种特定的文化驱动当前rails的发展模式。既然要用它，就应该顺应它的文化。 |
| 返回顶楼 | |
|
发表时间：2009-03-30
memcache-client 1.7.1 发布
* Performance optimizations: * Rely on higher performance operating system socket timeouts for low-level socket read/writes where possible, instead of the (slower) SystemTimer or (slowest, unreliable) Timeout libraries. * the native binary search is back! The recent performance tuning made the binary search a bottleneck again so it had to return. It uses RubyInline to compile the native extension and silently falls back to pure Ruby if anything fails. Make sure you run: `gem install RubyInline` if you want ultimate performance. * the changes make memcache-client 100% faster than 1.7.0 in my performance test on Ruby 1.8.6: 15 sec -> 8 sec. * Fix several logging issues. |
| 返回顶楼 | |
|
发表时间：2009-03-30
想到那个美国系列剧“成长的烦恼”，剧情很有趣也很精彩。
ｒａｉｌｓ是一个革新的ｆｒａｍｅ，应该多点耐心，多上点心。 ｒａｉｌｓ是最贴近ａｇｉｌｅ的框架之一，很值得投入和期待。 |
| 返回顶楼 | |
|
发表时间：2009-04-15
看到社区有人在讨论这个问题了。http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/fb60e23a7d345a81?hl=en
有人给出了个答案，不知道是不是这样： I've added a FAQ entry explaining what is going on. 1.6+ is much faster than 1.5.0 only when multiple servers are being used. I'm guessing your benchmark is testing just localhost:11211. http://github.com/mperham/memcache-client/blob/d5ae15d362c379c3a6692e... Simple answer, turn off socket timeouts in order to dramatically speed up memcache-client but realize you might be woken up at 3am when production melts down, as I was. mike |
| 返回顶楼 | |
|
发表时间：2009-04-15
最后修改：2009-04-15
the new memcache-client is slower than 1.5.0!?
Yes, in the simplest case, 1.6.x+ is slower than 1.5.0. If you just have a single memcached server, the latest memcache-client will be significantly slower. This is because 1.5.0 does not timeout network operations. For reliability purposes, memcache-client 1.6.x+ enables timeouts by default. Unfortunately Ruby’s network timeout options are not very performant. If you want timeouts, the best you can do currently is install the SystemTimer gem, which will approximately halve the overhead incurred by timeouts. If you need ultimate speed, you can disable timeouts or use Fauna’s memcached library which moves most of the client into native C. (Hint: if you are looking for a fun tuning project and are good with C, the SystemTimer gem has a lot of room for improvement in performance.) If you are using multiple memcached servers, 1.6.x+ will be much faster than 1.5.0 as 1.5.0 had an extremely slow hashing function to map a key to a server. Overall, production environments with multiple servers should see performance and reliability improvements in memcache-client 1.6.x+. |
| 返回顶楼 | |
|
发表时间：2009-04-15
genki 写道 看到社区有人在讨论这个问题了。http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/fb60e23a7d345a81?hl=en
我测试过2.3带的那个版本memcache-client，设置timeout为nil和2.2相比还是有不小的性能差距（robbin在文章中也提到了） 从讨论中看，也提到了基于c的libmemcached，我测试下来这个库的性能是最好的（基于单台cache server），可是解决了这个client问题最终以后还是从2.3回退了，我们的应用64位操作系统上用2.3跑，平均每个进程要240M，而2.2只要190M，开20个进程就要多1G内存，服务器资源有点紧张。 不过换了client以后，从单个进程能够处理的请求数目来看2.3比2.2又有少许提高(5%左右)，如果你的服务器资源不是限制的话，可以考虑升级到2.3。 |
| 返回顶楼 | |
|
发表时间：2009-04-16
问robbin一个memcache的问题
一个数据量庞大的留言列表,默认只显示三个月内的留言,还有 一个星期内的留言,一个月内的留言,三个月内的留言,三个月到一年的留言,一年到二年的留言 (两年以后的留言删除),这样的时间段缓存如何实现? 我使用的是memcached,IBatis,Spring,MySQL,我目前的方案是选择一个星期的时候,封装一个星期做参数到一个map中(还包括其他参数),同样一个月做参数封装到一个map中,三个月的map,这三个map通过IBatis拿值并做精确缓存,在做添加,修改等操作时实时更新缓存,制约三个月到一年,一年到二年可以非精确缓存 ,这样的方案有没问题,不知道你有更好的方法吗? |
| 返回顶楼 | |
