json_encode/json_decode与serialize/unserialize性能对比

PHP里面,有时候需要把数组给字符串化,来存储进redis或者其他缓存系统中。能达到这种效果的有两组函数,分别是serialize/unserialize和json_encode/json_decode。其中serialize/unserialize是序列化,json_encode/json_decode是转换成JSON字符串。以下就以上两组函数的优缺点简单作个对比。

前面已经说明了情况,不仅要对变量进行转义,还要将转义后的内容进行存储、读取,经过本人测试发现,在对变量进行转义方面serialize/unserialize相比之下要比json_encode/json_decode高效一些,不过,也没有高得离谱,那么,对于大数据方面,二者就有比较大的区别了。
举个例子,通过下面这段代码,产生一个包含20万个(数组)元素的数组。

$module = [];
for ($i = 0; $i < 200000; $i++) {
    $module[$i] = ['SN' => $S->doSN(), 'str' => $S->randChar(30)];
}
// doSN()的作用是产生一个10位的订单序列号,randChar(30)是产生一个30位的随机字符串

通过前面的代码对$module数组进行赋值,接下来就是对数组进行转义了,实际操作发现,serialize($module)时会报错,“Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 14684160 bytes) in ”,如下图:

使用serialize对大数组进行操作时报Allowed memory size错

大概的意思是内存超过了系统允许的14684160B,当然也可以修改PHP.INI来加大。而json_encode($module)就不存在这个问题,虽然说笔者没有继续测试下去看看json_encode会不会也出现内存溢出的情况,但是,就目前的情况来说,json_encode似乎要更强大一点。
好了,接着测试另一种情况,“容错”,这里的容错指的是当无法判断需要转义/反转义的变量是数组还是字符串的情况,如下:

$str = ‘PHP’; //简单的定义一个字符串变量,
serialize($str)得到的结果是s:3:”PHP”;
json_encode($str)得到的结果是”PHP”;
都没有报错,同样的,我们看下反转义的。
unserialize($str)出错了,Notice: unserialize(): Error at offset 0 of 3 bytes in

使用unserialize对字符串进行操作报错

json_decode($str)没有报错,返回值是NULL,这个好理解,毕竟前面的$str中的内容不是一个有效的JSON格式数据。

到这里,大概的总结以下几点:
1、大数组情况下,JSON组函数要更耐用;
2、对未知类型的变量进行反转义时,JSON组函数容错性要更理想;
3、相比而言,JSON组函数转义后的字符串要更短一些,作为文件存储,可以节约一定的存储空间。

顺便,对serialize和json_encode的效率进行一个简单的对比,

$stime = time();
 for($i=0;$i<200000;$i++){
  serialize(['SN'=>$S->doSN(),'str'=>$S->randChar(30)]);
 }
 echo '<br><br>进行20万次serialize运算花费' . (time()-$stime) . '秒';

 $stime = time();
 for($i=0;$i<200000;$i++){
  json_encode(['SN'=>$S->doSN(),'str'=>$S->randChar(30)]);
 }
 echo '<br><br>进行20万次json_encode运算花费' . (time()-$stime) . '秒';
serialize和json_encode的对比结果

通过上面的对比发现,20万次同样的操作,serialize比json_encode快1秒,这样算下来,单次执行而言二者基本上是不相上下了。

转载自:https://www.cnblogs.com/gyrgyr/p/9989786.html

WordPress更新加速

WordPress的自动更新程序一直以来,都是特别炸裂的存在。由于众所周知的原因,访问速度太慢,以至于不断超时重试,导致非常坏的体验。

现在国内有个公益组织来加速WordPress的更新过程以及各种大陆以外的服务资源。

名字叫WP中国本土化社区

下载wp-china-yes插件后,能够静默加速国际服务资源的访问,很畅快

NSQ使用curl命令增加一个新Topic

使用nsq的web面板增加topic会有奇怪的问题,如图

这个匪夷所思的问题到现在没有什么解决方法,只能通过另外一种方式,使用http协议增加一个topic

curl -X POST "http://172.16.164.248:4151/topic/create?topic=purse.withdraw.result"

给Let’s encrypt颁发的SSL证书开启OCSP stapling

在iPhone等客户端打开Let’s encrypt证书的https网站,会出现等待时间过长的问题,究其原因,大概是,https握手的时候,浏览器会去找证书颁发者问,目前已经吊销的证书列表有哪些。Let’s encrypt的服务器在海外,因为神秘力量作用,“查已吊销”动作非常耗时。

Let’s encrypt证书免费到香的不行,配合上计划任务,只要服务器不欠费情况下,可以自动续期,全程做到无需人工介入,这点比花钱的单域名证书香太多了。

网络上查询一段时间,发现有个技术叫“OCSP stapling”。先解释一下OCSP:

OCSP 是一个在线证书查询接口,它建立一个可实时响应的机制,让浏览器可以实时查询每一张证书的有效性,解决了 CRL 的实时性问题,但是 OCSP 也引入了一个性能问题,某些客户端会在 SSL 握手时去实时查询 OCSP 接口,并在得到结果前会阻塞后续流程,这对性能影响很大,严重影响用户体验。(OCSP 地址也在证书的详细信息中)

再解释一下OCSP Stapling:

