IT牛人博客聚合

去年9月份时候，我写过一篇《我所使用的知识管理系统》 来介绍我使用的KMS系统。当时经过我层层筛选之后，我选用了Wiz作为我的KMS。

一年多过去了，Wiz在Windows下面工作的非常不错，Wiz团队里陆续推出了iOS / Android / Web版本。我的Wiz收藏的内容也增加到近1000篇。

此时我遇到了KMS再选型的问题，原因很简单：我全线转换到Linux平台， Wiz不符合我的要求了。

我重新整理一下我要求KMS的特性：

跨平台：Linux / Web / iOS / Android / Windows

数据保存格式：移植方便，将图片保存到本地

数据采集方式：支持网络直接拷贝复制

数据索引：支持分类 + t

查看全文: http://www.udpwork.com/item/6587.html

单文件压力测试



    准备用varnish来做图片缓冲服务器，用ab测试了一下单文件读取。发现nginx和varnish都可以把网卡写满（千兆网卡速度》110M/S）。调整了ab测试的并发数，在同样的配置的机器上，发现nginx的在1W并发情况下，依然可以运行；varnish在3600并发测试的时候，直接开始报错。不能不说nginx是神器，varnish不靠谱么？

多文件压力测试

到图片服务器的图片目录执行：find . -name "*.jpg" -print > jpg_url.txt



合计得到38W张图片，用python代码切割成10个文件。

查看全文: http://www.udpwork.com/item/6359.html

重要通知：Log4D的域名由 http://dddspace.com 迁移到 http://log4d.com 。 订阅地址现在改为 http://log4d.com/feed 和 http://feeds.feedburner.com/dddspace 。（FeedBurner的地址未发生变化）

这一次域名迁移的同时，我更换了服务器，由原先的虚拟空间迁移到独立VPS。 现在使用的VPS是 PhotonVPS 。

我选用的套餐类型Xen WARP .25。这是PhotonVPS的配置最低的套餐，硬件如下：

内存： 128MB

SWAP： 256MB

CPU Cores： 2

硬盘空间： 2GB

每月流量： 300GB

查看全文: http://www.udpwork.com/item/6233.html

     1：配置情况



nginx机器配置：

CPU：     E7500  @ 2.93GHz (双核)

内存：4G

varnish机器配置：

CPU：     E3300  @ 2.50GHz (双核)

内存：2G

测试脚本执行机器配置：

CPU：     AMD Phenom(tm) II X4 925 Processor

内存：2G

     2：测试

查看全文: http://www.udpwork.com/item/6067.html

摘要

简单可依赖的架构首先需要有一个简单可依赖的前端WebServer集群。本文通过深入调研当前主流的异步web服务器Lighttpd和Nginx，从业界使用情况、架构原理、扩展开发、功能对比、性能对比等多个方面进行分析。

调研分析

业界相关

从业界使用情况来看，最新Web Server使用情况的数据如下：Nginx的使用率是6.6%，Lighttpd的使用率是0.51%。

从文档来看，nginx中文相关文档越来越多。来自最新的百度搜索数据显示，nginx的网页数量是lighttpd的10倍。目前国内对于Nignx内核深入研究的人越来越多，有淘宝、sina、腾讯等许多大公司的技术人员参与研究，并进行相关的技术交流。对于L

查看全文: http://www.udpwork.com/item/6037.html

以前向大家介绍过Stack Exchange的系统架构和Facebook的系统架构，今天和大家说说Quora的。本文主要参考了Phil Whelan的这篇文章《Quora’s Technology Examined》。关于Quora是个什么网站我就不多说了，国内对他的C2C网站叫“知乎”。呵呵。我们还是来看看Quora的技术吧。

Search-Box

Quora只能搜索问题，主题标签，用户名，和主题标题。没有全文搜索，所以，你无法搜索问题和答案的内容。而搜索中使用前缀搜索方式，比如你输入mi，则Microsoft会马上出来。其搜索还会有一些非常简单的模糊匹配的算法。另外，如果有重复的问题，其中一个问题会自动跳转到另一

查看全文: http://www.udpwork.com/item/5399.html

昨天把blog迁移到VPS上来，今天nginx就不停地502 gateway error，难不成是我害了大家？

现在的PHP是用spawn-fcgi启动的php5-cgi，死的时候完全没有任何的log，这个是没办法查出来的了。

网上搜了一下，大家的结论是PHP这货不够稳定，可能服务这么多个request之后就会死掉。所以有一个workaround就是设置PHP_FCGI_MAX_REQUESTS这个环境变量，让它在一定的request之后重启。

现在已经改好了，得观察一段时间。

这blog再不写就要发霉了，写一篇凑数吧。

© 2011, liuw. All rights reserved.

查看全文: http://www.udpwork.com/item/4354.html

本站使用的是Linode VPS，选择Fremont机房，速度很不错。
不过，自从添了几个网站之后，速度就慢了。我以为内存不够，应付不来，可我查看内存的使用情况并没发现这个问题。后来只好怀疑那个机房到中国的线路不太好使，可很多同一个机房的网站照样速度很好啊。
后来，通过简单的方法解决不了这个问题，我只好伸下懒腰起来看看access.log文件了。一看吓一跳，访问我们服务器最多的既不是机器，也不是我自己，而是服务器上的某个网站。也就是说，该网站上有个程序一直在向本地服务器发出get请求，效果跟windows电脑中毒似的。难怪打开网站会超级慢。知道问题之后就好解决了。
这篇文章的主题是自动化备份网站和添加Nginx网站配置文件，三个脚本

