早上看到有网友留言说评论提交之后,没有然后……我大概get到了意思,就是ajax提交之后被block住了。我第一反应可能是缓存导致的,但后来一想,并没有在comment的脚本里加缓存啊。于是中午排查了一下,发现了两个可能,一个是session lock,另一个是smtp邮件服务有问题。
我把smtp发送改为了ssl模式,端口是465. 还到阿里云安全组里面去添加了规则。回来测试了一下,发邮件OK了。
session lock这个话题比较专业,这里有一篇文章可以大概了解为什么一个session会把请求block住。简单的说就是你代码里面一个简单的$_SESSION['xxx'] = 'xxx',实际上php要去写入文件,如果同时多个请求都去执行这段代码,那么后面的请求需要等前面的请求把这事儿干完了才能继续,不然只能等着。解决的办法就是在每一个赋值语句后面加上
session_write_close();
这个语句可以在你的php程序执行完之前提前把session lock解锁。如果不执行,那么PHP要等到你当前这个进程执行完毕才会unlock。而在我这次案例里面,因为发邮件的问题导致我的PHP进程被block住,所以如果在发邮件之前有一个session写入,那么其它的要写入session的程序就会被block住,比如我在后台提交了一个请求,要写入某个session,前台某个提交也要写入这个session,那么在后台那个请求执行完毕之前,前台的提交就会block在写入session那个地方。
在经历长时间的挣扎之后,我最终将自己的部分网站迁移到lightsail。这不是背叛,感谢linode曾经给我的满足感,但是世界上的事,都是用脚投票。当linode不再适合我时,无论他口碑多好,我都依然决定离开。
当初决心每月$10搬到linode时,在香港的VPS上折腾过很久,后来一次服务商被DDOS攻击,停运了一两个星期,才决心搬迁。那是两年前的事了。在上linode时,还在美国和东京机房之间徘徊过。后来选了美国西海岸的机房,那时虽然慢,但是还基本OK。而时间过了两年,这种慢已经无法忍受了。因为家里的网速慢,打开网站基本上靠等和忍,刷新10次才出来一次。于是开始找新的服务商。可是google了很久,linode都占据着第一的位置。在一篇还算靠谱的文章里,我知道了亚马逊出了lightsail,在我的印象里,亚马逊云就是AWS,不仅速度慢,而且计费坑爹,在试用了它免费的EC2之后就弃坑了。但是现在在linode不想用的情况下,最为世界上最大的云服务商之一的亚马逊又进入了我的视野。于是又尝试了一下lightsail。
lightsail是亚马逊推出的有别于EC2的共享虚拟服务器服务,简单的说就是阿里云的ECS。它的收费方式和我目前用的阿里云的ECS一样,按月计费,内存大小、流量都固定了上限。其实这种计费方式最适合个人,完全不用担心每月的账单会不一样。而且就现在的汇率来看,同样的配置,lightsail竟然比阿里云更便宜,测试了性能之后,发现lightsail的服务器打开网站速度也没差多少。现在的问题是,为什么还有那么多人选择阿里云?难道只想做国内市场?中国企业难道不应该具备基本的国际化市场思想吗?
搬迁网站超级快,全部靠linux命令行完成。mysql的备份和导入,scp的远程拷贝,整个搬迁过程总时间加起来不到30分钟,在本地hosts修改测试没问题之后,把dns切换到新的服务器。搬迁结束,现在可以顺畅打开网站了。
很想了解,为何最为第一名被推荐的linode现在变得那么辣鸡。看了下别人的文章,我想可能有两个原因:1.网络线路问题,据称他们的机房已经不支持电信直连。2.共享内存,linode的虚拟技术是内存共享,在它所有套餐里面,你都看不到内存的信息(可能内部有一个每个应用的最高使用限定值),而由于国内对linode的推崇,导致很多人在上面架设应用,人一多,特别是国人一多,资源就消耗的快,网站打开慢成常态。说到这里,本质上,还是服务商在技术上不可能完全掌控单个应用进程资源,所以这种共享内存的策略必定被淘汰。反观亚马逊,把EC2的经验用到lightsail上,我估计lightsail的机器都是EC2淘汰下来的,但是因为技术上的优势,也比其它服务商更稳定。
不过有的文章也有推荐美国的其它服务商,理由是,某些服务商只做美国本土生意,服务器质量都是上乘,但是因为只做本土生意,所以不为国人所知。我觉得也有一定道理。但是如果它只做本土生意,那么在宽带上可能就像阿里云一样,对国外的宽带做了限制,毕竟都要节省成本,所以我们访问那上面的网站估计也慢的不行。
转投lightsail之后,我相当于现在只拥有阿里云和亚马逊的VPS,(虽然还有几个其它的虚拟服务器,)今后希望不要再有大的变得,让我可以不再折腾服务器问题,而是专心写博客。
-
你这不是用的杭州的阿里云吗。。。lightsail不好用吗?求告知。。。。#752 5656 2019-03-27 14:12
-
Lightsail的稳定性比阿里云好,价格便宜,但是速度会慢很多,我博客放在阿里云,其他没备案的域名站放亚马逊#753 回复给#752 否子戈 2019-03-27 14:34
-
搬瓦工49.9的GIA-E简直不要太舒服,美西机房电信联通170ms,移动210ms的延迟,带宽也很充足。三网的链接效果好很多很多,建议值得一试。#904 Francis 2020-02-29 13:59
-
bwg不是主要给ss用么,还敢放网站在上面?#908 回复给#904 否子戈 2020-03-01 00:06
-
还有建站啊,搭梯子好的机子建站也不会太差啊,为啥不敢放网站在上面啊,大家都是独立IP,别人的IP被封了和你也没啥关系不是。你就建个站,国家不会封你IP的,而且搬瓦工上的站长也是非常多。还有lightsail上搭梯子的也是非常的多,之前aws有github学生包给150刀码子时候,lightsail几乎让薅秃了,全是搭梯子的,aws因为家大业大只是受了点影响。#911 回复给#908 Francis 2020-03-01 08:37
-
Lightsail现在体验如何了#1002 123 2021-01-17 19:44
-
不再用了#1004 回复给#1002 否子戈 2021-01-22 17:31
-
你好,我客户在南美,我看了一下,阿里的服务器没有在南美那里有,所以想用lightsail,或者还有其他推荐吗,求告知#1111 回复给#753 mark 2021-11-18 18:45
-
这个不清楚,客户在哪里最好买哪里的服务器#1113 回复给#1111 否子戈 2021-11-18 22:09
-
有没有国外速度快性价比高的vps推荐#1223 莫兰特 2022-09-13 06:38
-
目前在用哪个呢?有推荐吗#1284 回复给#1004 Chaos 2023-04-30 05:39
-
目前就阿里云腾讯云了#1285 回复给#1284 否子戈 2023-05-06 20:13
linux命令行备份和还原mysql数据库
上次tyson给我指出来说首页的几个区块滚动到那个位置的时候就特别卡,我回来自己看,确实这样。于是就开始研究了,最后定位到了 background-attachment: fixed; 觉得是这个东西搞的鬼。于是各种调试,最后发现,其实关键还是对重汇这件事没有深入理解。最后解决的办法是加了 background-repeat: no-repeat; 看上去极其奇妙。按理来说repeat只会渲染可视区域,但是为什么会影响整个页面的渲染呢?实际上这跟UI引擎有很大的关系。每一次界面的操作都需要重绘,无论是否可视区域和非可视区域要重新渲染,都需要进行计算,这个计算涉及到很多问题,特别是页面设计层叠复杂的时候。所以我这里就是因为一个repeat的背景图给搞卡了。
从某种意义上讲,docker是一种项目部署方案,它简化的是项目部署过程,甚至可以和开发过程,选型相对应。问题在于,docker部署的服务是否便于维护,便于及时发现问题和应对处理。由于container本身的运行时内容是会丢失的,所以在正式生产环境中部署docker是否真的有利于项目维护,还是说,仅仅把docker作为代码运行的容器,所有运行时应该被记录的部分全部丢到容器外去保存,如果是这样,是否会遇到对项目代码层面的侵入呢?
在经过一段时间的挣扎之后,我最终放弃了使用docker,而是直接在Ubuntu上使用apache+mysql来跑我的博客。
docker container无法start的问题
把react组件转换为web component没有现成的知名库,所以自己写。
https://zhenyong.github.io/react/docs/webcomponents.html 这里介绍了如何自己写代码来把react转换为web component,但是有一个问题是,这样的web component一旦实例化之后就不能从外部改了。所以,还要想办法可以在修改web component的props的时候,重新去渲染内部的react组件,还好有 https://reactjs.org/blog/2015/10/01/react-render-and-top-level-api.html 这篇文章,告诉我们ReactDOM.render其实可以做到。所以,剩下的,就是如何监听web component的props的改变了。
从 webpack 到全面拥抱 Parcel #1 探索 Parcel
https://juejin.im/post/5a38e100f265da4324809297
这个parcel很吊啊,比脚手架还吊,它用到了文件束,效率比webpack快很多。我一直觉得webpack这种东西,浏览器默认支持import,或者网速达到一定快,或者http2全面支持,那它都没什么用了,真正有用的,是babel这类转译器。连gulp都比webpack强,gulp起码还是一个工程化工具,webpack呢?年轻都parcel啊,你涉世未深,马上就要挂了。
component和virtual dom的互动
没有手撸过virtual dom的人,肯定以为component就是virtual dom了,但实际上不是,virtual dom只是个依赖,生命周期这种东西只是component自己臆想的,跟virtual dom没半毛关系。我自己写hst-virtual-dom之后,大致梳理清楚了生命周期的问题。我们来看下使用hst-virtual-dom的代码:
let vdom = new HSTVirtualDOM({ template, state })
...
vdom.create()
...
vdom.mount('#app')
...
vdom.update(newState)
...
vdom.destroy()
看到来吧,这就是在完全没有component情况下,怎么使用一个virtual dom的过程。它提供来四个方法来进行操作,create是生成vtree,这个时候只有一个和DOMtree对应的js对象,这个对象就是vtree,完全按照DOMtree的结构生成,只不过它是一个js对象。mount动作通过createElement,利用vtree创建来真正的DOM结构,并挂载到传入的selector上。create和mount这两个动作其实可以自动处理,如果实例化的时候传入来selector,就自动调用这两个方法。
update和destroy是在外部调用的,不可以自动处理。update是传入新的state,和老的state merge之后更新界面。它的处理过程是,先通过create创建一个新的vtree,通过diff算法得到新老vtree之间的差异,然后把这些差异patch到真实的DOM节点上。destroy则是把创建的真实DOM,以及它们绑定的事件监听销毁。
一个component干了什么事呢?它其实是对virtual dom的封装,完全暴露给外面的,不是virtual dom的方法,反而是一些围绕virtual dom的辅助方法:
let component = new Component()
->
· this.getDefaultProps()
· this.getInitialState() => state
· this.componentWillMount()
->
· this.render() => template,或者说render本身已经自建了vtree
this.vdom = new HSTVirtualDOM({ template, state })
->
· this.beforeCreate() // vue
this.vdom.create()
· this.created() // vue
->
this.beforeMount() // vue
this.vdom.mount(selector)
this.mounted() // vue
this.componentDidMount()
// 下面进入存在期
this.componentWillReceiveProps()
this.shouldComponentUpdate()
this.componentWillUpdate()
this.render() => newTemplate => this.vdom.template = newTemplate
this.beforeUpdate() // vue
this.vdom.update(newState)
this.componentDidUpdate()
this.updated() // vue
// 下面进入销毁期
this.componentWillUnmount()
this.beforeDestroy() // vue
this.vdom.destroy()
this.destroyed() // vue
// 这个时候对于hst-virtual-dom来说,vdom.vtree还在,如果想要彻底销毁,只需要this.vdom = null
这样你就可以看到,一个component是多么的不起眼,只不过在调用vdom的方法前不断干一些看上去是生命周期,实际上是一些在执行vdom操作前后的普通调用而已的函数。而对于一些初学者而言,拼命的研究生命周期函数,以为即掌握了react的精髓。