V2EX › sun2920989 的所有回复 › 第 4 页 / 共 29 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2 3 4 5 6 7 8 9 10 ... 29

❮

❯

2021-09-22 19:54:02 +08:00

回复了 vjnjc 创建的主题 › 问与答 › ipip.net 有代替品吗

早年用过 ip138,试了下,还能打开.

2021-08-26 14:10:59 +08:00

回复了 AlexPUBLIC 创建的主题 › 宽带症候群 › 搞了一个对等 1G 的宽带

@AlexPUBLIC #29 哪里还能再开么可以聊聊吗?

2021-08-04 18:56:09 +08:00

回复了 zhoudaiyu 创建的主题 › 音乐 › 心情低落，心理很乱，分享一首使人心静的音乐吧

@zhoudaiyu #8 等你入职新公司就好了..

2021-08-03 11:47:27 +08:00

回复了 EKkoGG 创建的主题 › CDN › 第一次配置 CDN 的问题请教，成功了请大哥喝奶茶

@makizcy #2 哈哈想法一样 ...

2021-08-03 11:46:57 +08:00

回复了 EKkoGG 创建的主题 › CDN › 第一次配置 CDN 的问题请教，成功了请大哥喝奶茶

直接测试 ip/static/images/xx.jpg 是否可以访问,如果不能,请设置回源 host.

2021-06-02 10:53:10 +08:00

回复了 sun2920989 创建的主题 › PHP › 一个可以在 PHP -FPM 环境来并发访问 HTTP 接口的工具类

@sxbxjhwm #44 好的谢谢.

2021-05-28 17:03:38 +08:00

回复了 vevlins 创建的主题 › 程序员 › lowcode 是不是在断后人的路？

本来想着表达完观点就行了不想在探讨这个话题了,可是你的回复让我看的莫名其妙.
我上个回复全文没有提过 lowcode 一次.也没有说你之前的发帖内容与 lowcode 有什么关系.
我甚至感觉你是不是阅读理解有什么问题,还是我表达的不明白,这没有攻击的意思,就是单纯的疑问.大家应该都听懂了我的意思就你没懂.
既然你非让我说的这么明白,那我就直接说了,如有得罪很抱歉

我对于你 "反对 lowcode 平台" 的观点,既不支持,也不反对,因为我不太了解 lowcode.但是我觉得你这个人双标.

这样听明白了吗?
这下应该表达明白了吧,不再回复了.谢谢.

2021-05-28 16:36:16 +08:00

回复了 vevlins 创建的主题 › 程序员 › lowcode 是不是在断后人的路？

友情提示,继续讨论的各位可以查阅楼主最近几条发帖纪录.
他想要
"一个可以固定模板来快速替换视频文本图案等元素的方案"
"一个根据建表语句 sql 半自动绘制 ER 图的工具"
"一个可以清晰完整地描述表单的组成、分步、联动等关系的表单描述语言"
"一个可以自动进行前端测试的方案因为可以节省人力并提高覆盖率"
以上文字都取材于楼主贴内
但是他却不希望他的老板想要
"一个可以通过拖拽一些组件来快速生成应用的方案"
因为这
"没价值","断后人路"
言尽于此.勿回,不再回复.

2021-05-10 16:51:18 +08:00

回复了 sun2920989 创建的主题 › PHP › 一个可以在 PHP -FPM 环境来并发访问 HTTP 接口的工具类

@sxbxjhwm #42 只是为了做不阻塞情况下的并发数量限制.

2021-05-10 16:27:28 +08:00

回复了 sun2920989 创建的主题 › PHP › 一个可以在 PHP -FPM 环境来并发访问 HTTP 接口的工具类

一个新的思路是,既然 curl_multi 的管道复用,会尽可能的使用已有连接,那么对于未超过限制的请求,每次创建一个 curl_multi_init 和 curl_init,并打开 curl_multi 的管道复用,对于超过限制的请求,就使用已存在的 curl_multi_init 再次发送一个新的 curl_init.至此,已经基本可以使用 curl_multi 实现我之前用 tcp 模拟时实现的全部功能.唯一的问题和之前测试结果一样,多个 curl_multi_init 实例同时存在同时执行时效率较差,比使用 tcp 模拟或使用全局唯一的 curl_multi_init 效率下降非常多.
@sxbxjhwm #39 仅供参考.

2021-05-10 13:16:52 +08:00

回复了 sun2920989 创建的主题 › PHP › 一个可以在 PHP -FPM 环境来并发访问 HTTP 接口的工具类

@sxbxjhwm 主要是使我的工具类可以在项目内尽量通用，尽量复用现有逻辑。而不是将每个地方都做很多修改。

2021-05-10 11:17:32 +08:00