查看全文: http://www.udpwork.com/item/4030.html

很久以前在TW上挖了个坑，说nginx的fastcgi_cache是被大家忽视的一大金矿，今天把这个坑填上，顺祝大家新年快乐。

对于变化不太频繁的数据，大家都比较喜欢存Memcached以减少数据库的读取，但还是会有语言解析运行上的消耗（比如运行PHP，Python等），当然这个时间很短，记得OP上有个同学说P字头的语言，效率都不高，如果能省去，当然最好。（已经用上Squid等的可以忽略本文）。

还有一个问题就是很多时候一个页面由多个数据片断组成，为了提高页面速度，要么分别缓存，要么整体缓存（所谓的Page Cache），其实都比较麻烦，增加和减少数据片断的时，大多需要调整。

最后一个问题，所有的数据都存Memcached是否

查看全文: http://www.udpwork.com/item/3953.html

商品图片，平均200－500K，说大不大，说小不小，但量大且细碎，最早通过页面上传，全部保存在文件里，且不分目录，管理和索引都很慢，几乎无法备份，读取也很慢。

改进方案由大鱼设计，图片是保存在MySQL表里，每10万张图就换一张新表，操作语言是PHP，它解决了图片备份和缓存的问题。

经过一段运行时间后，我对效果并不满意，主要是速度还是有些慢，尤其是第一次加载的过程。这期间又负责主体商品数据迁移到MongoDB，大致研究了一下GridFS，并做了些测试，感觉这个比MySQL要靠谱，且MongoDB还有Sharding和Replica Set支持，帮我解决了分布存储的问题，很是诱人，决定一试。

设计思路和需求整理：

决不允许重复

查看全文: http://www.udpwork.com/item/3947.html

很久以来，Ubuntu 10.04 LTS上官方源里的Nginx都是0.7.65版本，相对较老。要使用新的版本只能自己编译。自己手动编译真是个费力不讨好的活，好不容易刚好能运行了，又发现这功能不全那功能不全的，刚上来的成就感一下子没了。
还好，第三方提供了Ubuntu 10.04 LTS上的Nginx 0.8.53的源，安装后基本上不会出啥问题：

sudo su -
echo "deb http://ppa.launchpad.net/nginx/stable/ubuntu lucid main"
>> /etc/apt/sources.list
apt-key adv --keyserver keyserve

查看全文: http://www.udpwork.com/item/3563.html

Apache启用gzip/deflate或者Nginx启用gzip之后

用wget测试的话需要加上--header="accept-encoding:gzip"

用curl则加上--compressed

浪费了20分钟在这选项上,milk



关于gzip和deflate有两篇文章(1和2), 作者应该是一个人，明显是从1毛跳去了性浪...

查看全文: http://www.udpwork.com/item/4798.html

Poppen.de是德国的一家婚姻中介网站，对于该网站的统计数字有：1）2.000.000的用户数，2）20.000的并发用户数，3）每天产生300.000的私信，4）250.000的日登录用户数。这样的网站也就是个中型规模的网站，下面看看这个网站在技术应用及经验方面带来的东西。

原文链接：http://highscalability.com/blog/2010/4/12/poppende-architecture.html

Nginx

Poppen.de使用nginx作为web server，包括静态请求和动态请求。特别的，Poppen.de通过nginx来直接从memcache中获取缓存的动态页面内容而不需要经过PHP，一

查看全文: http://www.udpwork.com/item/1648.html

作者：Fenng 发布在 dbanotes.net.

拿到这本 《实战 Nginx》 有几天了，休假期间将感兴趣的几章阅读完毕。作者张宴是国内 Nginx 最早的技术传播者之一，产生的影响也最大，他的一系列 Nginx 实战的文章相信让很多 Nginx 用户受益良多。

尽管之前已经在他的网络文章或者 PPT 里看到过这本书里包含的一些内容，我还是要说一下第六章中的架构图是这本书中非常有参考价值的内容(至少对我如此)，作为网站维护者，即使不用 Nginx，这几张图也非常值得分析一下。对于从 Apache 迁移到 Nginx 的用户，第七章关于 Rewrite 规则的讲解则不可错过。

这本书的最大缺点或者说不够严谨的地方，我觉得

查看全文: http://www.udpwork.com/item/894.html

Nginx本身可以通过

kill -HUP `cat /usr/local/nginx/logs/nginx.pid`

进行平滑重启的，可以通过ps进程查看一下。效果还是挺不错的。

这里介绍的是另外一种方式service，适合RHEL/CentOS系列。

1. kill nginx进程

kill `cat /usr/local/nginx/logs/nginx.pid`

2. 建立 /etc/init.d/nginx 文件

#!/bin/sh
#
# nginx - this script starts and stops the nginx daemin
#
# chkconfig: - 85 15
# desc

查看全文: http://www.udpwork.com/item/1063.html

在邮件组里看到有人问能不能把多个hiphop-php编译后的程序跑在同一个端口上，想想也是合理的要求。如果一个服务器上跑了多个站点，那肯定都得用80端口，当大家共同租用服务器的时候，这个需求更为强烈。当时我所想到的解决办法是在前面搭个nginx之类的做代理，实际编译后的程序跑在别的端口，然后没过几天就看到了这份wiki – Using nginx as front server to HipHop。

简单的nginx配置示例

/etc/nginx/conf.d/ooso.conf:

server {
listen *:80;
server_name *.ooso.net ooso.n

查看全文: http://www.udpwork.com/item/1709.html