V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  dandankele  ›  全部回复第 1 页 / 共 5 页
回复总数  87
1  2  3  4  5  
最多只能写点通用性的代码,稍微加点复杂逻辑就要乱了。。。每天的时间浪费在大量的 prompt 上。。最大问题是,它竟然能够在回答 A 与回答 B 之间无限循环。。我跟它说回答 A 是不正确的,它给我回答 B ,但回答 B 也是不正确的,接着又给我回答 A 。。。。我特么。。
@vibbow 有个问题,长连接是不是也需要服务端的支持?如果服务端在每次处理完成请求之后主动断开连接(例如对方服务端接口也是没使用长连接的常规的 php 实现的接口),即使客户端支持长连接,也无法维持这个长连接是吗?
106 天前
回复了 dandankele 创建的主题 数据库 同 database 不同 schema 多租户连接池问题
稍微看了下。。我主要问题好像应该还是在 user+password 的切换上,只要能切换用户,那么 set schema 就不是问题。虽然 mysql 的底层 Driver 支持在同一个连接中 changeUser(username,password),但上层的很多库如 mybatis 、hikari 等都不支持明确的对一个连接切换用户,除非我是直接使用底层驱动开发,这显然不是太好。似乎只能采取一些折中的方式了?
106 天前
回复了 dandankele 创建的主题 数据库 同 database 不同 schema 多租户连接池问题
@kd9yYw2RyhQwAwzn 我也用的 AbstractRoutingDataSource ,但你们租户之间都是用的同一个数据库帐号密码进行连接的吗?我现在卡在了数据库帐号密码切换上
github 上有相关的库的吧,我是直接把库拿来然后专门做了一个工具供内部使用的,因为我们有对比数据库表结构的需求。。自己弄个也不难
107 天前
回复了 dandankele 创建的主题 数据库 同 database 不同 schema 多租户连接池问题
另外关于 mysql 中有没有 schema 概念,我也不太清楚哈,没怎么用过其他数据库。。但意思就是那个意思。。每个租户在一个数据库实例中有一个数据库。。另外我看 mysql 术语库中有提到 schema ,https://dev.mysql.com/doc/refman/8.0/en/glossary.html

@lesismal select * from database.table 之前我也看到过,可以算是一个还好的备选方案吧,相比直接在表列上增加租户标识好一点。。