OCSP Stapling 就是为了解决 OCSP 性能问题而生的,其原理是:在 SSL 握手时,服务器去证书 CA 查询 OCSP 接口,并将 OCSP 查询结果通过 Certificate Status 消息发送给浏览器,从而让浏览器跳过自己去验证的过程而直接拿到结果,OCSP 响应本身有了签名,无法伪造,所以 OCSP Stapling 既提高了效率也不会影响安全性。另外服务器有更好的网络,能更快地获取到 OCSP 结果,同时也可以将结果缓存起来,极大的提高了性能、效率和用户体验。

接下来直接上在nginx中,虚拟主机配置OCSP Stapling

先在服务器上找到三个证书文件:www.aa.com.key www.aa.com.pem

另外一个文件可能叫ca.cer

在Windows上打开这个文件是长这样的:

Windows打开查看

在mac预览的时候,长这样:

Mac预览

其实就是Let’s Encrypt 给咱们颁发证书的上一级证书的公钥证书

准备好了三个证书后,在server_name 同一层加如下配置:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /usr/local/nginx/conf/ssl/your.domain.com/ca.cer;
resolver 8.8.8.8 8.8.4.4 114.114.114.114 114.114.115.115 valid=60s;
resolver_timeout 2s;

配置完毕后,执行nginx -t检查一下有没有语法错误,再nginx -s reload走一下

找一台iPhone 打开网站看看速度有没有飞快许多

参考链接:
https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol#Browser_support
https://www.feiniaomy.com/post/156.html
https://www.sohu.com/a/204468378_612370
https://www.jianshu.com/p/540124f370e0

Mac shell提示complete:13: command not found: compdef

Compdef is basically a function used by zsh for load the auto-completions. The completion system needs to be activated. If you’re using something like oh-my-zsh then this is already taken care of, otherwise you’ll need to add the following to your ~/.zshrc

实际解决方案,修改~/.zshrc 在开头增加下面的命令即可

autoload -Uz compinit
compinit

Completion functions can be registered manually by using the compdef function directly like this compdef . But compinit need to be autoloaded in context before using compdef.

微信小程序直播功能准入要求

一、类目要求:

  1. 小程序开发者为国内非个人主体开发者;
  2. 小程序开发者为下述类目品类,类目具体信息可参考《微信小程序开放的服务类目》:
    1)电商平台:电商平台
    2)商家自营:百货、食品、初级食用农产品、酒/盐、图书报刊/音像/影视/游戏/动漫、汽车/其他交通
    工具的配件、服装/鞋/箱包、玩具/母婴用品(不含食品)、家电/数码/手机、美妆/洗护、珠宝/饰品/眼镜
    /钟表、运动/户外/乐器、鲜花/园艺/工艺品、家居/家饰/家纺、汽车内饰/外饰、办公/文具、机械/电子
    器件、电话卡销售、预付卡销售、宠物/农资、五金/建材/化工/矿产品;
    3)教育:培训机构、教育信息服务、学历教育(学校)、驾校培训、教育平台、素质教育、婴幼儿教
    育、在线教育、教育装备、出国移民、出国留学、特殊人群教育、在线视频课程;
    4)金融业:证券/期货投资咨询、保险;
    5)出行与交通:航空、地铁、水运、城市交通卡、打车(网约车)、顺风车(拼车)、出租车、路况、
    路桥收费、加油/充电桩、城市共享交通、高速服务、火车、公交、长途客运、停车、代驾、租车;
    6)房地产:房地产、物业管理、房地产经营、装修/建材;
    7)生活服务:丽人、宠物(非医药类)、宠物医院/兽医、环保回收/废品回收、摄影/扩印、婚庆服务、
    搬家公司、百货/超市/便利店、家政、营业性演出票务、生活缴费;
    8)IT科技:硬件与设备、基础电信运营商、电信业务代理商、软件服务提供商、多方通信;
    9)餐饮:餐饮服务场所/餐饮服务管理企业、点餐平台、外卖平台、点评与推荐、菜谱、餐厅排队;
    10)旅游:旅游线路、旅游攻略、旅游退税、酒店服务、公寓/民宿、门票、签证、出境WiFi、景区服
    务;
    11)汽车:养车/修车、汽车资讯、汽车报价/比价、车展服务、汽车经销商/4S店、汽车厂商、汽车预售
    服务;
    12)体育:体育场馆服务、体育赛事、体育培训、在线健身
    二、运营要求:
    1、主体下小程序近半年没有严重违规
    2、小程序近90天存在支付行为
    以上2个运营条件和类目同时满足的前提下,下面3个条件满足其一即可
    3、主体下公众号累计粉丝数大于100
    4、主体下小程序近7日dau大于100
    5、主体在微信生态内近一年广告投放实际消耗金额大于1w
    以上准入要求于 2020 年 02 月 24 日进行公示生效。为营造良好健康的微信生态,腾讯公司有权对《微信
    小程序直播功能准入要求》不时予以调整并公布,请予以关注。

来源:https://res.wx.qq.com/mmbizwxampnodelogicsvr_node/dist/images/access_47d0ce.pdf

Docker快速开启一个MySQL5.7实例

docker run --name mysql57 -v /Users/charles/docker/mysql57/etc:/etc/mysql/conf.d -v /Users/charles/docker/mysql57/data:/var/lib/mysql -p 3357:3306 -e MYSQL_ROOT_PASSWORD=root -d mysql:5.7

第一个-v是绑定mysql的配置文件夹

第二个-v是绑定mysql的数据文件夹

-p 3357:3306 将本机的3357端口绑定到docker实例的3306端口上

-e MYSQL_ROOT_PASSWORD=root 设置MySQL的root账号对应的密码是root

tips: -e是设置docker容器的环境配置