在MacOS中使用AB测试工具

  一直以来都是用JMeter来做压力测试,GUI界面功能虽然强大,报表齐全,但有时候只是想简单测试下,启动JMeter过于繁琐,于是想到用ab来测试,一条命令搞定。MacOS自带了ab,却因版本问题无法正常使用,需要升级到最新版,本文简单记录下过程。

1,先下载httpd、apr、apr-util、pcre,若有已安装的可以忽略
http://httpd.apache.org/download.cgi
http://apr.apache.org/download.cgi
https://ftp.pcre.org/pub/pcre/

2,由于httpd依赖apr、pcre,所以先安装apr、apr-util、pcre

$ cd apr-1.5.2/
$ ./configure
$ make
$ make test
$ sudo make install

$ cd apr-util-1.5.4/
$ ./configure --with-apr=../apr-1.5.2/
$ make
$ sudo make install

$ cd pcre-8.40/
$ ./configure
$ make
$ sudo make install

$ cd ../httpd-2.4.25/
$ make
$ sudo make install

3,在恢复模式下替换系统ab,关闭MacOS Rootless,开机按住Cmd+R键,进入恢复模式,打开终端执行:

$ csrutil disable
Successfully disabled System Integrity Protection. Please restart the machine for the changes to take effect.

重启
$ reboot

4,备份并替换,以下路径是httpd默认安装位置

$ cd /usr/local/apache2/bin/
$ sudo mv /usr/sbin/ab /usr/sbin/ab.bak
$ sudo cp ab /usr/sbin/

5,重新进入恢复模式,开启Rootless

$ csrutil enable
Successfully enabled System Integrity Protection. Please restart the machine for the changes to take effect.

重启
$ reboot

  到此,工具算是准备好了,但MacOS对文件打开有限制,无法满足ab需求,通过以下命令临时调整:(重启后需重新执行)

$ sysctl kern.maxfiles
kern.maxfiles: 12288

$ sysctl kern.maxfilesperproc
kern.maxfilesperproc: 10240

$ sudo sysctl -w kern.maxfiles=1048600
kern.maxfiles: 12288 -> 1048600

$ sudo sysctl -w kern.maxfilesperproc=1048576
kern.maxfilesperproc: 10240 -> 1048576

$ ulimit -n
256

$ ulimit -n 1048576

$ ulimit -n
1048576

  搞定!

Java并发编程一些笔记

《Java并发编程》

  • 自旋锁与互斥锁

  两者非常类似,只是调度策略的不同。对于独占资源的访问,互斥锁在获得锁之前将一直处于休眠状态,自旋锁则是不断的自我循环来等待锁。对于线程切换没有损失,但消耗CPU,等待过长影响系统性能。

  • 并发包中的信号量与有界阻塞容器

  Semaphore用来控制对某种资源的访问数量,可以用来实现资源池化访问,也可以将任何一种容器变成有界阻塞容器。

  • 线程的关闭

  大多数时候使用原生线程都是等到运行结束而自动关闭,然而有时候也需要提前结束线程,比如用户取消了操作。但Java没有提供任何机制来安全地终止线程。仅提供了中断(Interruption),这是一种协作机制,能够使一个线程终止另一个线程(Thread.stop和suspend存在缺陷,避免使用)。

  解决方案有:非阻塞情况下使用volatile类型的变量来做标记,阻塞框架又存在可中断和不可中断,可中断调用阻塞框架中断方法,例如对阻塞队列的操作。处理好中断异常,保证数据完整性。不可中断的阻塞如IO的操作或者等待获得锁而阻塞,在取消方法中先关闭IO,或者调用Lock类的lockInterruptibly。

  • 线程饥饿死锁

  在线程池中,任务依赖其他任务,那么可能产生死锁。在单线程Executor中,一个任务将另一个任务提交到同一个Executor,并且等待这个被提交任务的结果,会死锁。

  • 线程池大小

  线程池过大,大量的线程将在相对很少的CPU和内存资源上发生竞争,导致更高的内存占用量。线程池过小导致处理器空闲,减低吞吐率。

  • synchronized与ReentrantLock

  两者jvm层语义一致,Java 6及更高版本两者效率差别已经不是很大,Lock具有公平与非公平两种选择,除本身特性之外,非公平锁吞吐率高于公平。其原因是恢复一个被挂起的线程与该线程真正开始运行之间存在较大延时。Lock具有定时锁等待,可中断锁等待,非结构化加锁。

DJI Mavic Pro短暂的体验

  对于一个喜爱摄影的人来说,上帝视角无不充满了诱惑,然而传统摄影方式确实难以触及。这不自从去年大疆创新发布了旗下首款便携无人机Mavic Pro之后就一直长草至今,在得知年前有一批货放出之际,迅速下单购之。然而在收到之后却极其失望,如同大多数国产数码产品,但凡冠以“智能”头衔之后,必然要出现无数的软件问题。(这里可以先卖个关子,有空要盘点下16年购置过的那些“智能(SB)”数码)

  Mavic Pro硬件方面到还不错,外壳衔接,各种接口虽然粗糙了点,但也还耐用。尤其难免会磕磕碰碰的情况下,机身还是很坚固的。三轴云台也是很赞,极其稳定。出现问题的主要还是摄像头,其设定的规格是比精灵系列要低不少,不仅视野少了,传感器尺寸也少了,输出的DNG画质中央暖色调,四周冷色调,JPG则要略好一点。引入的自动对焦也是惨不忍睹,稍微纹理不明显就无法合焦,有趣的是似乎对焦永提示远都是正常的绿色,以至于导出到电脑上才发现不够清晰,整体拍摄水准停留在千元安卓手机水平。App端的拍照和录像设定也是不太方便,录制过程中无法拍照,每次切换手动/自动模式都要重新设定参数,拍夜景简直就是折磨。

  介于这些“缺陷”,限制与定价,个人觉得Mavic Pro的设定应该是一款高端遥控飞行玩具。在DJI并不清晰的产品定位中,Mavic Pro也就入门款,即便下一代,可能不会有很大提升。

  参考:DJI Mavic Pro 官方社区

  照片:花图相册