Spike https://github.com/slince/spike;
之前由于要与一个同事远程协作开发一款 app 需要用到内网穿透服务,在网上找到了 frp 与 ngrok ;后来我在想能不能用 php 也写出来一个这样的服务软件?大家都知道 php 多进程多线程不够友好,在 window 上还不支持;写服务确实很吃力;不过幸运的是有ReactPHP的存在,关于 ReactPHP 不做赘述有兴趣的同学可以自行百度。
基于 ReactPHP 的 IO 多路复用,使得 Spike 并没有比 Frp 性能差太多;下面是我简单做的一个 benchmark,基于 apache ab 检验 http 隧道的服务性能;客户端与服务端都搭在本地,代理同事电脑上的 http 服务。不是特别符合应用场景,大家简单看一下。
从下面的信息可以看出 Spike 性能似乎是稍微好点的,不过这个地方有点不公平,我在做 spike 的测试时只开启了服务端的日志,客户端的日志是关闭的;而 FRP 的两端日志都是开启的;我不知道怎么关 frp 的日志;
在这里简单提一点由于 Spike 的日志 IO 是同步的所以日志的读写会耗掉部分性能,提升日志等级减少日志写入可以提升不少的性能;
这个项目是我比较上心的一个作品,算是证明了一点,php 除了可以做网站也可以做服务,并且也没有太差。 最后再次附上项目地址: https://github.com/slince/spike 欢迎 star,欢迎 fork
Spike:
Concurrency Level: 10
Time taken for tests: 37.727 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 2569900 bytes
HTML transferred: 2514600 bytes
Requests per second: 2.65 [#/sec] (mean)
Time per request: 3772.747 [ms] (mean)
Time per request: 377.275 [ms] (mean, across all concurrent requests)
Transfer rate: 66.52 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.4 0 3
Processing: 533 3602 591.9 3714 4096
Waiting: 516 3587 592.3 3701 4076
Total: 534 3602 591.9 3715 4097
Percentage of the requests served within a certain time (ms)
50% 3715
66% 3791
75% 3822
80% 3844
90% 3970
95% 4015
98% 4053
99% 4097
100% 4097 (longest request)
Frp:
Concurrency Level: 10
Time taken for tests: 38.230 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 2569900 bytes
HTML transferred: 2514600 bytes
Requests per second: 2.62 [#/sec] (mean)
Time per request: 3823.045 [ms] (mean)
Time per request: 382.304 [ms] (mean, across all concurrent requests)
Transfer rate: 65.65 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.2 0 1
Processing: 379 3650 644.4 3809 4140
Waiting: 360 3633 645.5 3789 4124
Total: 380 3650 644.4 3809 4140
Percentage of the requests served within a certain time (ms)
50% 3809
66% 3847
75% 3909
80% 3923
90% 4026
95% 4053
98% 4129
99% 4140
100% 4140 (longest request)
ReactPHP是个不错的东西,打破了已有的php执行方式;对php有兴趣的同学可以关注下,https://github.com/reactphp;类似的项目还有https://github.com/amphp; 都是异步单进程的执行方式;php并没有大家想的那么局限。
1
kuxiazi 2017-06-27 23:32:52 +08:00 via Android
有公网 ip 还有必要折腾穿透吗?
|
2
slince OP @kuxiazi 看应用场景;如果你要开发微信公众号或者远程协作开发 app ; 你每敲完一个功能是不是还得把代码部署到服务器上呢?直接让远程的人访问自己本地多好
|
3
lyhiving 2017-06-27 23:47:36 +08:00 via Android
赞一个
|
4
wwqgtxx 2017-06-28 00:09:04 +08:00
其实还可以在局域网用 ipref3 试试看单线程能不能跑满带宽
|
5
liuxu 2017-06-28 02:51:12 +08:00 via Android
马克,明天详细看看代码
|
6
GoBeyond 2017-06-28 08:08:04 +08:00 via Android
竟然是用 php 实现的。。感觉一些技术值得借鉴
|
7
askfilm 2017-06-28 08:42:20 +08:00
赞啊
|
8
airycanon 2017-06-28 08:46:40 +08:00
看了 Github 才发现是南京的大牛,再看以前发过的帖子,我好像去你们公司面试过……
|
9
Clarencep 2017-06-28 08:51:46 +08:00
话说即使不用 frp 与 ngrok 也可以直接用 ssh -f -NT -R ... 何必自己造个轮子
不过为 LZ 的研发精神点赞~ |
11
slince OP @airycanon shein 是吧 我已经离职了 没更新资料算是怀念吧 不错的公司 在的时候各种抱怨 走的时候各种不舍
|
13
batnss 2017-06-28 09:43:43 +08:00
我这几天还想用 workerman 弄一个类似的来着 看来不用了
|
16
imagecap 2017-06-28 09:56:18 +08:00
内网穿透还是要有公网 IP,
不过内网穿透好处自然有很多,比如: 内网可以配个好点的机器跑复杂点的程序,换成公网高配的成本比内网自己配的要高很多。 |
18
wu1990 2017-06-28 10:07:34 +08:00
swoole 欢迎你
|
19
shuimugan 2017-06-28 10:14:14 +08:00
终于看到有用 reactphp 做的东西了,赞
|
20
slince OP @batnss 单进程再同步阻塞的话效率让人难受; reactphp 也是单进程的不过机制是 io 多路复用,类似于 nodejs 的执行方式;这个效率会高很多,尤其是写这种 socket 服务;
|
22
slince OP @shuimugan react 其实有一些实际应用了,不过基本上都被当做实验性质,这点比较遗憾;
ps: 除了 reactphp 还有一个项目也值得关注 amphp( https://github.com/amphp ) 跟 reactphp 一样的原理,名气差点 |
23
ajan 2017-06-28 11:09:09 +08:00
ngrok 不是有 php 版么?
|
26
hhacker 2017-06-28 11:46:58 +08:00
已 star 好东西啊
|
27
slince OP @ajan 命令行不是更方便吗;现在的 php 项目基本都是多文件的;不像以前都写着一个文件里;把文件下载下来执行下了事了
|
29
jz361 2017-06-28 15:52:04 +08:00
顶,来学习的
|
30
Actrace 2017-06-28 16:44:58 +08:00
CLI 领域,PHP 确实有很多独到之处,因为 PHP 核心代码是很稳定的。比菜鸡自己用其他语言实现相同功能更稳定跟快速。
但是,php 封装了不少挺潮流的东西,本身来说,socket 也只是给标准 socket 库套了一下。其他类似的东西,比如 ev,libev,event 都有,什么多路复用,多线程都能搞。问题就在于大多数的库都没有把 bug 修完,偶尔会埋个坑,然后隔个几年才发现。对于生产环境来说,这是难以接受的(以前用 pthreads 写过服务,发现很多坑,隔了一年才修复)。 另外的一点就是内存的控制了,因为自动类型,这一块完全就是由 PHP 内核在管理,然后目前为止,内存的回收都还没有做完美。有些服务要运行个 1 年 2 年,结果就是内存不够用了,悲剧。 |
31
slince OP @Actrace 对的内存回收是个麻烦,这个也是我目前比较担心的问题,为此我在项目中加了不少定时器去维护几个核心的集合防止内存溢出,好在现在看起来并没有什么异常
|
32
Actrace 2017-06-28 20:13:52 +08:00
@slince 目前唯一靠谱的解决方案是学 apache 或者 fastcgi,就是负责业务的进程在执行一定次数的业务后结束掉,由守护进程再开新的业务进程。然后守护进程尽量写简单一些,尽量少点在守护进程里进行创建变量之类的操作。
|
33
dailaosan 2017-06-28 21:41:49 +08:00 via iPhone
Jj
|
34
a308057848 2017-06-30 09:52:33 +08:00
👍 厉害了.
|
35
slince OP @a308057848 3q
|