halo
halo copied to clipboard
halo-dev
连接远程数据库超级慢
Server 版本：1.3.2 Admin 版本：1.2.0 数据库：MySQL 5.7.18 运行模式：production
如题，目前发现连接远程的数据库超级慢，我后端服务器在上海，然后数据库服务器在北京，都是用腾讯云的服务，数据库用的是云服务，而不是自建的；数据库方面排查延迟很低，ping都是在30ms左右，并且其他应用访问速度很快(其他应用服务器和halo博客在同一台机器(上海地域)，连接的是同一个mysql数据库(北京地域))
博客地址: https://www.mogody.com
可以随便打开一篇文章，速度是肉眼可见的慢，每个请求基本都是在3-4s左右。测试切换到内网数据库，访问速度有明显提升，每个请求差不多在300ms左右，但是还是不如 1.2.0 版本的
@JohnNiang debug模式是哪个配置呢？
在 application.yml 中新增配置以下内容：
logging:
level:
run.halo.app: DEBUG
org.hibernate: INFO
org.hibernate.type.descriptor.sql.BasicBinder: INFO
org.hibernate.type.descriptor.sql.BasicExtractor: INFO
观察了大半天，日志中除了 Token 相关的之外，只有这一条信息：
2020-06-13 06:49:08.123 WARN 6 --- [XNIO-1 task-1] com.zaxxer.hikari.pool.PoolBase : HikariPool-1 - Failed to validate connection com.mysql.cj.jdbc.ConnectionImpl@164183d7 (No operations allowed after connection closed.). Possibly consider using a shorter maxLifetime value.
MySQL服务器的 wait_timeout 的配置是 3600
可能得靠缓存来解决这个问题了。
这个问题的原因是什么？链接远程服务器慢是肯定的，但是也不至于这么慢。而且我博客也基本上没什么文章，如果直接加缓存来加速，是否意味着程序代码上面还有优化的空间呢？
2020-06-13 06:49:08.123 WARN 6 --- [XNIO-1 task-1] com.zaxxer.hikari.pool.PoolBase : HikariPool-1 - Failed to validate connection com.mysql.cj.jdbc.ConnectionImpl@164183d7 (No operations allowed after connection closed.). Possibly consider using a shorter maxLifetime value.
这个错误日志报的非常频繁，
可能得靠缓存来解决这个问题了。
这个问题的原因是什么？链接远程服务器慢是肯定的，但是也不至于这么慢。而且我博客也基本上没什么文章，如果直接加缓存来加速，是否意味着程序代码上面还有优化的空间呢？
是的，代码上确实有很多优化空间，一个页面查询太多次数据库，导致查询时间线性递增。
2020-06-13 06:49:08.123 WARN 6 --- [XNIO-1 task-1] com.zaxxer.hikari.pool.PoolBase : HikariPool-1 - Failed to validate connection com.mysql.cj.jdbc.ConnectionImpl@164183d7 (No operations allowed after connection closed.). Possibly consider using a shorter maxLifetime value.这个错误日志报的非常频繁，
这个日志非常有用，基本判定为连接池配置和 MySQL 那边的配置问题，通过这个异常搜索到：
- https://github.com/brettwooldridge/HikariCP/issues/856
- https://github.com/brettwooldridge/HikariCP/issues/1131
后面有时间我们将验证一下。
- 大概率是halo业务代码或者配置层面的问题，我用的mysql是云数据库，不是自建的，参数都是走默认的，原则上不会有很大问题。
- 这个数据库稳定运行很久了，就最近部署了一个全新的halo应用，只有halo应用非常慢
- 其他应用性能都非常ok，稳定快速，延时都是在正常跨地域连接延时内，而且halo和其他应用都是部署在同一地域不同可用区的k8s集群内，配置什么的和其他应用都是一样的
1. 大概率是halo业务代码或者配置层面的问题，我用的mysql是云数据库，不是自建的，参数都是走默认的，原则上不会有很大问题。 2. 这个数据库稳定运行很久了，就最近部署了一个全新的halo应用，只有halo应用非常慢 3. 其他应用性能都非常ok，稳定快速，延时都是在正常跨地域连接延时内，而且halo和其他应用都是部署在同一地域不同可用区的k8s集群内，配置什么的和其他应用都是一样的
是的，下一步得考虑缓存所有页面了，减少数据库访问次数。
我感觉应该要优化sql语句以及减少不必要的查询，而不是加缓存。博客类应用其实数据量和访问量并不大，是完全不需要用到缓存的，如果用了缓存本质上也是治标不治本。
我感觉应该要优化sql语句以及减少不必要的查询，而不是加缓存。博客类应用其实数据量和访问量并不大，是完全不需要用到缓存的，如果用了缓存本质上也是治标不治本。
你可能误解了我的意思了。这里缓存是指直接渲染页面成静态内容，缓存在内存或磁盘。
如果是因为 SQL 执行速度太慢，是需要着重优化 SQL；但是因为数据库连接太慢，我认为更重要的是要优化一下为什么连接如此慢。减少不必要的 SQL 的幅度也不会太大，该慢仍然会慢（当然，我们也会努力减少不必要的查询，或改进为并发查询）。
嗯，这样确实是可以解决问题的。但是个人还是感觉要从两点出发：
- 减少不必要的查询
- 优化SQL语句效率
- 列表尽量避免n+1查询
这个才是根本上解决问题的，直接缓存页面还要考虑页面的更新策略等等，其实加重了设计，也是治标不治本的表现
用了latest版本访问，无论是mysql和h2版，当数据量级达到1w左右的时候，查询非常慢，单个文章的查询基本在5-6s加载完成。排查中导出数据到mysql，单个查询，速度并不慢【20-100ms】，我跟踪代码进去，单个文章的关联查询多，还会查询上一篇和下一篇的文章。每一个查询递归 加起来，确实非常慢 【10106.wang】
用了latest版本访问，无论是mysql和h2版，当数据量级达到1w左右的时候，查询非常慢，单个文章的查询基本在5-6s加载完成。排查中导出数据到mysql，单个查询，速度并不慢【20-100ms】，我跟踪代码进去，单个文章的关联查询多，还会查询上一篇和下一篇的文章。每一个查询递归 加起来，确实非常慢 【10106.wang】
用了latest版本访问，无论是mysql和h2版，当数据量级达到1w左右的时候，查询非常慢，单个文章的查询基本在5-6s加载完成。排查中导出数据到mysql，单个查询，速度并不慢【20-100ms】，我跟踪代码进去，单个文章的关联查询多，还会查询上一篇和下一篇的文章。每一个查询递归 加起来，确实非常慢 【10106.wang】
感谢问题的排查。性能优化问题将会是 1.5.x 的重点。
@JohnNiang: Reopened this issue.
In response to this:
/reopen
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
![f2c-ci-robot[bot] avatar](https://avatars.githubusercontent.com/in/179827?v=4 "Published by a pub.dev verified publisher"){kind=small}