Jump to Navigation

Document

Programming articles and books.

使用NGINX+PHP实现comet服务的nginx配置

正常情况下,nginx为了最大化优化其负载能力,
大量使用缓存技术,比如缓存http响应内容直到缓冲区满再输出,可以最大化提高网络吞吐量。
在nginx连接fastcgi时,也使用相同的缓存技术。
但是,对于comet来说,缓存只能让comet的传输信息延迟更大,甚至可能收不信息。

在现在的nginx版本中,提供了一些参数,可以优化这种应用场景。

一般comet的实现,需要尽量关闭不需要的所有缓存,在无法关闭的时候减小缓冲区大小。
还需要尽量能保持连接跟踪,以便能在有信息时及时响应。

这里说明的是使用php fastcgi实现简单的comet服务端的情况。
具体在nginx中,配置需要注意这些参数,
fastcgi_keep_conn on; # < solution
proxy_buffering off;
gzip off;
fastcgi_buffer_size 100;
fastcgi_buffers 2 100;
fastcgi_busy_buffers_size 100;

Category:

通过http实现简单的远程shell访问代理

当机器处理不同局域网时,如果希望能够互通,一种常用的也比较可靠的方式是使用vpn。
如果是自己搭建私有vpn,则需要一台可控的公网IP服务器。
在没有这些资源的情况下,希望机器的互通比较困难。

在此,给出一种并非完全的互通方式,可以实现单向的远程shell命令执行方式。
这种方式能执行另一局域网中机器的命令,实现简单的类似远程登陆管理的功能。
这就是使用http实现的远程shell访问代理。

实现逻辑为,
在一台有公网访问的http服务器上安装一个像php一类的脚本程序,
该脚本程序分服务端模式与客户端模式。
服务模式下,脚本程序不断轮循命令记录数据库表,查找需要远程执行的下一条命令记录,
并把查找到的命令记录依次输出到访问该脚本的客户端组件。
客户端模式下,脚本程序不断轮循命令响应数据库表,查找需要返回的已经执行完的下一条命令行输出,
并把查找到的命令行输出记录输出到访问该脚本的客户端组件。

fastcgi客户端PHP语言实现

在一个项目中,希望使用php直接与PHP-FPM进程通信,
跳过nginx代理,减少一点中间过程的效率损耗,
同时,更重要的是把PHP-FPM当作一个PHP进程池使用,
不要受到关于nginx的超时、缓冲设置的影响,让不同处理程序之间通信更直接,
特意使用PHP语言编写了一个fastcgi客户端类,实现协议的打包、发送与接收工作。

在经过一段时间的完善之后,确定这种方式非常适用我们的需求场景,
花了一些时间,重新使用C语言编写了一个中间代理服务,
并集成了一个C版本的fastcgi客户端实现,现在已经不再需要这个PHP版本的了。

现张贴在此,给有兴趣的朋友一个示例,给需要的朋友当作参考,
在实现fastcgi类的过程中,总结下来,需要注意的一些点,
对二进制数据包的封装,像处理C语言中的不同长度的整数,字符串在PHP语言中的处理方式。
对C语言中的变长结构体类型的数据结构,在PHP中不太好表达,需要使用比较原始的分支逻辑来实现,
还可以了解网络协议的封闭数据包,解析数据包的基本模式。

Category:

projecttox项目介绍

projecttox旨在实现一个能够替代skype的开源支持视频通话的即时通信IM,
它的目标是简单易用,消息全程加密,保证通信与通话的安全。

在技术上,与skype类似地可大概分为核心部分与界面UI部分。
核心部分实现了主要的网络通信,网络穿透功能,加密安全功能,视频编码功能。
界面部分是基于核心的功能,使用Qt开发,比较容易地实现跨平台功能。

网络部分最开始使用了UDP协议,为了能支持简便的网络穿透功能。
最近,开发工程师正在添加TCP的支持。
可能将来projecttox也会像skype一样,两种网络协议混用。
在不同的功能上使用不同的网络协议,简化代码,提高可靠性与可用性。

目前在网络穿透功能上,核心部分已经实现了非对称防火墙打洞功能,
对称防火墙的打洞正在做理论研究与测试,相信不久之后也能够加入到核心代码。

在分布式网络方面,使用的是类似bittorrent的分布式DHT网络结构,这一点也与skype类似。
但相比skype来说更是一种无中心结点的分布式网络环境。

Category:

gmagick图片处理优化打包

在做网站的图片处理项目时,碰到系统自带的graphicmagick库与效率比较低,
导致服务器负载偶尔达到 300-500的值,这种状态服务基本不用了。
而这个图片处理系统设计的是实时图片处理,前端加varnish缓存的模式。

一旦达到这个范围的负载Load,整个服务基本处于不可用状态,
大概有70-80%的图片处理请求得不到处理,在页面上显示白页了。

这是由于在默认情况下,全部使用CPU的x86指令处理图片,不但耗CPU,而且处理速度还慢。

