V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  sun2920989  ›  全部回复第 1 页 / 共 26 页
回复总数  520
1  2  3  4  5  6  7  8  9  10 ... 26  
34 天前
回复了 vjnjc 创建的主题 问与答 ipip.net 有代替品吗
早年用过 ip138,试了下,还能打开.
61 天前
回复了 AlexPUBLIC 创建的主题 宽带症候群 搞了一个对等 1G 的宽带
@AlexPUBLIC #29 哪里 还能再开么 可以聊聊吗?
@zhoudaiyu #8 等你入职新公司就好了..
@makizcy #2 哈哈 想法一样 ...
直接测试 ip/static/images/xx.jpg 是否可以访问,如果不能,请设置回源 host.
@sxbxjhwm #44 好的 谢谢.
151 天前
回复了 vevlins 创建的主题 程序员 lowcode 是不是在断后人的路?
本来想着表达完观点就行了不想在探讨这个话题了,可是你的回复让我看的莫名其妙.
我上个回复全文没有提过 lowcode 一次.也没有说你之前的发帖内容与 lowcode 有什么关系.
我甚至感觉你是不是阅读理解有什么问题,还是我表达的不明白,这没有攻击的意思,就是单纯的疑问.大家应该都听懂了我的意思就你没懂.
既然你非让我说的这么明白,那我就直接说了,如有得罪很抱歉

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

这样听明白了吗?
这下应该表达明白了吧,不再回复了.谢谢.
151 天前
回复了 vevlins 创建的主题 程序员 lowcode 是不是在断后人的路?
友情提示,继续讨论的各位可以查阅楼主最近几条发帖纪录.
他想要
"一个可以固定模板来快速替换视频文本图案等元素的方案"
"一个根据建表语句 sql 半自动绘制 ER 图的工具"
"一个可以清晰完整地描述表单的组成、分步、联动等关系的表单描述语言"
"一个可以自动进行前端测试的方案 因为 可以节省人力并提高覆盖率"
以上文字都取材于楼主贴内
但是他却不希望他的老板想要
"一个可以通过拖拽一些组件来快速生成应用的方案"
因为这
"没价值","断后人路"
言尽于此.勿回,不再回复.
@sxbxjhwm #42 只是为了做不阻塞情况下的并发数量限制.
一个新的思路是,既然 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 仅供参考.
@sxbxjhwm 主要是使我的工具类可以在项目内尽量通用,尽量复用现有逻辑。而不是将每个地方都做很多修改。
@sxbxjhwm #35 测试时还发现一个有意思的事情,在设置了启用管道时,我的倾向是期望在没有超过并发数之前尽可能使用新的连接,虽然建连也有一点损耗但是由于获取数据比较慢,所以也会比复用已有连接更快.但是 curl 库的默认方式似乎是优先尽可能复用已有的链接,直到一条连接上传输的请求超过阈值之后,才会去开一个新的连接.鉴于这个倾向的不同,所以即使我的 curl 版本符合这个区间,也不是我期望的效果.
@sxbxjhwm #35 找到三个参数,按照 libcurl 文档的描述,搭配使用可以实现通过 http1.1 管道来控制并发的效果.CURLMOPT_PIPELINING,CURLMOPT_MAX_HOST_CONNECTIONS,CURLMOPT_MAX_PIPELINE_LENGTH.但是这三个参数如果搭配使用对 curl 的版本有着严格的要求,需要大于等于 7.30 小于 7.62.我这边版本和线上一致不符合这个区间.所以没有测试出全部效果.不过设置 CURLMOPT_PIPELINING 为 1 来启用管道是可以实现的.
@sxbxjhwm #35 好的.我了解一下.
@sxbxjhwm #33 是的,php-fpm 本身是同步的,总有一个地方要阻塞来获取网络请求的结果.
@sxbxjhwm #31 我这边需要在 fpm 环境来实现这些效果.加速一些页面的打开效率.所以不方便使用后台脚本的方式.除非再做一次 fpm 进程与后台脚本之间的信息交互,总之还是非常感谢您的持续回复,极大的拓宽了我对 curl_multi 的了解.
@sxbxjhwm 嗯看到了。问题还是那个,如果请求不是一起添加进去的,而是一个一个添加的话,程序将要么在超过并发限制时报错,要么在这时阻塞。没有其他的好办法。虽然 http1.1 的管道是一个建议最好不要使用或者少使用的特性,但是确实可以解决我遇到的问题。
@sxbxjhwm 好的 感谢。我参考一下。
找到一个参数,CURLMOPT_PIPELINING,也许有一些作用,周一尝试一下。感谢您的回复,让我对 curl 有了更多的理解。
更换了一个思路,使用全局唯一的 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 ... 26  
关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1075 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 45ms · UTC 22:28 · PVG 06:28 · LAX 15:28 · JFK 18:28
♥ Do have faith in what you're doing.