Tag Archives: lighty

用 SYSOP 风格的方法研究 spawn-fcgi

Posted on 2010年 10月28日 by JulyClyde

不怕大家笑话，以前我一直不明白为啥会有 spawn-fcgi 这个东西。因为以前都是用 PHP 啊，PHP 本身就是可以并发处理多个请求的 fastcgi server 啊，要 spawn-fcgi 干啥用呢？更有意思的是有人用 spawn-fcgi 启动多个 php-cgi ，然后这个 php-cgi 再启动多个子进程，不知道有什么好处。 前几天，我读了一下代码，还是没太明白这个东西存在的必要性，于是就用我们 SYSOP 的方法研究了一下 spawn-fcgi： fakefcgi.sh脚本文件 #!/bin/sh ls -l /proc/self/fd/ >/var/log/$$.txt sleep 600s 执行 spawn-fcgi -p 3333 -F 5 — ./fakefcgi.sh 得到结果 spawn-fcgi: child … Continue reading →

Posted in 默认分类 | Tagged , , | 1 Comment

web服务器和web应用的结合方式是个很麻烦的事啊

Posted on 2009年 07月14日 by JulyClyde

今天在看python的资料，发现没看关于python作为web应用部署的方法。后来才发现，原来python的web应用功能大都是由开发框架提供的，用这些开发框架开发的程序可以以http、fastcgi、uwsgi等协议对外提供服务，但都是与该应用程序紧密相关的；和Apache的mod_php类似的mod_python文档上声称尚未支持Apache 2.0；没有找到和php-fpm类似的语言级别的fastcgi服务器。 web应用程序的部署是个挺麻烦的事。 普通web服务器+cgi： web服务器需要把URL映射到文件系统，并执行cgi 普通web服务器+内置语言处理模块： （像apache+mod_php这样的） web服务器需要把URL映射到模块（并判断文件是否存在，可选步骤），并由该模块处理） 普通web服务器+分离式web应用： （web服务器+php等语言级别的fastcgi、 web服务器+应用级别的fastcgi、uwsgi等种种协议） web服务器需要把URL映射到后端服务，并由该后端服务处理。而该后端服务还得再把URL映射Class、Function再运行，需要两次regexp匹配。这样就把应用的开发和部署紧密耦合了，增加了部署的麻烦啊 20130103更新：随着我对python的学习，我越来越认同python派的WSGI server+框架+应用程序的架构，也认同WSGI server直接对外提供高性能服务的理念。参考Shell Xu的博文

Posted in 默认分类 | Tagged , , , | 3 Comments

无责任猜测某视频分享网站的系统架构

Posted on 2009年 06月28日 by JulyClyde

今天听了 lighty modcache 的讲座，晚上和 suchasplus 谈论这个讲座时，注意到以下细节，于是我开始自说自话的猜测他们的系统架构。 modcache 本身不会自动删除磁盘缓存文件，需要 tmpwatch 程序配合或者被动 PURGE 缓存目标的老化只根据 refresh-pattern 决定，没有多余的信息和缓存目标保存在一起，缓存目录中的文件格式很简单 从这些细节中，我猜测该视频分享网站有个主控端，负责通过发请求或者直接推送文件到缓存目录的方法推送文件到前端缓存服务器 ，而这些傻得可爱的前端缓存不会主动删除缓存文件。这样，主控端对“某台前端服务器拥有哪些内容”了如指掌，配合性能测量机制，可以动态的向客户端发送指向不同前端服务器的播放列表，从而达到均衡各服务器、各网段负载的目的。在网络流量低潮，还可以偷偷的向前端发送热门内容文件，或者遥控前端服务器删除过期内容等。 这样看来，其实前端的服务器并不能算做传统意义上的反向代理缓存服务器，而是 web 服务器，但为什么用缓存代理的方式来实现这个功能呢？我认为主要是可以通过向缓存代理发送一个 GET 请求的方式，轻松的向该前端服务器推送内容；缓存目录中的文件没有特殊格式和多余信息，恐怕也是出于这个考虑。 声明：本文为无责任猜测。如果与实际情况相同，并不表明我窃取了该企业的机密；如果不同，则说明我已经独立发明了一种较通用的大型网站系统架构。

Posted in 默认分类 | Tagged , , | 4 Comments