※ 引述《lintingy (4/9 热舞成发在新体! 4/9)》之铭言： : 环境： : Ruby 1.8.7 : Rails 3.0.7 : 状况： [...] 大哉问 XD : 1. rails default使用single thread的原因是什麽？ : 要能够让很多使用者同时使用网站但却用single thread，这不会很矛盾吗？ 这个问题有很多很多的层面，以我个人主观的说法是，rails 打从一开始就没写好， 不是个 thread-safe 的 framework. concurrency 的作法有很多种，threaded 只是 其中一种。另外大致上分成 multi-process (fork) 和 event-driven (evented). 最早 rails 是走 multi-process 的路，不管是用 fast-cgi 或 mongrel. 这种作法的优点是，程式很好写，因为根本就不用去管 thread-safety, 也就是 可以大量使用有 state 有 side-effect 的暴力写法。对不太擅长写程式的人而言， 这也是最简单的作法。 後来 rails 终於变成 thread-safe 了，但预设还是会做 lock, 我没记错的话。 因为大部份的 rails application 仍然不是 thread-safe, 跑 multi-thread 还是 会烂掉。 至於如果你想用 evented-rails 或 threaded-rails, 主要要注意的是 server 本身得支援才行。而这两种作法，都得保证你自己的程式也是 thread-safe 或 async-safe 等等，有很多技术细节要讨论。 : 2. 丢到background去处理，跟想办法让rails server变成multithread， : 这两种方式有哪一种会比较建议吗？ 这两个解决的问题是不同的。丢到 background 处理，server 得先回应 client. 反之如果是 threaded 或 evented, server 可以等到有结果後才回应 client. 因此问题是，能不能先回应 client? 如果这不是个重要的问题的话，我会建议先走 background (worker), 因为这种作法比较单纯简单，而且以後总是用得到。 不过不管怎麽样，这两种作法并不是互斥，能走 threaded 或 evented 还是比较好。 （技术难度也高很多） : 3. 那如果用background执行的方式，要怎麽样知道他已经处理完了？ : (因为处理完後要马上给使用者feedback) : (而之前有用过fork处理类似问题， : 但是这麽一来就没有办法知道他已经处理完了， : 後续的显示就不知道该怎麽接上...) fork 应该还是能知道他处理完了，不过在这边用 fork 应该不太对... 总而言之，这边会变成两种作法... 也就是常见的 poll 或 push 了。 只是要能动的话，可以先找各种 poll 的方法，效能不佳的话再看 push, 再不行再试 threaded 或 evented, 因为这难度最高，所以最後试... : 4. 最後则是说，如果要实做rails server的multithread， : 有没有建议的方式？ rails 里有个 config.threadsafe! 要打开，然後 server 本身也要跑 thread, 比方说 Rainbows! 的各种 thread model: http://rainbows.rubyforge.org/ ThreadPool for 1.9: http://rainbows.rubyforge.org/Rainbows/ThreadPool.html ThreadSpawn for 1.8: http://rainbows.rubyforge.org/Rainbows/ThreadSpawn.html 不好意思的是，我自己是没玩过，之前试 async rails 碰了一堆壁， rails 自己有一些奇怪的 lock, 所以就不想在 rails 上试这些了... 可能 rails 3 有改善吧，不知道 : 抱歉，第一次问问题就问了一大堆，也还希望有人可以协助解答， : 感谢非常!!!!!!!! -- In Lisp, you don't just write your program down toward the language, you also build the language up toward your program. 《Programming Bottom-Up》－ Paul Graham 1993 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 114.25.229.250