V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  lolizeppelin  ›  全部回复第 24 页 / 共 52 页
回复总数  1023
1 ... 20  21  22  23  24  25  26  27  28  29 ... 52  
HTTP 的请求就不应该有阻塞
HTTP 设计本身就是无状态的才会有 fast cgi 这样的形式,http 请求本身就不应该有需要长时间执行的调用

你要实现 B 请求在 A 未完成的时候阻塞本身就是错误的思路,违背了 HTTP 协议的本意
如果 B 需要依赖 A 完成,那么 B 请求发现 A 未完成的时候直接返回 A 未完成,而不是阻塞

由客户端轮询 B 请求,直到成功执行

否者,需要设计成服务端通知模式,这就需要 websocket
2019-09-06 10:17:22 +08:00
回复了 JASONWOOD 创建的主题 云计算 阿里云文档抄袭 AWS
有哪家云不借鉴 aws 的可用拿石头砸他................
2019-09-06 10:09:53 +08:00
回复了 b00tyhunt3r 创建的主题 程序员 在子进程中执行 execve 之后子进程自身处于什么状态?
你 fork 以后啥都没 进程不退出还能干啥 233
@aieike

自己 google 一下
你执行的 shell 函数,最终实现是 fork 了一次,阻塞 wait,所以卡住
改成 fork 两次,直接 os._exit(0), 给 pid 1 接管你的子进程就是
这和写守护进程的原理是一样的

所有的外部进程调用都是 fork exec 的组合,这是 linux 编程基础,只盯着 python 自然一头雾水
不要开线程去 直接 fork 两次 exec 就完事
你又不关心执行结果 不要开线程
2019-09-05 10:34:04 +08:00
回复了 liangxunli 创建的主题 PHP PHP 高并发处理
唯一可以做的,就是对一些内容变化少的接口加缓存

上 openrestry
2019-09-05 10:32:31 +08:00
回复了 liangxunli 创建的主题 PHP PHP 高并发处理
估计是做区块链的 量化交易平台
这个并发很正常,全是 api 请求

换语言什么的就算了,等你们换好了估计公司都不在了 233
出了问题也担不起,老老实实家机器别折腾了,免得背锅 233
2019-09-03 21:14:09 +08:00
回复了 nullboy 创建的主题 Linux 群晖这种小内存真的能挂 PT?
这伤个屁

最伤的应该是流媒体,播放的时候写缓存数据,大量的写,电影越大生成的缓存文件也越大
这部分不用内存盘,嘿嘿,保障写入量大大滴
群晖我不清楚,反正 jellfin 是这样的,估计群晖的流媒体也好不到哪去
2019-09-03 21:08:07 +08:00
回复了 Breadykid 创建的主题 MySQL 刚才,领导对我的 sql 提出了建议
2 和 3 的核心问题是一样的


查询过程无外乎


数据库 应用层
从硬盘读取数据——数据库解析数据——复制到网路层 ~~~~~~~~ 网络层复制到应用程序——应用程序解析


数据库开销
硬盘读取开销~解析开销~复制 /传输开销


应用层开销
解析开销~传输开销

这些省不了的开销,无非是放在哪里而已

用数据库解析, 数据库 cpu 消耗大,但是传输开销小
应用解析,数据库 cpu 小,应用服务器 cpu 开销大,传输开销大
但是数据量大起来以后,传输开销自然就不能忽视了

如果 group by/join 前的数据远远大于处理后,思考两点
1.应用层来 group/join,数据库计算量的虽然降低,但是好处是否会被大量传输抵消?
2.一定量级上数据库层的 group/join 的否效率是否远远好于应用层?
3.上述一定量级是如何判断?
4.数据库层的 group/join 是否能降低硬盘 IO ?
5.应用层 group/join 事务问题怎么解决


-------------------------------------------------------------------------------------
1.其他数据库要用函数索引,也需要索引函数对象,例如 index(int(column))
2.mysql 不能多核并行查询,这个是死穴,当然少量数据肯定比你自己做强多了
3.mysql 没有 hash join 和 merge join 稍微大的数据 join 起来肯定要死翘翘,但是少量数据又有索引肯定比应用层做好得多.
至于到底多少数据量算大这个嘛............
4.分表是下策,mysql 的表分区也是个残疾...上策嘛....换数据库!!

所以说!!早点换 PG,压根就不纠结这些问题...真要纠结这些问题的时候,就是你换大数据的时候!!
PG 一统江湖!
你读一下 zipfile 的源码就知道了

根本原因在于 zip 设计本身,每一个文件需要写在这个文件的前分配空间写一段校验信息,文件越多校验的块也越多,zip 的性能自然就差
加上 python 本来计算就慢,这种方式更放大了 python 的缺陷

文件数量多非常不适合用 zip,非要用 zip 不如调系统的解压工具解压
2019-09-02 14:49:00 +08:00
回复了 zhiwoda123 创建的主题 硬件 四万块买一个外星人游戏本值不值
@zhiwoda123
还没出啊 刚在 CJ 上展出过而已,你自己搜索 Y9000x
2019-09-02 14:39:04 +08:00
回复了 zhiwoda123 创建的主题 硬件 四万块买一个外星人游戏本值不值
Y9000X,还没出,配显卡坞. 我不信外星人散热能罩得住 I9+2080
2019-09-02 14:36:37 +08:00
回复了 zhiwoda123 创建的主题 硬件 四万块买一个外星人游戏本值不值
不值,散热跟不上的把

买联想那个新出的 I9 不带显卡, 然后雷电 3 外接显卡盒。
不都是扩展坞接多显示器么,还直接用笔记本键盘啊?
2019-09-02 14:16:46 +08:00
回复了 lolizeppelin 创建的主题 Python 求一个编译号的 Python 包 yappi 要 python3.6 的
发现 https://anaconda.org/可以下载
orz 真是救了老命了
楼上真是搞笑, 虚拟化用傻了?
一台机虚拟出 10 台是算例翻倍了还是 IO 翻倍了

没钱没机器还上分布式,你当做实验啊?
直接物理机都不够用, 还套一层虚拟化?
思路都是找时序型数据库
PG 正好有时序插件, 比专门的时序数据库差一点,但是功能上是标准的 sql
时序的数据? 装 pg 的 timescaledb 插件啊

不用自己弄分区和 BRIN 索引了
2019-08-29 13:34:46 +08:00
回复了 hujianxin 创建的主题 程序员 常用 Python 写命令行工具的朋友,你最常用的库是什么?
请使用 python 最牛逼的配置文件兼命令行库 oslo.config

openstack 出品,用过以后你再也不需要用其他命令行 /配置文件库了
没有,目前可以作为微服务参考的 python 项目只有 openstack
1 ... 20  21  22  23  24  25  26  27  28  29 ... 52  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5351 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 38ms · UTC 06:39 · PVG 14:39 · LAX 23:39 · JFK 02:39
Developed with CodeLauncher
♥ Do have faith in what you're doing.