• midori 百日记 at 2017年1月17日

    #28楼 @luikore mruby 下的线程栈还挺小,但生态太糟糕

  • midori 百日记 at 2017年1月16日

    #25楼 @gihnius 很多稳定性问题主要是 eventmachine 本身导致的,而不是异步。我也打算在下一个大版本中把基于 eventmachine 的绑定改成基于 nio4r 的绑定。rust 线程比 gorouting 快很多,但是 rust 上基于的 tokio-rust 的网络通讯会比线程更快。扯到 IO 的时候,只有在完全解决阻塞的情况下,问题才会落在内存、网络、磁盘上,一旦出现线程阻塞,那性能必定是非常糟糕的。异步的做法就是用来解决阻塞问题的,但是异步的做法代码很难看,这才是这几年很多语言设计都在极力克服的问题。高性能的 Web 服务器,从 Apache 到 nginx 没有一个不是在使用 I/O 多路复用技术来解决问题,甚至连使用哪种复用技术都经过了几代的改变,更不要说单纯同步靠创建线程来解决 I/O 导致的线程阻塞,运行效率实在是太低下。

    IO 密集型还是用线程。

    这种表述实在是难以苟同,你基本找不到单机 10k 并发以上的应用是通过纯线程来解决的,因为单纯靠创建新线程,*NIX 线程创建的性能代价是极大的。

  • midori 百日记 at 2017年1月14日

    #23楼 @mizuhashi 在多线程下不会阻塞是指,他们在多个线程连接数据库的时候互不阻塞,但对于当前线程就出于阻塞状态了,我在实现 pg 的 adapter 的时候就发现了这一问题。主要是大家没有共享同一个 event loop

  • 有点奇怪,既然是 Let's encrypt 的证书,为什么不直接申请呢?在又拍云上申请 Let's encrypt 证书有什么区别?

  • 怎么看都像是脱裤啊。。。

  • 这帖子让我想起来不少事情。我自己从 BASIC 开始 Delphi, C++, PHP, Python, Java, JavaScript, Scala, Objective-C, Ruby, Common Lisp, Swift 都先后学过。最后想想语言和框架真的是这么好学的东西吗?是也不是。

    是的部分是语言的语法确实是一通百通的,基本就可以分为类 C 语言和类 Lisp 语言这两大类。不是的部分是,如果大家的设计都这么接近,那么为什么会有这么多语言呢?事实上,理解一门语言的重要部分就是理解这门语言的设计思想。

    如果你会写 C++,学习 Java 的第一天你就可以开始干活了,但你很容易写出 C++ 风格的 Java。这就好像谭浩强的 C 语言书有那么多问题,除了本身的语法问题,一个就是对于语言设计思想本身谭浩强不理解,另一个就是保有了大量谭浩强之前 BASIC 程序员的风格。

    所以如果你学过很多语言,学得好,你优势就会很大。比如你又会写后端,又掌握前端,在你开发时你就能很好的对接,设计出更合适的接口,极大地提高沟通和开发的效率。学得不好,那么这些东西反而会成为阻碍,让你什么事情都没法做好。这是全栈工程师和全栈 Hello World 工程师最大的区别。

    不过反过来说,如果只学一样东西,即使这项技术没有过时,那么你就能专精了吗?其实也不是。很多外包公司的 Java 程序员所谓的 10 年经验难道不是半年经验用九年半吗?

    所以本质上来说,要想有好的职业规划,需要对自己有明确的认识。永远知道自己知识薄弱的地方,永远知道自己要学习要接触新的东西。好的程序员其实吃饭的时候在想怎么更好抽象,排队的时候在想怎么提高性能,洗澡的时候在想怎么优化风格。用框架用语言的同时会提出这些框架语言设计的问题,并思考能不能解决,怎么解决,这样才能对这些东西理解更加深刻,这样才能让自己写起代码来游刃有余。

    其实真的好好思考后,就算是业务代码也并不会繁杂。业务逻辑上的繁杂通常就是由于没有正确的抽象,从一开始就没有好好做好,从而使得复杂度越来越高,永远是打补丁,在补丁上打补丁,代码越来越糟糕,最后让思路越发混乱,越发不能维护。如果是这种情况,别说 Rails,世界上任何一种语言、一个框架都能写出这种垃圾代码出来。

    于是说,如果因为自己买了台 iPhone,就能荒废 Android 开发的技能,这种坚持和努力程度实在是太低了。我很难苟同说楼主现在这样的情况的主要原因是环境造成的。

  • midori 百日记 at 2016年12月25日

    #20楼 @0x005a 已 fix。我最近用这东西写了些实际的项目,跑了下 benchmark 还是相当好的。准备把性能测试写得更完善一些,之后可以更好对比。

  • midori 百日记 at 2016年12月22日

    #18楼 @harryyoung 我觉得我要把 em- 彻底拿掉。。。

  • midori 百日记 at 2016年12月20日

    #16楼 @huacnlee 其实 API 里都没有 em- 前缀,只有 gem 名字有。。。因为 midori 这个 gem 名字被人注册了 QuQ

  • midori 百日记 at 2016年12月18日

    #12楼 @0x005a

    • 请求体较大的请求,耗费 parse 时间
    • 响应体较大的请求,耗时 send_data 时间
    • get 中执行耗时操作时。上述 sleep 1 只是举例,现实场景是,开发者使用的第三方网络请求库,随机性的 CPU 密集型操作等等。

    这样的问题就不是说依靠异步模型本身去解决的,因为这些场景出现的是真正的 CPU 密集运算 需要的是真正的计算力来解决的。如果说我们只有一个核心一个线程可用的情况下,任何 Web 框架,包括 Node 也好,都会出现同样的性能下滑。只有说我们靠多线程多进程来解决,类似于 express 的 clusters;类似于 Ruby 上的 puma。

    另外你给的 benchmark 代码,如果限制 thin 只能在一个核心上运行的话,em-midori 并不会比 thin 慢一倍。(在 Linux 上的性能测试,macOS 上的 em-midori 有一些奇怪的性能问题,还在排查。)这和 em-midori 目前还没有实现 clusters 功能有关,这是下一个版本的工作重点之一。

    另外我不能理解所说的

    难以保证 Promise 的方式是可靠的,且性能不低于常规方式

    因为这个 Promise 是按照 Node 新版本的思路一致实现的,如果说可能存在一些边缘情况,这些之后会通过更完整的单元测试来补充。而使用 Fiber 的封装肯定会比 UNIX 线程方式的性能高,这点应该是毋庸置疑的。