• 我还是比较推荐别在服务器直接起 smtp, 用类似https://sendcloud.sohu.com 或者 mailgun 啥的会好一点

  • 阿里 465 端口被禁用了

  • 我特别好奇在机器需要的不太多的情况下(20台以内),

    大家是如何管理docker 的: 包括 部署 健康检查 日志收集

  • Let's Encrypt 爬坑记 at 2019年06月28日

    不影响啊

  • Let's Encrypt 爬坑记 at 2019年06月28日

    acme.sh 可以使用dns 级别的验证 生成wildcard 的证书

    acme.sh 已经支持了 ali_dns 了

  • 你可以单独引入这个 js 的 没必要编译一个大的application.js

  • 我是用stimulus 解决了以前困扰我的各种 turbolinks 的问题 以前遇到各种重复绑定的, 现在都靠 disconnect 解耦

  • 回头在我的穷困潦倒搬瓦工上装装看看效果

  • 现在 vscode 支持 远端编辑了 可以试试哟

  • 如果是在rails 中处理的话 建议如非必要, 不要上 react的 router 和 redux 还是仍由rails 管理路由, 就加载个 react.js 在head 中 之后去找dom 渲染

  • 是时候普及一下 kill 和 linux 空间占用的知识了

    在linux 删除文件后, 如果有进程在之前打开了这个文件, 则这个删除的文件的空间是不会释放掉的 ,

    (帖子提到的拆分日志后 puma之后产生的日志就消失了 是因为之前puma 进程打开的文件句柄, 实际上是被删除了的 所以就会消失)

    需要让打开这个文件的进程释放这个文件句柄,

    那么最粗暴的释放句柄的方式是?

    结束掉这个进程就好了...

    然而 有些关键是有些进程并不方便被直接结束 (比如这里的puma 进程)

    其实 kill 并不像字面意义那样完全杀气腾腾, 其实里面还隐藏了一个叫做信号量的东西

    发送不同的信号量会实现不同的作用, 这个具体得看进程程序是咋写的, 只是一般情况下默认的信号量大家都是结束进程罢了

    根据 puma 的文档 https://github.com/puma/puma/blob/master/docs/signals.md

    kill -HUP puma.pid 就会根据路径重新打开文件句柄, 而不影响其他的服务

    (重新打开新的文件句柄, 则又发现了新的文件, 则日志就可以正常输出了)

    so jasl 的这个是完全可行的

  • 额? 其实 也可以在 gems 里找到对应gem 的源码?

  • 社区讨论 stimulus 的本身不多, 还是挺遗憾的. 但是用起来确实非常爽, 就是因为太简单了,反而不知道怎样去跟其他人介绍这东西

  • "在状态变化低于3个左右的一个界面"

    这是我自己的一个使用惯例

    就是 一个UI 模块中, 有包含3个以上的状态, 任何一个状态的变动都会引起新的ui变动

    其实这个的定义是来自 react 的本质, 就是 数据 决定 UI,

    比如登录窗口 一个地方, 有 用户名 清空 有 密码控制显示 有没填写密码警告 没填写用户警告 , 这种状态就比较多(>3), 比较复杂, 用 react 组件写, 逻辑就比较清晰, 只需要关注 state 就好. 当然 你用 stimulus 去操作这些也可以, 只是会疲于在各个dom 里去隐藏或者显示啥的, 比较麻烦一点 逻辑中混用的ui 操作比较多

    但是类似于 点击后加载一个数据, 或者点击之后加载个报表, 点击之后读取 搜索条件 去搜索 这种状态就只有加载和未加载, 直接上 stimulus + SJR + turbolinks 就特别轻松, 无脑写就好

  • 服务本身应该还好 m$ 对中国市场还是很重视的 gov 不是还拿到了windows 的源码么 主要是墙高了 或者国家从安全层面考虑 要求私有代码必须落地国内

  • 在我举的例子当中, 当进行数据库事务的时候 本机的 CPU 是闲置的状态, 这个时候切换上下文是会提高cpu 效率的, 而这种情况的变种我觉得还经常会发生(瓶颈在数据库). 所以我会对您那个公式有点不同意见

  • 简化一下情况

    假设运行后端的服务器只有1核的CPU

    之后开一个 PUMA , puma 跑20 个线程,

    现在有大量数据库事务的任务,每个事务执行需要1s,

    再假设除了执行数据库, 其他操作小于1ms 的响应

    如果pool的大小是2, 那么是不是此时就只能并发两个请求?

    是否能等效理解为 在执行事务的时候, 此时服务器的cpu 是空闲状态, 但是却因为数据库连接池的问题不能进行服务?

    如果此时连接池开到20, 将puma 的线程池满

    似乎就可以进入20个并发了

    或者我的理解有问题, 有一些概念上的错误?

  • 这个线程池个数设置方式 应该比较靠谱.

    特例是, 在puma 的一个 thread 里并行用到了一个以上的连接. 但是似乎我也没想到这种情况的场景.

    而且算法是在 puma max threads的情况下的, 一般压力不会那么大

  • 看上去都是数据库?

    加大点 pool 比如 30 - 50 试试 ?

  • 😆 不能老让小姐姐们玩 postman 不是么......

    最后还是决定牺牲一点性能, 在 rails-api 上 继续写传统 view, 复杂点的就 webpacker react 跑一下凑凑热闹

    在pv 没到10m 之前 性能损失在20% 以下都还能接受

  • 我试试 @kayakjiang

  • 理论上你可以让puma 承担所有工作, 只是说 puma 是基于 ruby 的 , 效率没有基于 nginx 的高

    比如你开一个puma 进程, 进程再跑20个线程

    但是很有可能你一个网站就有超过5个静态资源, 之后只要有4个访问并发, 你puma 的线程数就占完了, 新访问就没办法进来了

    而nginx 首先在处理静态资源的情况下效率就比puma 高很多, 对 wait 的处理也非常好, 对于静态资源, 几千个并发随便来,

    同时就算puma 资源耗完了, nginx 也可以先将连接进入wait 状态, 等待 puma 可以接受新资源了, 再进行转发

    再就是一些跟网站本身没有多大联系的功能, 比如 SSL证书, 或者多个网站部署到同一个ip 等等, 要说用puma 可以不可以实现, 也可以, 但是复杂性大大增强了, 耦合性也急速的膨胀. 然而对于这种东西, nginx 处理起来驾轻就熟, 直接上配置就好了

    总结下来, 就是专业的事情, 专业的工具来干. 用螺丝刀也可以钉钉子, 但是如果有锤子, 还是上锤子比较好

  • 邮件写的已经要delay了

  • 印象中猎聘是在八里庄那边 没想到也是用的 rails 啊

  • 不算不算 😁