经过一些理论研究与摸索测试,找到了一个能够大幅优化图片处理效率的方式。

这个优化方式,着重在三点,
1)使用新版本的包,
2)使用CPU的针对图片处理的高级汇编指令
3) 使用openmp并行处理

这里主要使用了libjpeg-turbo这个处理库,这个库尽可能使用了硬件支持的专门处理图片视频的CPU扩展指令,所以效率非常高。

据其官方测试这个库处理图片的效率是系统默认libjpeg的3-5倍。

根据自己的实现项目测试,这个优化效果也非常明显。

关于这个库的详细说明详见其官方网站。

代码服务器与测试机自动部署

  在前一节中,讨论了代码的自动同步几种方式的原理与实现。
  本节中,对开发机环境整体的代码存储与自动部署作个介绍。

Category:

PHP的PDO遇到MySql has gone away的解决方法

在MySQL特定的数据库参数配置的情况下,在一个超时的连接上调用任意的mysql函数,

会导致PHP的PDO扩展报"MySQL has gone away"警告,导致程序无法继续执行。

在使用多种PHP层的解决方案后,依旧无法避免这一问题的出现。

原因在于PDO架构采用了连接对象缓存机制,在使用相同的dsn串连接数据库时,

PDO会从连接池对象中取出有相同dsn串的连接,问题就出在这个地方。

当该连接出现了"MySQL has gone away"之后,PDO并不知道这一情况,

PDO连接对象仍旧在PDO的连接池中。

下次即使在PHP层检测到这一问题,并重试连接,PDO却返回之前报了错的连接。

问题的原因查找到了,接下来就是寻找解决方法。

由于PDO没有提供关闭连接的方法,而是依靠PHP本身的引用计数与垃圾回收机制关闭连接,

在大多数情况下这都没有问题,但这时候这种机制就略显无力了。

经过多次实践修改测试,总结出来以下两种方式,

简单动态web js/css压缩与cdn系统

1、目标,
优化处理过程,不再需要每次有svn提交重复处理所有文件。

自动化程度更高,添加自动处理多文件控件的动态按需合并功能。

采用实时动态js/css压缩,只在有请求时才有压缩,而不是之前的预先把所有文件压缩好。

相对可靠的自动varnish缓存清理,降低从更新代码到生效的时间延迟。

减少svn钩子端代码量和处理时间,SVN服务器减负。

添加处理日志,帮助处理异常查询。

调整svn目录结构,更合理规范。

2、使用技术组件,
nodejs做js/css压缩。

nginx/varnish做服务与缓存。

graphicsmagick做图片压缩优化。

3、服务组件图,

4、压缩处理程序流程图,

Category:

php扩展编写中的整数参数接收

在php中没有C/C++语言中的unsigned long long,unsigned int这些无符号整数类型,

在C/C++程序中一般表示为uint64_t,uint32_t等。

如果在php扩展中需要接收这些无符号数据类型,则需要特殊的处理方式。

对于在PHP支持的范围内的整数,可以直接使用"l"参数获取,

但对于赶出php支持范围的整数,一般需要使用"s"参数获取,

之后在C/C++语言中转换成无符号整数。

也就是,通用的情况下,参数定义为mixed(integer/string)类型的。

在扩展中使用"z"接收参数,接收到之后,使用宏Z_TYPE_P判断参数的实际类型,

对于Z_TYPE_P == IS_LONG的时候,直接转换成无符号类型,

因为这情况情况说明PHP正确传递了整数类型的参数。

如果超出了PHP处理的范围,参数会被转换为浮点数,宏Z_TYPE_P应该为IS_DOUBLE类型。

这样就可以根据扩展中判断出来的类型做不同的接收处理。

当使用字符串类型传递这种参数时,Z_TYPE_P == IS_STRING,转换一次就可以。

Category:

svn到git的迁移与过渡方案

svn与git都是源代码版本控制软件,但它们属于不同的时候。
svn特点在集中式的管理方式,而git更适合于当前分布式管理方式。
当前从svn到git的迁移方案,都是以git为目标,从git的角度提供了相对的迁移策略。
使用的比较多的是,git-svn 和 subgit。

前者出现的早,一直是在git包里自带,用的人多些,在最新的版本里对分支的支持已经非常完善了。
但是它只是一个客户端口的解决方案,能让使用人员用git的方式管理svn代码库,并最终把代码存储在服务器的svn服务器上。
后者属于第三方的解决方案,并且是个商业产品。客户端的使用纯git命令而非git-svn命令,
并在git服务器上提供服务器端的配置支持,让服务器上的git与svn服务器保持同步。

在客户端上则看不到svn的影子,只是把git-svn拿到服务器上使用,并且自动化了。

这两种方案最终都是使用 git或者类似git命令管理代码,与向git的迁移目标一致。

Category:

页面

订阅 RSS - Document


Main menu 2

by Dr. Radut