编程语言API性能大比拼
发表于 15:36|
作者夏梦竹编译
摘要：Ciaran是Skimlinks项目团队中的一名领导者，热爱开发，在业余时间喜欢研究一门新语言。作者和他的团队在开发Skimlinks项目时遇到了一些困难，于是做了这份调查表，文中将Node.js、Scala、Go、Python、PHP进行对比，最终Python获胜，目的的是为了让开发者为stack挑选最好的开发技术。
Ciaran是Skimlinks项目团队中的一名领导者，热爱开发，在业余时间喜欢研究一门新语言。作者和他的团队在开发Skimlinks项目时遇到了一些困难，于是做了这份测试，文中将Node.js、Scala、Go、Python、PHP进行对比，最终Python获胜，目的的是为了让开发者为stack挑选最好的开发技术。
在过去的这段时间里，我之所以杳无音讯，是因为作为这个项目的领头人，我正从事一项有趣的项目，我们将其命名为&Skimlinks&。
我的大部分工作是从事后端引擎开发和支持SkimWords产品进程，通过一些非常完美的高科技进行识别和添加代销商网络产品链接从而让网站主获取利润。这是一种新颖的线上广告模式，相比于页面上的大幅banners图我更喜欢这种新颖的模式，我们正在尝试为用户添加有价值的信息如产品价格比较、添加链接让用户可直接购买想要的产品。
开发环境：
大部分前端开发是用PHP编写的，当公司需要快速、灵活开发项目时，选择PHP是个不错的选择。但是随着公司既定产品的知名度不断提高以及搜索的高并发访量，PHP正日益成为我们发展的一个瓶颈。
存在问题：
使用Apache多选程模块(MPM)，apache会阻碍大量的搜索请求，当出现高并发访量时，页面无法响应。
这里有一个快速的方法可提高服务器的吞吐量增加工作进程，然而当RAM快要耗尽时，将会受到限制。每个进程都有独立的RAM数据块，增长和搜索取决于PHP在哪个点上，当没有足够的空间释放时，你必须将OOMing关闭（它可以迅速的将吞吐量降至为0）。
最可行的扩大规模的方法就是把项目管理模块从Apache prefork MPM换成更出色、更快速的Apache worker MPM。通过改变多进程大大增加了服务器请求数，唯一的缺陷只是为了这个工作而工作，PHP必须能够保证处理多个并发线程不会产生死机，然而事实并非如此。PHP的核心是多线程，因此我门认为它可能是因为某些驱动或者延长使用而导致失败，然而无论出于什么原因，PHP不在符合我们的需求。
为此，引发了我们会选择哪种语言进行开发而争论不休，每个人都在推崇他们喜欢的语言，有人赞成、有人反对。很明显，众口难调，没有一个衡量标准是很难选出来的，因此，我们决定用各个语言来测试一个系统，看它们的执行情况在做定夺。
参赛语言：
基本规则是，如果你想要某语言进行测试必须愿意提供执行API请求数，最后推选出：
Node.js：流行程度依然高涨，它的目标是帮助程序员构建高度可伸缩的应用程序，编写能够处理数万条同时连接到一个（只有一个）物理机的连接代码。&
Scala (w/ Tomcat)：我非常热爱JVM，起初我也推荐过该语言，但因为它过于冗长而被否决，令人兴奋的是，这次Scala得到了大家的认可。
Python (w/ Tornado)：我们已经有Python方面的经验。
Go (golang)：我对这门语言感兴趣，而我的同伴们却认为这门语言不好，建议使用Java。我还建议使用C#和.NET/mono，但因为不公平性，最后都被否定了。
我们选择了一个非常简单的日志API系统，所做的这些是为了从JSON请求数中抓取详细信息，采用MD5，用于确保信息传输完整一致。（主流编程语言普遍都用MD5实现。将数据（如汉字）运算为另一固定长度值，是杂凑算法的基础原理）每个执行阶段都将使用Apache Benchmark（Apache附带的一个小工具，专门用于HTTP Server的benchmark testing，可以同时模拟多个并发请求）来评估各种语言开发并发水平速度。
当Node.js和Python Tornado以单一线程运行时，使用Nginx（一个高性能的HTTP和反向代理服务器，也是一个IMAP/POP3/SMTP代理服务器 ）来查看这两个实例。
针对Scala我甚至特意编写一份old-school Servlet(一种服务器端的Java应用程序，具有独立于平台和协议的特性，可以生成动态的Web页面，它担当客户请求Web浏览器或其他HTTP客户程序与服务器响应的中间层)在基于tomcat下运行。
采用AWS（Asp Web Server是一款基于netbox开发的asp web服务器，其个小功能强大，基本上能够取代IIS成为广大Asp程序员和网站开发者的利器）直接在服务器上执行基准，以消除任何一个网络瓶颈。
通过mongo删除每次测试数据，每次测试至少执行3次，选取平均值，以确保有足够的&热身&时间和消除任何异常结果。
通过在多个并发值下进行测试（(10，50，100，200，500，1000)，一起来看下在高负荷的情况下，性能发生了什么变化。
测试结果：
每秒请求数：这个测试给了我们一个实现纯速度的想法，最明显的一点（越高越好）。
有一点值得我很欣慰，Scala独占鳌头。PHP（正如预期所想的那样）受多线程的限制，香消玉损。另一个让我震撼的是Go语言当并发访量不断增加时，它以平缓的速度迅速下滑，最终也Over了。如期所料，两个单线程non-blocking solutions（node和 python）性能差不多，python要比Node稍微好点。
响应时间：
尽管每秒请求数进程的吞吐量呈现出一个好的迹象，但是同样重要的是在高负荷的情况下，表现很糟糕。由图表得知，在一段时间内完成的请求数比例，越低越好。
100并发请求数:
在这里，我们看到Scala需要的时间最少，而其他几门语言之间没有太大区别。
200并发请求数：
图中，我们看到有趣的现象，以9秒速度来计算请求数，Go和PHP都有受到影响，花费的时间比较多。
500并发请求数:
在500并发需求时，使用9&14秒完成请求。PHP无法响应，Go语言花费时间较多，占最高值。
1000并发需求数：
当我们遇到数以千计的请求数时， Go语言Over了，通过测试，根据apache规则要求超过50%的失败率就算出局。如图所示Node和Python依然存在，可以清楚的看到其性能特性。但是Python比Node要更好一点。但在第一幅图上，Python表现的要稍微差一点。
通过测试，能清楚的分辨出各语言的性能表现，以上测试的这些数据是我们APIs中的一部分，因此对我们来说非常重要。
Scala表现的很好，几乎很完美，我把它归功于在连接池的Mongo数据库中单独接入MessageDigests和快速进行JSON分析程序。我不确定Go语言到底是怎么了，也许是我使用的Mongo驱动的问题，但无论是什么原因，看到它这么差的表现真的让我很难过。
最后决定：
最终，我们经过讨论决定选择Python！Scala如此之快，我们为什么不选择Scala而另选Python呢？原因如下：
Scala这门语言很难，我需要很久才能将简单的API整合在一起，才能进行工作，python阅读起来就像，而Scala阅读就像蛇类游戏一样。
线性编程是很痛苦的，对Scala来说，很容易也很安全，简单的单线程non-blocking解决方案总是很吸引人，但我们应该不断的去尝试挑战。
整个团队在Python上有着丰富的经验，如果让大家去接受一门新的语言，尤其像Scala这样的既昂贵又费时间。
此前网络速度、数据库查询等API成为我们发展的一个瓶颈，而今，我们已经找到正确的解决方案&&Python，我们只需等待执行和发布，希望这个决定是正确的。
英文出自：
（本文为CSDN原创，未经授权或许可，不得转载）
推荐阅读相关主题：
网友评论有（0）
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章当前访客身份：游客 [
已有文章 2191 篇
当前位置：
如何雇一个牛逼的 Node.js 开发者
英文原文：
0人收藏此文章,
推荐于 1年前 (共 8 段, 翻译完成于 07-30) ()
参与翻译(6人)：
初创公司是我的激情所在，而我干的也是管理一群雄心壮志的开发人员。我工作在Strongloop,并且已经在很多初创公司待过。初创公司在雇佣问题上有它独特的挑战----预算紧，期限近。加上要使用开源框架进行开发，而且还是相对年轻的框架，如Node.js，这一切使得雇佣一个合适的团队成为了一种巨大的挑战。
&翻译的不错哦!
正如所有新兴并被快速采用的技术框架一样，一开始的挑战就是给你的技术团队增加高效的人才资源。在快速得出关于把 Javascript 开发变成 Node.js 工厂的结论之前，让我们先来看看关于 Node 及产品开发环境的核心问题。&简而言之，核心问题就是：
Node.js 具备的编程风格
Web 趋向于更小的以响应器/消息为基础的架构
最后，大多数我们试图解决的问题仍然需要通过可扩展的后端架构而不是UI来提供支持。
让我们逐个分析这些问题并揭示它们所带来的挑战。那就引出了我们需要招聘什么的人。
&翻译的不错哦!
基于事件的程序设计
相对于传统的线程模型，Node.js开发与传统模型之间的主要区别是围绕着事件模型。相对于传统的线程模型，框架在基于事件的程序设计中管理的是控制流。在传统模型里，开发者必须在控制流中仔细处理模型中的流程，主动编写控制流向及返回的代码，要完全了解任务执行完后应该如何继续下面的流程。而对循环进行完全控制的事件模型则会返回到它会去的地方，而你却只能交叉手指祈祷好运。于是挑战就在于你如何组织逻辑，在于如何从过程模型到应用系统的输入与响应模型理解上的转变。这就是关键。
&翻译的不错哦!
一个好候选人，能就传统的问题通过事件的方式进行讨论。他们是否能够清楚哪种类型的应用程序更适合于Node的方式？ 例如，一个I / O与CPU密集绑定的应用程序。著名的聊天服务器就是个很好的例子。问他什么样的复杂变化需要使用这种模式放在一起的代码。 一个好的候选人应该能够解释并发模型，事件循环与多线程的差异，以及它们如何影响可扩展性。
&翻译的不错哦!
开发来自测试，二者手拉手。JavaScript是一门弱类型的动态语言，来自于Java/C#的世界，你突然失去了你的安全保障（你的“编译器”）。此外，你写代码处理事件都处在模型之中，以测试驱动开发（TDD）的经验 确实变得好用。以我的观点来看，TDD更适合基于事件的编程。实际上最好的开发人员已经这么做了，在测试之前甚至只有一行代码。更关键的是，你要确保你所想要雇佣的开发者有使用测试驱动代码设计的思想，而不仅仅只是考虑去用。下面将会做一下介绍。
这样，我们就有了两个关键的技能点用来寻找候选者，即：编码能力和测试驱动设计！这与我之前说的没有太大区别，除了一些细微上的不同！
&翻译的不错哦!
你可能已注意到了网页的范型转换： 我们正快速地从传统的网页加载刷新走向较小的传感器般的信息，快速地访问小片的实时信息。你将也注意到通过开放式API我们走向传感器连接，器件连接，移动访问。Node.js这种情况，这里也是开源，由小模块API提供访问丰富信息组成。加上有不断成长的模块生长生态的外在，我观察到它惊人的成长---大约30%，从我加入Strongloop大概18个月以来。所以，你雇佣的任何Node.js开发人应该擅长在这样的开发模型下工作： 访问实时信息的小部分。
&翻译的不错哦!
通常，我相信这意味着这样的开发者：擅长互动开发，快速编码试水，写小的重用的代码片段，遵循基于API开发。
基于类似Express, Connet, Async的关键模块的经验肯定都是加分的。github经验，开源贡献都得加高分。事实上，候选人用GitHub合作对等编码,关注Node.js在Google群和StackOverflow的活跃社区，和他写代码的能力同等重要。用模块生态系统的许多模块，找到已有模块，修好别人的模块或者给别人的模块打补丁，终归都是关键的技能。我要检查候选人GitHub的贡献的趋势和质量数量。他们是好的社区成员吗？他们修好代码吗？他们实行干净健康的特征分支，PR,提交吗？
如果你确实发现有人他积极贡献某节点核心，好，移交到附近的办公室。
&翻译的不错哦!
安全性，后端架构，培训
伴随着代码开源，Node.js又是基于Javascript，这可能会导致你的应用存在安全隐患。开发者应当对服务器端注入比较熟悉，而且知道如何通过编码去避免这些风险。Node.js是单线程的，所以很容易会受到拒绝服务攻击。一名能够考虑到这些恶意情况并且编写出经得起良好测试的代码，在你的Node.js组中将会非常有价值。
Node.js相比其他编程语言还是比较新的，所以找到一名理想的员工可能会是一个挑战。在一些当地的小聚会中，你可能会找到一些黑客，也有可能找到一些经验丰富并希望向Node.js发展的Java工程师。或者为什么不考虑将你手下的一些在大型后端架构、处理大规模问题和容错方面有丰富经验的Java工程师送去参加一个好的培训呢？准备好开始了吗？StrongLoop提供和对。
&翻译的不错哦!
标题不应该这样翻译吧。great应该翻译成“优秀”！！！感觉这种翻译方式不好，译好了就不改了。而且每篇文章由不同的人翻译，风格和质量都良莠不齐。Node.js 与 Python 作为后端服务的编程语言各有什么优劣_百度知道
Node.js 与 Python 作为后端服务的编程语言各有什么优劣
提问者采纳
但是就看Node.js是目前很多前端通向全栈的桥梁。缺乏全盘级的考量.js的本身Web库还是它的主力Express框架从整个Web设计的角度讲还是处于lib阶段。相对Python的Web框架可选选择更多一点。我个人倾向于Django不得不说Node
其他类似问题
为您推荐：
python的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁Node.js 与 Python 作为后端服务的编程语言各有什么优劣_百度知道
Node.js 与 Python 作为后端服务的编程语言各有什么优劣
提问者采纳
Python不容易找到关于后端开发中各种问题的处理办法Node，Node，使用方法都很容易找到各种资料，而Node，因为网页前端如果有代码，基本上都是使用的js &nbsp，Python要么借助asp，配置有一定的难度活跃度上，似乎更方便,要么配置cgi或者其它，语法上上手更容易，但还是稍微特殊点作为后端的环境.js目前正处于活跃上升期;那么,js与后端的js对接，Python语法也算简单。不知道算不算优势，其插件.js是自有的.js作为基于javascript的后端扩展
来自团队：
其他类似问题
为您推荐：
python的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁酷勤网 C 程序员的那点事！
当前位置： >
浏览次数：次
twisted是一个强大的异步网络框架，应用的面也非常广，但是没有这几年才出现的Node.js火，社区、文档也是很少可怜
我觉得二者其实在本质上差不多，而且python使用起来还是比较容易一些的
因为，它给了一大部分程序猿幻觉比如前后端统一，脚本也能性能很牛Demo搜搜快什么的，但实际上，这仅仅是幻觉罢了&&
正是因为这样的幻觉是&看得到&的，又有一个响当当的干爹Google，因此Node的曝光率远高于后端常规语言就不足为奇了。
论速度，你一个带JIT的跟常规脚本语言的虚拟机比，没到数量级差异丢不丢脸？内存各种匪夷所思的占用丢不丢脸？web才和CPython+Gevent一个水平比不过pypy丢不丢脸？
论稳定性，Python十来年的积累，大公司的经验，你一个以桌面系统为目标的V8拿来做工程逗我玩呢？
论代码的管理，Js那种匪夷所思的陷阱还要不要一起玩了？Callback hell？
说白了，前端工程师在普通level这级人数太多了，作出来的东西能看得到，吸引力比埋头在服务器上耕耘的系统工程师要高。技术新人往往是被看得见的先吸引到，但不深入怎么知道系统的严谨？node一出前者觉得自己各种碉堡，觉得System Engineer is die 然后四处宣传，比如你看老子一天撸出个实时web，还带个碉堡的前端实现，看看你们系统工程师，呵呵呵。Full Stack哦，一个socket连接消耗多少内存都算不出来你跟我谈Full Stack？
所以，这就不是浮躁的宣传这是什么？系统工程是很严谨的，打交道的往往不仅仅是代码，最终产出最看重的也不是什么性能，很多设计很多实现最终服务的都是后端系统的稳定性，扩展性等这些跟钱相关的东西，你跑来跟我谈跑循环？循环能赚个锤子？
至于Python的XXX为何不火，Callback早就有Twisted，新生代也有Tornado，Coroutine有Gevent，Actor有Pulsar，VM方面要稳妥CPython，要性能PYPY，要并发Stackless，AIO神马的的选择太多了，你喜欢上啥就有啥，社区要运作要宣传怎么闹，手头的牌太多了有木有。Node没这样的历史包袱，就一个选择，自然全部社区的力量和宣传都可以集中到这上面去，加之低门槛，你看出书都出了多少，不火才不科学。
但是，做工程和火不火有毛关系啊？
，长期求职
关键是营销做得好。说是因为Twisted有什么不如Node.js的技术缺陷，那都是不客观的。
Node解决这个问题靠的是强制异步IO操作，使得Event driven模型能够高效执行
这个就太想当然了。连node.js的作者都不会这么说。你一定不知道什么叫POSIX吧。按POSIX的定义，一个file descriptor假如对应的是普通文件，不管有任何non-blocking或者async的选项可以设置，它必须block。Node.js也只是在背后开了一个线程池。这种做法和Twisted并没有任何区别，而且比Twisted更糟糕。Twisted实现了线程池的功能，并且暴露API给你用，这样你碰到别的没法异步的地方，你也可以用Twisted的线程池。而Node.js在很长时间内并不打算提供线程池，或者说，Node.js有线程池只是你不会C++罢了。
另外，没有抢占式调度，你还是不可避免地要审查代码。有些代码相比别的代码消耗了太多CPU了，成为了瓶颈。查这个比查有没有调用会block的代码可难多了。Python再没节操，好歹库里也把语言自身的ast暴露出来了，很容易就能写个脚本检查出来了，现成Python代码检查工具不会比JavaScript难用的，JavaScript语言设计就拖后腿了。
原因之一也许是 JS 能方便地在表达式里插函数，你 python 的 lambda 里能放语句么？
只有要把同步写法扭曲成异步写的时候，lambda写起来是否方便才会显得很重要。Twisted有inlineCallbacks，不需要扭曲。
python这种语言要做nodejs的异步的事情，得语言支持cps变换才行
原因是V8那时还远没有yield。就Node.js用没有yield的V8而不用早就有yield的SpiderMonkey这点就可以不用看了。这个选择完全就是为了营销。Python有yield，没必要自己搞什么CPS变换。
是Tornado让Twisted变得更好了。之前Twisted在Web方面没有花太大精力，导致Twisted.web也就仅仅是能用，远说不上是好用。但是Tornado除了Web部分做的比较好，其他地方都是不如 Twisted的。只要把Tornado的Web部分移植到Twisted上，Twisted的Web也不烂了嘛。就有一个叫cyclone的项目做了这个。我不会告诉你跑分还比原生Tornado要好呢。
-----------------------------------------------------
在Node.js还没起来的时候，Twisted那几个开发者早就知道只能异步很不好，等知道有Erlang这种语言的时候，都开始大力向推荐大家用Erlang了。Node.js刚出来那时候和Erlang比，不，显然就不该做这样的比较。
营销做得好，才是Node.js火起来的关键。
假如你还记得那个多少行写个IRC的slides。大致是这样的，Node.js的作者在拿Event-driven和Apache那种fork子进程方式对比的时候，他是有理有据地指出了Event-driven的优点。但是在讲和其他模式对比的时候，他讲的是感觉。他说要是把那些不能立即返回的操作的调用方式和一般的函数调用区别开，不然会给人以错觉 。这样一来，只能写异步回调就立即变成优点了。把Node.js最致命的缺点都包装成优点了，再没节操地鼓动一帮人去搞一些毫无意义的benchmark，立即就避免了不利的局面。喊口号总是最容易的，事件驱动就是高性能， 库就是包袱，异步回调地狱就是好就是好就是好。就火起来了。
，系统编程
在Python增加带返回值的yield前，Twisted代码全是回调，程序结构那是相当的twisted。在Python这个注重代码简明的语言里，Twisted实在是格格不入。大部分Python程序员恐怕没看完deferred就被吓跑了。
而回调对js程序员根本不是个事儿。
首先对于排名第一大谈 nodejs 弱爆了，System Engine 才是吊的人做个冷嘲&&真正做 nodejs 的如果不熟悉 v8 引擎和 libuv 其实只能是做作外围吧？而熟悉 v8 和 libuv 的哪一个没有扎实的 System Engine 基础（没个七八年的 C/C++ 项目基础能玩转 v8 和 libuv 的那真是少见了）？然后说出什么搞 nodejs 的人搞不清楚 websocket 消耗多少内存这种话你确定打击面没有太大？难道你身边有一些初级的 nodejs 开发人员给你造成了错觉然后你就优越到没边了？
在这种角度就讨论技术，讨论的根本不是技术，而是自己的偏好，自己的圈子和好恶。调侃下可以，但是真的是一点营养都没有。而那些赞同他的人，我只想问你们真的有研究过 nodejs？
分割线下面是之前的回答。
-----------------------------------------------
说 nodejs 只是靠营销的是否太天真了些？当初 nodejs 出来的时候各种 BUG，我简单的测试其大文件传输都会出现各种问题。而同r期的其他阵营早就甩其几条街了。但是为什么却能一直不断发展壮大？难道仅仅靠所谓的营销和忽悠？
如果只孤立的去考虑 nodejs 的异步库到底怎样怎样，实在是太片面了，难道 nodejs 里面就只提供了异步网络 IO？
事实上，nodejs 是提供了一套通用的异步基础设施，使得你可以基于此构建各种异步 API。异步网络 IO 只是其上的一个具体应用。而现在问题里提及的 twisted 实际上在这一点上根本不具有与 nodejs 的可比性！
我选择 nodejs 的原因很大程度上是因为它是 JavaScript 的，这样一来在前后端我可以用同一种语言完成整个项目，这是极大的一个优势！另外，尽管 nodejs 不是唯一的也不是最早的基于 JavaScript 的服务端方案。但是它是同r期性能 JavaScript 阵营里最佳的。
再加上 nodejs 底层的 libuv 设计很简单，非常容易扩展，而且 npm 又那么好用。因此开发效率急速上升。
选择 nodejs 到底为什么，其实到了现在，许多人各自有各自的理由。但许多人都是因为他是基于 JavaScript 的低成本解决方案。
考虑 nodejs，不止是考虑它的一小部分 API，而是它带来的各方面的便捷。请不要太片面。
，失业是为了发现更好的自己，恢复毒舌吐槽&
nodejs有两个可以大书特书的优点：
1、和前端统一语言，减少【想象中】的学习成本。
2、npm好用到不行，虽然很多lib难用到不行。
你猜猜看，看上去很简单实际上很困难，看上去很困难实际上比较简单，这两个谁的用户会比较多？
& 相关主题：