(nginx源码系列一)--nginx源代码初步学习
nginx真是博大精深,最近写fastdfs的动态缩略图模块,刚好能有时间研究下,真是满心欢喜。
学习主要是靠两本书,其他的稍微搜搜也就能解惑了。
《Nginx模块开发与架构解析》这个我看的电子PDF
《Nginx开发从入门到精通》这个有网页版本的,挺好的:
nginx真是博大精深,最近写fastdfs的动态缩略图模块,刚好能有时间研究下,真是满心欢喜。
学习主要是靠两本书,其他的稍微搜搜也就能解惑了。
《Nginx模块开发与架构解析》这个我看的电子PDF
《Nginx开发从入门到精通》这个有网页版本的,挺好的:
传统的jni方式是这个步骤
1.在java文件中定义native函数
2.使用javah 生成对应C函数定义并实现
3.编写Android.mk把C源码用ndk编译成动态库
4.在java中调入编译好的动态库
公司需要,需要对一些加解密模块做调研。
把一些参考资料贴出来
这个是内核中摘出的算法,不知道为什么特别慢,DES加解密一起只能到7M/S的数据处理
time out这个问题是我刚实习的时候所有的业务组就都存在并且反应的。但是最近这段时间才定位了错误,固然这中间弄了小文件系统等等,但主要还是本人能力不太够导致的。
由于定位的时间拖得太长,导致大家对twemproxy-redis都有一种不稳定,不放心的看法,然而今天要为它正名:
1 首先分析测试环境。
在测试组和同步业务的帮助下,我们拉来了device的数据进行测试(使用了ntpdate对所有机器进行了时间同步)
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 -u\(USER -p\)PASSWD -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:
这个工具比较轻量级,能看到所有的函数调用链,和函数运行时间,原生是只支持单线程监控的,通过文中的方法,可以支持多线程