php7和python3性能对比,python与php哪个简单
GRPC是Google最新发布的开源软件，基于最新的HTTP2.0协议，支持多种常用编程语言。我们知道HTTP2.0是基于二进制的HTTP协议的升级版本，目前正在被各大浏览器快速支持。想象一下，未来浏览器支持HTTP2.0，可以通过现有的开源序列化库(如protobuf)直接高效地与各种语言的服务进行交互。这是多么美妙的一幕啊。
作为gPRC Java实现基础的网络库是Netty，它是netty5.0.0. alpha 3的最新开发版本。因为最新版本针对HTTP/2做了很多改进。出于跨语言的考虑，gPRC和其他方案一样，使用IDL等旧的接口描述语言，使用自己的Protobuf项目的Protobuf编译器生成框架代码。这是目前最流行的脸书开源，符合节俭原则，顶级Apache项目。
我很好奇这个新诞生的框架的性能，以及它与现有的RPC开源方案相比如何。简单的比较需要时间。我选择了五个开源项目进行测试：gRPC、Thrift、Wildfly、Dubbo和JBoss EAP。为了简化，可以通过使用项目附带的demo或sample来简单地修改测试用例，从而使进程间网络调用的数量保持一致。
从Github master backbone network获取最新版本，按照手册编译。如上所述，网络框架是Netty5，基于最新的HTTP/2。
其中选择getFeature方法，删除不用的句子和屏幕输出，同时调用10000个。
testclientsyncclient=newtestclientsync( localhost ，8980)；尝试{
finallostarttime=system . nano time(；
for(inti=0；我
client.getfeature(409146138，-746188906；
finalllongendtime=system . nano time(；
信息(方法1:)(结束时间-开始时间)；}
publicvidgetfeature(int lat，intlon ) {
尝试{
point request=point.new builder(设置纬度)(lat)。设置经度(lon)。构建)；
feature feature=blocking stub . get feature(请求)；
}catch(runtimeexceptione ) {
logger.log(level.warning， RPCfailed ，e)；
投掷
}
运行多次，并记录所需时间。
GRPC还提供了一个非阻塞的调用方法。但由于时间有限，为了简化测试，我们采用了只通过标准服务器启动的方法。由于asyncStub在大规模并发访问时会出错，使用时间较长，所以本次测试中没有该方法的结果数据。
从Apache站点获取最新版本0.9.2，而原生编译器获取C编译器和Java运行时环境。
intdifffinallostarttime=system . nano time(；尝试{
for(inti=0；我
DIFF=client.calculate(1，work)；}catch(invalidoperationio ) {
system.out.println(无效操作：)io . why)；} finalllongendtime=system . nano time(；system.out.println(方法1:)(end time-start time)；
Thrift采用的是经典的基于网口的RPC，效率最高，最后的汇总数据可以看出来。
Wildfly是重新命名的JBossAS服务器，它实现了完整的JavaEE规范。我知道JavaEE上的远程RPC调用是在EJB规范中定义的。在这里测试Wildlfy的远程EJB调用功能。
由选择的Wildfly8.2是目前发布的最新稳定版本。这个版本也支持端口重用。这意味着EJB远程调用是在HTTP端口复用中进行的，而HTTP的升级机制是在二进制运行时进行协商和升级的。虽然不是纯HTTP/2，但是工作机制差不多。
示例选择jboss-eap-quickstarts项目来测试远程ejb调用示例RemoteEJBClient.java
纯Java RPC方案的优点是不需要IDL文件定义和编译代码生成过程。只需协商接口。
公共界面远程计算器
intadd(inta，intb)；}
int sum=0；finallo
ngstartTime=system . nano time()；for(inti=0；我
sum=statelessremotecacalculator . add(a，b)；} finalllongendtime=system . nano time()；system . out . println( method 1:(end time-start time))；
无状态SessionBean方法被调用10，000次，对应的远程EJB服务是部署在Wildfly应用服务器中的EJB。
Dubbo是阿里集团一个极其开源的RPC框架，广泛应用于众多互联网公司和企业。并且协议序列化框架可以被插入和拔出。同样的远程接口是基于Java接口，依托spring框架很容易开发。可以方便地打包成单个文件，独立运行，与现在的微服务理念一致。
采用github中的Master backbone，当前版本为2.5.4-SNAPSHOT。
在测试示例中，选择demo来修改DemoAction.java。
公共接口服务{
StringsayHello(string name)；}
finallostarttime=system . nano time()；for(inti=0；我
尝试{
string hello=demo service . say hello( world I)；
} catch(exception one){
e . printstacktrace()；
} } finalongendtime=system . nano time()；system . out . println( method 1:(end time-start time))；
检查输入日志文件以获得调用结束后的运行时间。
red hat JBoss EAP 6 . 3 . 2链接
EAP JBossAS是一个商业版本，它实现了完整的JavaEE规范。
EAP6基于AS7.2之后的版本，红帽提供商业支持。
7.2之后，不再发布AS7的社区版，有能力的企业可以从源代码开始编译使用。EAP6.3是建立在AS7.4的分支上的，很快发布的EAP6.4也是建立在AS7.5的分支上的，不出意外，这将是EAP6的最后一个次要版本。
AS7还没有像Wildfly一样完全采用端口复用。基于JBossRemoting3的网络连接管理能力，通过独立端口完成短程EJB呼叫。
jboss-eap-quickstarts项目中远程ejb调用的例子仍然用于测试。
public interface远程计算器{
intadd(inta，intb)；}
记录10，000次通话后的时间。
结果。
最后，经过4轮测试，不间断运行10，000次远程RPC调用后的结果如下：
我们可以看到，节俭的效率最高，大约领先一个数量级。而其他三个项目的性能数据都在同一个数量级，从高到低分别是JBossEAP、dubbo、wildfly和gRPC。
需要解释以下几点：
为了简化测试，我没有选择相同的调用接口，而是方便地使用了项目自带的、易于修改的样例程序。gRPC和Thrift的接口有对象传递，稍微复杂一点。
不是严格的性能测试过程，比如没有预热过程，测试运行在我的台式电脑上，还没有完全恢复到“干净”的状态。
它们是简单的服务器单进程实例，标准的演示示例，没有特殊的优化和设置多线程池。客户端调用也是最简单的阻塞多调用压力测试。多机多连接多线程多环境异步无阻塞调用测试应该更客观，有机会继续提高。
之前没看过基于HTTP/2的RPC调用的性能对比，理论上应该低于经典的基于端口的RPC方案。这个测试结果可以简单的证实这个猜想。节俭的数据遥遥领先。gRPC还在开发中，基于Netty或者alpha版本，非阻塞方式还没有最终数据。我想耐心点，给gRPC一些时间。它会让我们大吃一惊。
Wildfly表现不错，要知道，它的服务器是一个完整的JavaEE服务器。但是，如果我有时间，我会尝试看看经典RMI连接的效率如何。如果能和节俭一个数量级就更好了。
Dubbo的性能也很优秀，如果协议层可以更换的话，应该会提升更多。
我的测试是在一台过时的笔记本上，受条件限制，没有先进的G级网络和多台服务器进行标准化的性能测试。如果有在互联网或者企业工作的朋友有条件，愿意全面完成这个测试，请联系我。我会全面介绍我的测试构建环境，分享代码，帮助完成。我觉得那个结果会更有意义。
郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。