android jni的坑
传统的jni方式是这个步骤
1.在java文件中定义native函数
2.使用javah 生成对应C函数定义并实现
3.编写Android.mk把C源码用ndk编译成动态库
4.在java中调入编译好的动态库
传统的jni方式是这个步骤
1.在java文件中定义native函数
2.使用javah 生成对应C函数定义并实现
3.编写Android.mk把C源码用ndk编译成动态库
4.在java中调入编译好的动态库
公司需要,需要对一些加解密模块做调研。
把一些参考资料贴出来
这个是内核中摘出的算法,不知道为什么特别慢,DES加解密一起只能到7M/S的数据处理
twemproxy的性能应该很好,毕竟是twitter在使用的,稳定性应该很高。
然而测试组的同学对其二倍扩容以后,基本没提升QPS,甚至QPS还降低了
我和我的小伙伴们一直以为是客户端或者服务端代码的问题,各种抓包,LOG分析,查不出原因。写了C,JAVA等多个客户端版本。
后面发现原来是测试组的布线坑爹了。
关于之前测试环境redis集群极限qps提升不上去的问题,认定是由于之前4台测试环境部署的宿主机,走的交换机,交换机网络达到瓶颈导致的。
FastDFS组合nginx的http_image_filter_module建立的图片服务器,实现动态缩略图
用fastdfs存储图片,然后用nginx的图片处理模块http_image_filter_module处理图片,根据输入的地址中的图片大小动态生成缩略图
原图http://192.168.8.127:801/group1/ … WAAL8RoEHXq8410.jpg
动态生成的缩略图地址
http://192.168.8.127:801/group1/ … HXq8410,222x222.jpg
我的学习历程是先接触的nosql而后接触的mysql,所以这里记下的只是初学的一些东西,没什么见地。
查看有没有安装过:
1 | yum list installed mysql* |
mysqldump -uUSER−pPASSWD -h127.0.0.1 -P3306 --routines --default-character-set=utf8 --databases mysql > db.sql
fastdfs的后台监控程序里有一段关于字符串解析的操作,使用snprintf进行字符串连接后无论如何解析的字串都是错误的
snprintf(buf,1024,“%s%s”,buf);
问题出在这一句,因为sprintf系列比起strcat方便很多而且更加灵活,所以我一直使用sprintf来进行字符串的连接操作,没想到用snprintf就跪了。
后来用sprintf就没问题了
看了一下man
本来觉得linux下性能分析只是一系列工具,也没什么难点。后来发现几个工具中间,各有优缺点。
稍微介绍下吧。
gprof:
这个工具比较轻量级,能看到所有的函数调用链,和函数运行时间,原生是只支持单线程监控的,通过文中的方法,可以支持多线程