回复了 sun2920989 创建的主题 › PHP › 一个可以在 PHP -FPM 环境来并发访问 HTTP 接口的工具类

@sxbxjhwm #35 测试时还发现一个有意思的事情,在设置了启用管道时,我的倾向是期望在没有超过并发数之前尽可能使用新的连接,虽然建连也有一点损耗但是由于获取数据比较慢,所以也会比复用已有连接更快.但是 curl 库的默认方式似乎是优先尽可能复用已有的链接,直到一条连接上传输的请求超过阈值之后,才会去开一个新的连接.鉴于这个倾向的不同,所以即使我的 curl 版本符合这个区间,也不是我期望的效果.

2021-05-10 11:15:09 +08:00

回复了 sun2920989 创建的主题 › PHP › 一个可以在 PHP -FPM 环境来并发访问 HTTP 接口的工具类

@sxbxjhwm #35 找到三个参数,按照 libcurl 文档的描述,搭配使用可以实现通过 http1.1 管道来控制并发的效果.CURLMOPT_PIPELINING,CURLMOPT_MAX_HOST_CONNECTIONS,CURLMOPT_MAX_PIPELINE_LENGTH.但是这三个参数如果搭配使用对 curl 的版本有着严格的要求,需要大于等于 7.30 小于 7.62.我这边版本和线上一致不符合这个区间.所以没有测试出全部效果.不过设置 CURLMOPT_PIPELINING 为 1 来启用管道是可以实现的.

2021-05-10 11:00:17 +08:00

回复了 sun2920989 创建的主题 › PHP › 一个可以在 PHP -FPM 环境来并发访问 HTTP 接口的工具类

@sxbxjhwm #35 好的.我了解一下.

2021-05-10 10:30:50 +08:00

回复了 sun2920989 创建的主题 › PHP › 一个可以在 PHP -FPM 环境来并发访问 HTTP 接口的工具类

@sxbxjhwm #33 是的,php-fpm 本身是同步的,总有一个地方要阻塞来获取网络请求的结果.

2021-05-10 10:09:56 +08:00

回复了 sun2920989 创建的主题 › PHP › 一个可以在 PHP -FPM 环境来并发访问 HTTP 接口的工具类

@sxbxjhwm #31 我这边需要在 fpm 环境来实现这些效果.加速一些页面的打开效率.所以不方便使用后台脚本的方式.除非再做一次 fpm 进程与后台脚本之间的信息交互,总之还是非常感谢您的持续回复,极大的拓宽了我对 curl_multi 的了解.

2021-05-10 09:09:35 +08:00

回复了 sun2920989 创建的主题 › PHP › 一个可以在 PHP -FPM 环境来并发访问 HTTP 接口的工具类

@sxbxjhwm 嗯看到了。问题还是那个，如果请求不是一起添加进去的，而是一个一个添加的话，程序将要么在超过并发限制时报错，要么在这时阻塞。没有其他的好办法。虽然 http1.1 的管道是一个建议最好不要使用或者少使用的特性，但是确实可以解决我遇到的问题。

2021-05-10 09:00:59 +08:00

回复了 sun2920989 创建的主题 › PHP › 一个可以在 PHP -FPM 环境来并发访问 HTTP 接口的工具类

@sxbxjhwm 好的感谢。我参考一下。

2021-05-08 20:57:14 +08:00

回复了 sun2920989 创建的主题 › PHP › 一个可以在 PHP -FPM 环境来并发访问 HTTP 接口的工具类

找到一个参数，CURLMOPT_PIPELINING，也许有一些作用，周一尝试一下。感谢您的回复，让我对 curl 有了更多的理解。

2021-05-08 20:18:43 +08:00

回复了 sun2920989 创建的主题 › PHP › 一个可以在 PHP -FPM 环境来并发访问 HTTP 接口的工具类

更换了一个思路,使用全局唯一的 curl_multi_init,每次请求时创建 curl_init 并添加,然后执行一个循环的 curl_multi_exec,获取数据时执行 curl_multi_select 和 curl_multi_getcontent.整体性能和我使用 tcp 连接基本差不多.但是有两个问题,一是此时等待数据时针对某一个变量进行等待其实已经没有意义,需要等待所有结果返回时第一个 wait 才能返回,然后后面的 wait 就是立即返回.二是此时没有很好的方式来控制并发数,因为我无法在一个 curl_init 中不获取返回值的情况下再传输一次 http 请求数据,所以此时如果判断超过了并发限制,只能报错,无法自动处理.而使用 tcp 时由于 http1.1 的管道,我可以不读取第一次的响应结果直接再次发送第二个请求,然后按照顺序来获取每一个响应.

1 2 3 4 5 6 7 8 9 10 ... 29

❮

❯