另外每个租户都设置单独用户名和密码主要出于安全考虑,我们是做 toB 的 SaaS 平台,就怕某个 B 被黑了数据库,也难顺着线找到其他的 B 然后再黑一次,虽然代码是一套的= =!
107 天前
回复了 dandankele 创建的主题 数据库 同 database 不同 schema 多租户连接池问题
我在 mysql 官网上看到有提供 C 的[API 接口 mysql_change_user]( https://dev.mysql.com/doc/c-api/8.0/en/mysql-change-user.html),可以在同一个连接中重置会话,然后又看了下官方提供的 java 的 Driver 和相关代码,在 Connection 里果然发现了类似`changeUser`的封装方法。。看样子得进行一波魔改了。。不知道会不会成功
107 天前
回复了 dandankele 创建的主题 数据库 同 database 不同 schema 多租户连接池问题
@LeegoYih 是的啊,各有利弊。。
107 天前
回复了 dandankele 创建的主题 数据库 同 database 不同 schema 多租户连接池问题
@RedBeanIce 我感觉我这情况已经不是改 Hikari 内部实现的问题了,是 mysql 本身好像就不支持在一个连接中直接切换成另一个用户,不切换成另一个用户就看不到其拥有的 schema = =!
107 天前
回复了 dandankele 创建的主题 数据库 同 database 不同 schema 多租户连接池问题
@RedBeanIce 租户数量适中吧,我也想过一个 schema 一个连接池,然后每个池子最大连接数设置为 database 的最大允许的连接数量,空闲时间设置短一点,一个池子如果空闲连接多的话会释放给其他忙的池子。。但感觉又有些不妥。在每个租户都需要较为繁忙时,某个池子的空闲连接来不及释放给另一个池子
107 天前
回复了 dandankele 创建的主题 数据库 同 database 不同 schema 多租户连接池问题
动态数据源我实现了,现在的问题是如何针对我的场景把连接进行池化复用,各位要审题啊
同样也有这个问题。。如果是出于公司业务增长遇到性能瓶颈等问题,想优化,并且也考虑成本,那么直接试试 swoole 一类的。。如果只是单纯的想提高自己的技能水平,为以后就业考虑,那么 java 吧。。虽说 go 与 php 很搭,但是二三线城市 java 就业机会多啊
182 天前
回复了 saka0609 创建的主题 酷工作 常州创业公司招聘 golang
创意产业园 E 座的吗?
238 天前
回复了 tlerbao 创建的主题 程序员 几乎不用的腾讯 CDN 也被刷,欠费 200 块。
@nuk 题中所说 100 个 fpm 进程只是举个例子,当然还得看机器配置。。最主要的意思是如果本身 100fpm 出现了当前的问题,那么我再在当前机器上加入改写的 go 的应用,把一些依赖外部网络请求的部分放到 go 里,是否能降低 web 请求响应时间、是否能降低机器 cpu 消耗


@everyx 是的,大量的 tcp 连接建立和销毁以及 php 进程在网络 IO 阻塞导致的切换。。我现在是想对这方面进行优化


@Twnysta 你所说的“时间不会减少”要看是什么的时间吧。。。如 34 楼老兄所说,如果我有非串行依赖请求,那么我可以用 go/swoole 尝试进行并发请求。。另外把 php 没有连接池、频繁建立和销毁 tcp 连接、频繁网络 io 阻塞导致的进程切换时间都用 go/swoole 来尝试改造,这部分的时间还是能减少的吧。。我所指的能减少的时间是“我服务端对客户端的响应时间”

---

[另外最后再补充下啊] 当前公司给的目标是服务器等成本降本,当前服务器配置下日均 pv 也是千万,业务应用能正常承受,是没问题的。。。所以我的重点目标还是继续优化性能,看看能否再减少服务器。。所以目前找到的优化点是这个 php-fpm 下的网络请求 IO 阻塞问题。具体大家可以看下前面和大家的对话。。实际上 swoole 与 go 都可以,但再出于后期找工作的考虑,所以想选 go ,咱就不再在 go 还是 swoole 等上面纠结了。。咱们就讨论用异步 IO 、连接池、协程处理并发等方面看看能否将传统 php-fpm 模式下的这个问题进行优化?
@everyx 我缓存也是走的网络 IO 。。。现在拿缓存数据也是慢。数据库也已经做过一轮优化了。我在 30 楼回复中留有了一些监控信息。。所以不知道是不是网络 IO 阻塞导致的频繁进程切换
@8355 差不多就是你说的意思,你举的例子是 php 在单个请求处理中,有着多个串行依赖请求外部接口,如果不是串行依赖的,来用 go/swoole 协程并发处理。我所想的是,把多个 php 请求处理(进程级别的,每个进程中处理着串行依赖外部请求)使用 go 协程并发来处理(协程级别的,并发处理多个请求,每个请求里还是处理串行依赖外部请求或者还可以再并发处理外部请求)。。

我目前还没打算重构,我还在评估我的问题用这种方式能否得以解决。。。除了你提到的这些,我这个主题帖的主要问题是在想这种部分重构的情况下,响应时间是否会有所提升。

目前 6 楼的朋友应该是 get 到了我当前的主要问题。。可以把这主题中的 go 换成 swoole 、java 等,但问题是原 100 个 fpm 进程还保留的情况下、机器配置不变的情况下,增加 go/swoole 是否会优化单个请求的响应时间
@leonshaw 目前只是根据少部分监控数据猜测出来的。。php 的调用栈的监控数据显示,每个慢的请求中,都是慢在了从外部服务获取数据的过程(如 fread 、Memcached::get 、Redis::get 之类的),而且消耗的时间上,wall time 挺大的,但是 cpu time 很小。并且服务器网络监控上,服务器带宽、收发数据包 pps 都没有打满。。所以目前是猜测在等待网络 IO 传输数据的过程中进程切换导致的时间消耗。。。进程目前大概是 cpu 核数的 8 倍,但再增加导致 RT 时间变长,减少的话也会变长。。
@8355 意思是改用 go 的话对于响应时间优化并不会有太大帮助?依赖外部服务查询数据的瓶颈主要还是在于网络传输性能与外部服务的性能吗?
@leonshaw 瓶颈分析了啊。。就是依赖外部服务导致网络 IO 大,fpm 进程切换频繁消耗 cpu 资源。。用 go 的话至少是协程、线程级别的上下文切换。。。但是相同服务器配置下,两个放一起能否提升性能就是本文要问的问题
1  2  3  4  5  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3234 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 30ms · UTC 12:05 · PVG 20:05 · LAX 05:05 · JFK 08:05
Developed with CodeLauncher
♥ Do have faith in what you're doing.