记得在PHP开发过程中，经常会用到实例级别或者线程级别的变量缓存，带来的性能提升是巨大的。但对于tornado来说，由于每次访问都会实例化tornado.web.RequestHandler，不能满足要求，只能考虑在主线程上进行变量缓存。一旦成功将有可能直接抛弃redis。

种种原因，不公开最终实现的代码，这里只用一个页面计数器来模拟。通过一个页面http://localhost/get获得主页http://localhost/的Page View。

import tornado.httpserver
import tornado.ioloop
import tornado.options
import tornado.httpclient
import tornado.web
import sys, os
from tornado.options import define, options

#####
class PageCounter(object):
    count = 0
####

#PageCounter = 0 这种采用全局变量的方法被证实无法实现。

class MainPage(tornado.web.RequestHandler):

    def get(self):
        PageCounter.count += 1
        self.finish('Hello World!')

class GetPageView(tornado.web.RequestHandler):
    def get(self):
        sPageView = str(PageCounter.count)
        self.write(sPageView)

def main(port):
    if os.fork() != 0:
        exit()
    define("port", default=port, help="run on the given port", type=int)
    application = tornado.web.Application([
        ("/", MainPage),
        ("/get", GetPageView),
    ])
    http_server = tornado.httpserver.HTTPServer(application)
    http_server.listen(options.port)
    tornado.ioloop.IOLoop.instance().start()

if __name__ == "__main__":

    if len (sys.argv) > 1:
        port = sys.argv[1]
    else:
        port = 80
    main(port)

这里要说的是object基类的PageCounter方法，可以定义一种数据结构以及对应的操作方法。当然这段代码只是Demo，写得不规范。由于PageCount是全局的，跟随进程实例化，所以可以很灵活在各个实例之间传递数据。

类似这种方法，我们的项目性能提升了至少5倍。但这样实现的结果也非常明显，首先不能持久化，一旦进程终止，数据就被清空；其次是进程隔离，这种方法共享数据只能工作在tornado的一个进程中，对于习惯于多进程并行的Tornado部署会有问题，我们最终的做法是做唯一哈希；最后要注意的是内存释放的问题，数据保存在内存中，如果是大量的数据通过dict/list做映射的话需要进行定期清理，当然通过这种方法可以变态的做一个基于HTTP协议的Key-value数据库。

# ab -n10000 -c1000 http://localhost/
This is ApacheBench, Version 2.3 < $Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests

Server Software: TornadoServer/2.1.1
Server Hostname: localhost
Server Port: 80

Document Path: /
Document Length: 12 bytes

Concurrency Level: 1000
Time taken for tests: 8.921 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 1700000 bytes
HTML transferred: 120000 bytes
Requests per second: 1120.89 [#/sec] (mean)
Time per request: 892.148 [ms] (mean)
Time per request: 0.892 [ms] (mean, across all concurrent requests)
Transfer rate: 186.09 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 230 792.8 0 3012
Processing: 14 134 73.9 114 1878
Waiting: 14 134 73.9 114 1878
Total: 86 364 815.1 114 3818

Percentage of the requests served within a certain time (ms)
50% 114
66% 115
75% 121
80% 141
90% 378
95% 3135
98% 3176
99% 3223
100% 3818 (longest request)

之前曾经通过nginx的memcache扩展，配合TokyoTyrant Server（每次都觉得很别嘴）这个即支持memcache协议，又可以持久化的Key-Value实现过琐碎文件的管理，但限于Memcache无法逾越的1M鸿沟，只能保存些小文件。

这些天看到一个Nginx第三方插件 HttpRedis, 本身仅仅只是计划用它来做一些短域名跳转之类的应用，忽然觉得Redis没有内容主体的限制，而且性能优良，完全可以用作琐碎文件的下载。

首先下载nginx——不知不觉nginx已经有了正式的1.0以上的版本了！

wget http://www.nginx.org/download/nginx-1.0.10.tar.gz

下载 http_redis:

wget http://people.freebsd.org/~osa/ngx_http_redis-0.3.5.tar.gz

开始编译，没什么复杂的：

tar vzxf nginx-1.0.10.tar.gz
tar vzxf  ngx_http_redis-0.3.5.tar.gz

cd nginx-1.0.10
./configure –user=www –group=www –prefix=/app/nginx  –add-module=../ngx_http_redis-0.3.5

make -j4 && make install //部分CPU无法通过编译，还是乖乖的make  && make install

修改nginx的配置文件：

在http{}之中加入：

server {

    listen       80;
    server_name  www.test.com;

    location / {
      set $redis_key CACHE_$request_uri;
      redis_pass     localhost:6379;

      default_type   text/html;
    }
}

安装redis，还是老一套：

apt-get install redis-serve
/etc/init.d/redis-server start

比如你现在需要通过http://www.test.com/a.html访问一个页面，则可以直接通过下面的方法在redis中塞入一个值，依次类推：

redis-cli
redis > set CACHE_a.html “Hello World!”
OK

redis > set CACHE_/b/a.html “Hello World!”
OK

调试无误后就可以使用程序端直接向redis中写入数据了。

当然，也可以通过设置不同的“default_type”存放图片或者其他类型的文件。 由于此扩展支持redis连接池，而且redis本身也支持master-slaver数据同步，完全可以实现redis端的负载均衡（考虑到redis的性能，我觉得意义不大，除非为了热备份）。需要注意的是Redis是内存数据库，尽管它有定时将数据回写磁盘的机制，但如果不启用vm的话，内存是一个硬性的限制。

由于项目本身是PHP的初次看到这个项目，首先想到的是Apache + mod_php的方式，配合php的ob_start()方式直接调用，就如同我之前的一篇东西所说的那样。可问题不这么简单：

1. 系统是nginx + php-fpm方式，php-fpm“hold不住”过多的Http请求，而nginx需要调整响应时间。
2. 用户数量很多，Apache的消耗很大。本身功能点很小，实现成本不合算。

说到并发，Apache采用的方式是大量的fork进程，通过“人多力量大”的方式应对多个请求，这样的基于进程（线程）模型的并发，一旦调用sleep，进程只是休眠而已，仍然占用着内存，仍然需要进程调度，资源始终得不到释放，资源自然无法得到控制。这些年nginx的流行大多都是因为nginx采用的epoll方式有效的解决这个问题——直接挂掉进程，然后再指定时间内重新启用。这就是传说中的“非阻塞”(asynchronous IO  AIO)。

多并发、轻量级应用，我首先想到的是Python，加上“非阻塞”关键字，得到的结果就是Tornado。

tornado原本是FriendFeed引擎的开源版本，本身就是为解决“C10K”问题而生的。

稍微研究了一下，coding也很简便：

#!/usr/bin/env python
#By Litrin J
#http://www.litrin.net/
import tornado.httpserver
import tornado.ioloop
import tornado.options
import tornado.web
import time, redis, hashlib,random
from tornado.options import define, options

define("port", default=8888, help="run on the given port", type=int)

class LongPolling(tornado.web.RequestHandler):

    minWaitTime = 15
    maxWaitTime = 900

    RedisHost   = "172.18.194.98"
    RedisPrefix = "Q/MSG%s"

    SignSalt    = "salt"

    StopCode    = "{'stop':1}"

    @tornado.web.asynchronous
    def get(self):
        sUid        = self.get_argument("uid", None)
        sSign       = self.get_argument("sign", None)
        sJsonCall   = self.get_argument("jsonCallback", None)

        if (sUid is None or sSign is None
                or self.checkSign(sUid, sSign) == False):
            raise tornado.web.HTTPError(404)
            self.clear()

        else:
            self.doLongPolling(callback=self.onWaitting)

    def checkSign(self, sUid, sSign):
        return True

    def doLongPolling(self, callback):
        #Check if the client close the connection
        if self.request.connection.stream.closed():
            self.clear()

        sKey        =   self.RedisPrefix % self.uid
        res         =   redis.Redis(self.RedisHost)
        sMessage    =   res.rpop(sKey)
        del res #close the redis at 1st time

        callback(sMessage)

    def onWaitting(self, sMessage):
        if (sMessage is not None):
            self.onRespones(sMessage)
        else:
            iNextPollingTime = time.time() + self.minWaitTime
            if self.minWaitTime < self.maxWaitTime:
                self.minWaitTime *= 2
                #Can't useing time.sleep for no-bloking mode
                tornado.ioloop.IOLoop.instance().add_timeout(
                iNextPollingTime ,
                lambda: self.doLongPolling(callback=self.onWaitting)
            )
            else:
                self.onRespones(self.StopCode)

    def onRespones(self, sMessage):
        sJsonCall   = self.get_argument("jsonCallback", None)
        if sJsonCall is not None:
            sMessage= sJsonCall + "( " + sMessage.decode('utf-8') + ")"

        self.write(sMessage)
        self.finish()

def main():
    tornado.options.parse_command_line()
    application = tornado.web.Application([
        (r"/", LongPolling),
    ])
    http_server = tornado.httpserver.HTTPServer(application)
    http_server.listen(options.port)
    tornado.ioloop.IOLoop.instance().start()

if __name__ == "__main__":
    main()

一旦建立http连接，系统会每隔一段时间去轮询用户的队列中是否有数据，有数据时才向客户端发送请求，否则就是“长时间小菊花”状态。很简单，仅仅用了不到100行代码的样子。当然，为了安全因素和节省资源，代码里添加了很多限制性的操作，否则可能会更简洁高效。

需要注意的是，tornado的理念就是建立在“非阻塞”基础上的，你当然可以选择time.sleep(n)，但传统上的time.sleep(n)方式的休眠会导致IO阻塞，故只能采用tornado.ioloop.IOLoop.instance().add_timeout 的方法回调来回调去，将下次启动的时间转给系统。话说回来，这是我第一次在Java或JS以外使用回调函数……

初步测试了一下，借助Redis本身就很强的并发能力在台式机上可以每秒钟完成4K次请求以上，并可以保持同时4K以上的访问不掉线，此时的CPU load仍然保持在1以下，单是测试的结果就足以让Apache+Php组合汗颜。

部署的时候采用了单IP多端口方式，服务器有4个核心，决定开4个端口对应，分别是8885~8888，修改

define("port", default=8888, help="run on the given port", type=int)

即可

前端nginx用负责负载分发：

upstream backend {
        server 127.0.0.1:8888;
        server 127.0.0.1:8887;
        server 127.0.0.1:8886;
        server 127.0.0.1:8885;
}
 server{
        listen  80;
        server_name message.test.com;
        keepalive_timeout 65;    #
        proxy_read_timeout 2000; #
        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;

    location / {
        proxy_pass_header Server;
        proxy_set_header Host $http_host;
        proxy_redirect off;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Scheme $scheme;

        proxy_pass  http://backend;
        }
}

需要注意的是，这样的httpSocket方式很可能被内核认为是SYN攻击，而且对于大量的keep alive而言，很可能超过核心限制，还要修改sysctl参数。

#系统最大打开文件数
fs.file-max = 201510

#TCP连接的最长时间
net.ipv4.tcp_keepalive_time = 1800
#出现问题的尝试次数
net.ipv4.tcp_keepalive_probes = 15
#检查是否连接的等待时间
net.ipv4.tcp_keepalive_intvl = 60
#不进行SYN cookies防御
net.ipv4.tcp_syncookies = 0

“开源小站”最初是基于drupal构建，基础数据库是postgresql。后来由于drupal的性能问题以及框死了的postgresql，只能整体迁移到了wordpress+mysql。当然迁移好之后，考虑到drupal和wordpress的链接地址的不同，修改了wordpress的部分代码，让之前的外链不至于失效。后来索性就通过apache的mod_rewrite模块添加了301跳转，wordpress的版本也可以随着“持续演进”了。

由于wordpress或者这一类的CMS系统本身不是一个性能优化的产品，后来一段时间搬迁过一次，平台是vps的虚拟机。性能问题很突出，首页打开竟然需要2.7秒以上，加上传输耗时，超出了3秒的范围，严重影响用户体验。于是不得不在wordpress的代码上进行修改。页面全部缓存到了memcache。响应时间减少到1.5秒以下，基本可以满足大部分需求。但这样就无法跟随wordpress持续演进了。wp的版本只能定死在了某个版本号上。考虑到安全因素，我只能说，这是3.1之前的“某个版本”。

关于硬件环境，最初的drupal版本是一台相对很“牛”的机器，双核志强*2 + 4G RAM+ RAID5。所以当初提供了很多开源系统镜像下载。系统的瓶颈出现在网络带宽上，可谓“衣食无忧”。

之后的变故，加上域名备案的因素，使得网站一度只能跑在一台win2003的virtual server上，内存只有64M，从一个极端到了另一个极端。之后很长一段时间，开源小站始终运行在虚拟机或者vps之上。当然，由此带来的流量下滑不是一点点，但访客停留时间大大增加。也算抹平了。

后来，设法弄到了一点资源，与别人合用了一台主机，4核Xeon+4GRAM + RAID1，磁盘总是不够用，甚至为此都不保存访问日志。

后来，曾经狂热的支持了一把atom，于是自己用atom的平台搭建了一台服务器，1u高度标准机箱，atom-230,1.6G +2GRAM+160G的笔记本硬盘，操作系统选择了Ubuntu的804 Server，竟然跑得很流畅，这就是现在开源小站的主机。当然，也感谢某位朋友，免费提供了他们所代理的某款网络安全产品，用以作为我们小站的前端防火墙。在前端防火墙之后，通过端口映射的方式完成了网站80端口的指向。负担一部分iptable的任务，同时也作为SSH和远程重起主机的跳板。

之后，加入了xml-rpc服务，同时将文章推送到几个免费博客和litrinjiang.appspot.com，尽管格式全乱，但至少也算是备份吧。

• FreeBSD + Apache + PHP + Mysql (恶搞版)
• FreeBSD + Apache + PHP + Mysql + Oracle
• Ubuntu + Apache + PHP + Mysql ，比较简单，正常server版安装结束的最后一步可以选择安装LAMP
• Ubuntu + nginx + php
• Ubuntu + php + Oracle

Memcache

说起Memcache，这年头稍微大点的网站几乎是必不可少的。内存Key-value一对一数据库，但数据易失。新浪的团队也有个项目是memcachedb，就是以速度为代价，部分数据回写硬盘。但似乎不是memcache的本意，个人觉得不如直接写sql，仁者见仁吧。

• For Ubuntu
  apt-get install memcached php5-memcache
  /etc/init.d/memcached start
• For FreeBSD
  cd /usr/ports/databases/memcached
  make install clean
  cd /usr/ports/databases/pecl-memcache
  make install clean
  echo”memcached_enable=YES” >> /etc/rc.conf
  /usr/local/etc/rc.d/memcached start

Redis

也是一个Key-value数据库，比起Memcache速度慢一点，但会回写硬盘，数据不丢失。处理Feed之类SQL吃上劲的应用必备。

• For Ubuntu //11.04可行，8.04不行，官方似乎从904以后才加入的。之前的版本不妨用debian包
  apt-get install redis-server php-redis //同样的debian包下载
  /etc/init.d/redis-server start
• For Freebsd
  cd /usr/ports/databases/redis
  make install clean
  echo ‘redis_enable=”YES”‘ >> /etc/rc.conf
  /usr/local/etc/rc.d/redis restart
  cd /usr/ports/databases/php5-redis
  make install clean //敲的条件反射了

说起redis的PHP支持类，由于redis是明文的传输，所以很多人会选择redisend这类基于socket连接方式的php类——说白了就是模拟telnet 6379。根据实际测试的结果，C扩展至少有40%以上的提升，而且内存更少，加包和拆包的过程更迅速。更何况redisend的前一个版本一堆问题，后一个版本又是php5.3 only的天上一脚，地上一脚的维护也是麻烦。不是万不得已还是少用为妙。

PHP-FPM

这个是给Nginx做fastcgi扩展的，相比php-cgi, spawn-cgi不但性能上有提升，配置上也灵活的多，但FreeBSD不支持，Ubuntu也不官方推荐。这里使用了ubuntu的非官方库。

echo “deb http://php53.dotdeb.org stable all” >> /etc/apt/sources.list
apt-get update; apt-get upgrade
apt-get install php5-fpm

会直接覆盖之前官方支持的PHP包，请慎重考虑。

/etc/init.d/php5-fpm start

PHP-GD

最常见的缺失，但很容易。

• For Ubuntu
  apt-get install php5-gd
• For FreeBSD
  cd /usr/ports/graphics/php5-gd
  make install clean

Minify

Minify是一个基于PHP5的CSS/JS优化包，其实这不属于Php的扩展。

1. http://code.google.com/p/minify/ 下载最新的minify，解压后，将min目录拷贝至网站根目录下。
2. 确认是否开启了apache 的mod_rewrite，Ubuntu默认不开启，需要a2enmod,选择rewrite后,/etc/init.d/apache2 restart 重起apache
3. 网站根目录下编辑.htaccess内容如下：

   RewriteEngine On
           RewriteBase /
            RewriteRule ^(.*\.(css|js))\S?$ min/index.php?f=$1 [L]

4. 如果系统已经安装了memcache包，不妨用MC替代文件方式存储优化后的信息，编辑min/config.php，末尾添加

   require 'lib/Minify/Cache/Memcache.php';
   $memcache = new Memcache;
   $memcache->connect('localhost', 11211); //根据本地配置调整
   $min_cachePath = new Minify_Cache_Memcache($memcache);

TokyoTyrant (ttServer)

TykyoTyrant想必web game, social game的公司用的很多，大概是由于某家企鹅公司的框架所限吧。这东西就是一个“支持lua扩展并可持续化”的key-value。个人觉得完全可以通过memcache + redis两者取代。

• for Ubuntu (natty ok, hardy not support)
  apt-get install tokyotyrant
  /etc/init.d/tokyotyrant 52~53行稍作修改：
  52 #SERVERHOST=”$RUNDIR/$NAME.sock”
  53 SERVERPORT=1978
  即可通过/etc/init.d/tokyotyrant start命令启动1978端口的监听

• for Freebsd
  cd /usr/ports/databases/tokyotyrant/
  make install clean

同样的，前些天最让奥巴马同志欣慰的莫过于总算搞掉了本·拉登这块心病。美国人一窝蜂的愣是挤爆了CNN的手机网站。据说全美所有新闻网站的平均响应时间瞬间提升了6倍以上——可以说，都是处在了宕机的边缘。拉登果然是“恐怖之王”连他的死讯都能媲美一次完美的DDOS攻击。

两个新闻都与宕机有关，而且都与移动互联和宕机有关。

不管愿不愿意接受，整个互联网已经逐步向移动互联网过渡。不管是4SQ、微博这样的应用型访问还是CNN这样的资讯型访问，与手机的结合无疑于绑定了所有人的垃圾时间，带来可观的流量和利润——随时，随地，随性访问互联网真的很方便。然而在此乐观的背后是恐怖的瞬间爆发式访问。正如之前twitter不止一次的宕机事故，每一次都少不了热门事件的推手。

相信这些知名网站的架构设计绝对不是我能想象的完善，硬件投入也绝非“抠门”。唯一的可能就是瞬间提升的访问量导致服务器处理速度和集群带宽容量的饱和。于是加上现在无处不在的“云计算”，像4SQ这样的“成长型企业”很自然的选择了亚马逊以及其他的云服务。选择的背后无疑是将自己的全副家当交给了云，云也会有处理速度和带宽的限制，同样也有可能出现爆发式访问，而且很自然的会出现波及效应，导致云中所有的用户离线。当然，亚马逊对此次事故的评价为“前所未见的”，可以预见的是，一切才刚刚开始！

在此之前我曾经认为移动互联短期内出现的瓶颈是在手机和基站之间的通讯，例如在人多拥挤的地方（事实上是“机多拥挤”）手机信号往往不好。以前年三十大家挤在一起发短信拜年，往往隔几个小时才能收到，对于数据的访问也应如此。后来我看到一篇华为的成功案例，觉得随着时间的推移，迟早这个瓶颈会消失。流量的压力迟早一股脑的扔给了服务端。

对于移动互联的架构师所要考虑的问题就是如何快速的处理“瞬间爆发”，没有任何侥幸心理。这似乎也只有更大的访问冗余可以解决。可以预见的是，现在加上了移动互联的概念后web2.0已经接近成熟，但目前的技术瓶颈已经出现。1.0时代的瓶颈来自带宽，2.0的瓶颈将会是在冗余和弹性上。而对于很多心存幻想的朋友，4SQ的宕机恰恰说明了另一点“云靠不住！”

SELECT pg.package_id, pg.goods_id, pg.goods_number,
        pg.admin_id, g.goods_sn, g.goods_name, g.market_price, g.goods_thumb, g.is_real,
        IFNULL(mp.user_price, g.shop_price * '1') AS rank_price
FROM `ecs_`.`ecs_package_goods` AS pg
        LEFT JOIN `ecs_venusveil`.`ecs_goods` AS g ON g.goods_id = pg.goods_id
        LEFT JOIN `ecs_venusveil`.`ecs_member_price` AS mp ON mp.goods_id = g.goods_id AND mp.user_rank = '0'
WHERE pg.package_id = -1
union all
        select 1,2,3,4,5,6,7,8,count(*),concat(
                (Select concat(0x5b,email,0x3a,user_name,0x5d)
                        FROM ecs_users
                        LIMIT 9456,1), floor(rand(0)*2))x
         from information_schema.tables
         group by x
ORDER BY pg.package_id, pg.goods_id;

不知看懂没有，反正这句SQL是解释不通的。由于网站跑在ECshop2.7.2的环境之上，问题肯定来自代码缺陷。之前似乎有发过ECShop的牢骚，作为一个商业软件，而且是做交易平台的商业软件，竟然如此不专业种种的操作。特地浏览了一下代码，发觉代码里面的更加经典！几乎没有对任何变量进行校验和过滤！

由于程序不是我开发的，无法追溯源。只能根据日志进行反查，找到了根基

1. flow.php中2157行中json来源可由客户端定义，导致2182行$package->package_id不可控。
2. include/lib_order.php中对include/lib_common.php 的function get_package_info($id)可以植入SQL
3. 畸形SQL导致Mysql返回空信息
4. 攻击者获得无限量优惠包，仅此而已。

无话可说！引以为戒吧！

时隔了5年多，不妨回头重新从新的高度上说说LAMP结构的网站如何支撑尽可能大的负载。同样说明，本文代表站长Litrin的个人意见，欢迎共同探讨，但喷子慎入。

首先声明的是，以下一堆相对无趣的文字仅针对一系列负载到了至少10W pv以上级别，对于较小规模的网站大可不必遵守，还是提倡成本优先的原则，到了对应的PV级别想必也会有足够的财力和物力去改版了。

初期规划

这里主要还是指设计模型等前期工作。MVC的设计结构深入人心，不得不承认确实大多架构设计师首选的设计结构必是MVC。事实上，在一个网站上最容易获取，最不缺的资源是CPU和内存，最大的瓶颈都是出现在IO。

作为LAMP架构最大的问题就是MVC的代价太大，层层的封包意味着重复判断；打开大量的程序文件只会严重拖累性能。网上很多免费的、开源的PHP框架，用过的几个诸如ThinkPHP, ZF等应付中小型网站绝对没有问题，但都不适合大负载的网站。甚至包括Smarty这样单纯的模版引擎，大量的IO操作会拖累整体性能。如果不考虑其他因素，我甚至都考虑过All in 1的垃圾结构——这当然不现实。但恰恰是这种all in 1却正是大负载最适合的结构。奇怪的悖论。

受GAE的影响，曾经想过API+XML的方式实现网站架构，但后来打消了这个念头。XML本身的结构冗余度很多，这也就意味着信息承载率低。在内部几台服务器之间的通讯状况想必都没有必要搞XML，如果要搞类似的模式，CSV方式反倒是不错的选择。XML是为了开放给第三方用户的。

数据库设计

读写分离这个是众所周知的秘密了。Mysql 的Master + Slaver的设计真的很方便！最多就是多搞几重的读写分离。

拆表、拆库、分机器，大表做纵拆，宽表做横拆，不关联的分机器；纵拆是为了省时间，横拆是为了省内存，分机器是为了分负载。Mysql在几百万行数据级别以下性能是很不错的，超过这个数量级，就算机器再强悍都会死的很难看，mysql垃圾的锁表机制会展现无疑。没有人愿等到30秒以上的Respone，何况我曾经遭遇一个45分钟以上的Select操作（一重操作，没有用到Like，使用索引）。曾经用过mysql 的分区表，感觉这种方法更像是在打补丁——改变数据库结构去适应程序，很奇怪的流程，更何况即便逃过这次不拆，迟早有一天还会回来拆的。

索引，该有的全都有，但对于写操作频繁的表，索引反倒成了累赘，不要让索引数占到字段数的30%以上这是约定俗成的标准吧。

memcache，没什么可以多说的，这玩意基本上就是铺硬件换时间的。

说道非关系型数据库，好像近期很热门。怎么说呢？越是复杂的网站越是能体现出它的优势，但问题是大多数网站都不会像twitter或者Facebook这么复杂，况且大多数程序员的逻辑还是SQL模式，贸进很可能搞砸。

WWW服务器拓扑设计

F5这类的设备是必须的，之前曾经觉得LVS可以替代F5这样的设备。用过之后才发现，这等于是将整个网站的身价性命都扔到了一台服务器上，一旦宕机或者被侵入呢？

对于Apache还是nginx的争论持续了很久。nginx很快速，可以将单独的PHP负载分离出去，但没有apache来的灵活。要根据需求再做评价。

异步操作和缓存机制

这个貌似也没有什么花头，调整好负载之后可以将一部分操作异步到数据库相对空闲的时段进行，达到移峰填谷的效果。配合memcache或者其他的缓存机制本身也是动转静的手段之一。

自动和手动的问题

属于代码级别了吧。良好的编程规范对系统的优化是很显著的。漫山遍野的select *， 大量的变量不清空是高负载系统的忌讳。纵然php的内存处理机制再出色，它永远也不会理解你设置的变量什么时候失效，减少这看似寥寥无几的空间乘上惊人的pv数也是很可观的。

我想，排除了其他因素，诸如网管可能有远程监视硬盘之类的技术，仅仅通过公司企业的前端路由——估计他们这种规模的企业，一定有深包分析之类的高级设备，完全可以清除的知道谁在使用Chrome，原因就是因为Chrome正在测试google下一代的web协议spdy。

单从发音上就知道spdy = speedy。快！它的核心是针对目前HTTP传输中对多重数据传输的低效，无优先排序功能重新构架的。google已经在自家的gmail等应用上偷偷支持了spdy协议，据说可以提升接近一半的传输速度。本想看看他们的协议白皮书，无奈，众所周知，这个网站并不存在。

大致上概括下，spdy协议可以让网页打开时优先传输html，完成后再去传输图片和js，css。而且就我理解下来，spdy是支持压缩和加密传输模式的，而且效率远高于http。

如果需要让您当前的网站支持spdy协议的传输，google提供了一个apache mod 。但说实话，由于spdy协议目前只是处在测试阶段，而且仅仅只能被Chrome支持，我还是不建议马上部署这个模块。

查看spdy的状态简单的方法是在Chrome中打开这个链接：chrome://net-internals 。

回答开始的话题，由于目前spdy尚处于测试阶段，大部分企业的防火墙都不会认为这是一个正常的http访问，兴许会作为一个攻击来源之类的抛出警报。网管们烦心，发出个邮件禁止一下也在情理之中。

话说去年11月份，刚接到一个项目，要在Android平台上开发一个基于手机通讯录的应用。众所周知的原因，Android开发者网站http://developer.android.com/ 在国内无法访问。一开始，我直接下载了本地版本的html全站镜像文件。作为一开始了解这个平台，读读SDK搭建方法一点问题也没有。后来对照几个example进行开发联系，发觉很多类型不知道何去何从，用了本地搜索发觉也是摸不着头脑。于是有了一个想法：为何不把手册放在网上，借助google来索引整个网站。

于是我马上切换到Geeker模式，浏览手册的目录，发觉所有的html都是很规范的相对路径，完全可以直接放在网上。而且主目录下已经有了部分GAE的文件，似乎可以很方便的上传到GAE。尝试了几次，大失所望，原来单是文件数目就有接近3000，超出了GAE 1000个文件的限制很多。

切换回程序员模式。想到之前曾经写过一个系统底层的Python脚本，为了方便翻阅归档的文件，通过python对于zip良好的支持和多线程操作，一次性diff多个版本的区别。用这种方式可以解决GAE的一系列限制，上传网站。
很快，最基本的代码完成了，网站也上传成功，大部分情况工作的也不错。于是有了想要把这个项目分享的想法。
既然要开源，只是基本的功能实现是不够的，而且代码也不够清晰。就算原理再简单，也应该给人清新的感觉，于是先重写了原型代码。想了很久有什么功能需要再添加，后来想到了GAE的CPU Time其实也是有限制的，zip解压又是CPU耗费型的。又通过GAE的Data Store和Memcache做了双重缓冲。大致上有点意思了，于是申请了google code的空间，通过SVN放出了第一个版本ver0.1作为测试。最后，为了显得有点可扩展性，写了一个接口，可以支持插件，其实主要是纯文本和HTML，最初的想法只是看到Android手册中的HTML有太多的空格和换行，很浪费带宽而已。

话说当时正巧我的广告帐户里面攒到了$80多之后，很久没有动静。始终无法达到最低的汇款金额$100。要知道，$80比$0还要折磨人。切换到商人模式，复杂化了插件，让他可以自动的制定位置插入广告。又复杂了一步。

本来这个项目只是为了想要借助google的本地索引来完成一些事情，谁知道上线很久以后，Google仍不能完成全站的收录。SEO吧。又写了sitemap的支持功能到项目中，发布了Ver0.2版本。

剩下的任务就是不断的修正bug而已。春节前几天，我觉得整个项目该有的功能都差不多了，于是这才开始整理feature——生命周期完全颠倒了。也正是这个原因，回头看看之前的代码，已经乱的差不多了。特别是插件的接口我觉得真的很垃圾，况且即便是程序员，也没有几个人愿意通过大量的正则表达式来实现功能，于是索性取消了。

为了给这个项目制作一个像样点的文档，我特地在Mac app store里面买了一套iwork，花了差不多$90大洋。呵呵，也算是开发费用的一部分吧。

然后就是Ver1.0 RC 版本，虽然这个项目没有什么人关注，但很庆幸，有几个人特地找到我，愿意参加测试，在此感谢下！

今天终于咬牙发布了最终的Release版本。希望不要马上推出个什么紧急补丁之类的东西。

说到下一个版本，我觉得应该遵守GAE的习惯，采用整数版本号来表示Release版本，小数表示tag或者snap版本。2版本应该增加一个管理员界面，在后台上多做些文章；重新启用插件部分，当然表达方式越简单越好。Zipsite项目的最终目标是成为一个运行在GAE沙盒内部的一个快速、傻瓜化的网站搭建系统。

PHP程序员的逻辑：

数据经过加工，传输给模板引擎，模板引擎选择合适的模板填充，输出为页面通过www服务器传输给用户。
再此之前，请自查手册，熟悉ob_end_clean() flush()以及相关联的输出控制函数。

如果能看懂如下伪代码，并认为这是一团糟糕的死循环的话请继续：

<?php

set_time_limit(300);
header('Cache-control: Private');
ob_end_clean();

while (true) {
    if ($Count % 2 == 0){
        echo "<div>";
        echo time();
        echo "</div>";

        flush();
    }

    $Count ++; 

    sleep(1);
}

echo优势之一——用户体验的改善

尽管现在手机已经进入了3G时代，网速已经接近了有线宽带的水平，但作为手机网络而言，最令人头疼的就是它的不稳定。用传统的方式载入模板，所有的输出必须先行等待数据完全准备好之后才能一次性输出，这可能会需要等待很长时间。API要时刻考虑到可能会出现的断网问题，特别是在大段文件之后，较长时间的等待响应时间之中如果一旦出现网络间断（不是中断）就会让手机端白屏，影响用户体验。

利用此段代码正是n久之前，在没有大规模使用前端缓冲或者ajax技术的时候，很多网站经常看得到的那种分段式载入的效果。程序的逻辑是：step1完成，立即输出给www服务器，在用户等待数据下载的同时准备step2，依次类推。确保用户先“有东西看”。即便中途网络间断，照样可以获取网页内容。
echo优势之二——HTTP长链接的实现

现在很多网站都在搞微博或者网页版本的IM，山寨版本Kik之类的东西。特别是后两种，设置一个定时刷新的js如果间隔很大，等于没有意义；间隔很小的话，请自行领略F5卡住对服务器的影响。要知道对于www服务器而言，建立/中断一个HTTP连接的操作同样是一个高资源耗费的过程。

利用此段代码的逻辑就是将http通常使用的短连接方式模拟一个长链接，每一个用户开一个http通道后不再立刻关闭而是建立一个持久的信道，后台执行一个轮询，一旦有新的数据则第一时间通过此信道传输给客户端。这种方式配合Json可以完成相当一部分数据刷新的需求。或者可以尝试用这种方式简单实现一些BS之间的心跳效果。
其他一些稀奇古怪的用法

Firefox这类的Mozilla系浏览器可以通过自有的header命令撤销之前的输出，通过定时的发送这个命令就可以达到不刷新而刷新的效果。具体header命令请google。

利用此模型带来的问题：
set_time_limit(300);只是防止php超时罢了，对于www服务器而言，它也有自己的时效性，请注意不要被www踢出来。特别是apache有个keep_alive的设置要注意。

1. 通用性，有前端缓冲的网站就暂时别想了，就算能成功也不保险啊。对于近期比较风光的轻量级http服务器而言，由于是单进程的，长链接对他们来说也不是擅长的。
2. 浏览器缓冲的问题。有些“智能型”浏览器会认为你的服务器响应不及时而自说自话的启用了n年前的缓冲页面。而且对于IE这类有一大堆“安全策略”的浏览器而言这样的结果反而会白屏（IE7以后256个字节以内的信息不会显示）所以header一定要写，上面的那段仅仅只是伪代码，我不愿保证这个可以在任何浏览器上调试通过。
3. 代码的复杂度，不用我说了吧。All in 1的代码反正我不想读。

知道GAE可以直接跟gtalk挂钩推送消息，可能一直挂Gtalk的人远没有挂QQ和MSN的多（密之声：Gtalk又没有星星和钻石，挂也没劲），但有了Android + 3G的实时在线，这种方式却可以直接替代SMS这类花钱的服务，何乐不为？

大致上完成了原型，制作了一个基于Python的命令行程序，不敢独享，分享给大家。希望大家能够一起加入这个项目完善它。
在此之前，请现将 server-say @@@ appspot.com （你懂的！）加为好友

#!/usr/bin/python
# -*- coding:utf-8 -*-
import sys
import re
import urllib

class ServerSaid:

	ApiURL = 'http://server-say.appspot.com/api'
	#
	#请到http://server-said.appspot.com/注册您的Ip地址。没有注册的Ip每小时最多10条消息。
	#
	Account = ''
	MessageBody = ''
	DefaultEncode = 'utf-8'

	def SendMessage(self):
		cleanMessage = self.MessageBody.encode(self.DefaultEncode)
		if (self.checkEmail(self.Account) and self.checkMessage(cleanMessage)):
			cleanMessage = self.MessageBody.encode('utf-8')
			url = self.ApiURL + '?account='+ urllib.quote(self.Account) +'&message=' + urllib.quote(cleanMessage)
		#	print url
			query = urllib.urlopen(url)
			if ( query.read() == '200' ):
				print 'Message be sent!\\n'

			else:
				print self.Error(0)
		else :
			print self.Error(1)

	def Error(self, code=0):
		return  'Message can\\'t be send! \\n'

	def checkEmail(self, Email):
		RegexString = r'^\\w+([-+.]\\w+)*@\\w+([-.]\\w+)*\\.\\w{2,5}$'

		return re.match(RegexString, Email)

	def checkMessage(self, Message):

		RegexString = r'^.{1,140}$'
		return re.match(RegexString, Message)

if __name__ == '__main__':

	if (len(sys.argv)>1):
		handler = ServerSaid()
		handler.Account = sys.argv[1]

		Message = sys.argv[2]

		handler.MessageBody = Message.decode(handler.DefaultEncode)

		handler.SendMessage()
	else:
		print 'serversaid.py YOUR_GTALK MESSAGE '

这里为了防止消息的滥发，使用前最好先到 http://server-say.appspot.com/ 注册一下。没有注册的IP每小时仅能发送10条消息，我想大部分情况下也够用了。注册了的用户可以无限制的发送消息了，除非我在GAE注册的那张信用卡里的钱花光——我会哭的。

啥也不说了，PHP接口也搞定了！

< ?php
/*
 *    Gtalk 通告机器人 Ver 0.1
 *
 *    Litrin Jiang 2010/12/02
 *
 * --------------------------------
 *  1. 2010/12: v0.1 原型实现
 *
 */

Class Gtalk{

	private $APIUrl = 'Http://server-say.appspot.com/api?';
	//Api 的地址，不要修改

	public $mothod = 'get';
	//默认的提交方式，现阶段仅支持get
	public $account = '';
	//接收人的Gtalk账户
	public $messageBody = '';
	//消息主体，最多支持140个字符

	public $Charset = 'UTF-8';

	public function Send($account=null, $messageBody=null){
		if (is_array($account)){
			foreach ($account as $key) {
				$this->Send($key);
			}
		}

		if ($account === null){
			$account = $this.account;
		}
		$this->CheckAccount($account);

		if($messageBody === null){
			$messageBody = $this->messageBody;
		}
		if ($this->Charset != 'UTF-8'){
			$messageBody = iconv("UTF-8", $this->Charset.'//IGNORE', $messageBody);
		}
		$this->CheckMessage($messageBody);

		$url = $this->APIUrl .'account=' . urlencode($account) . '&message=' .  urlencode($messageBody);

		$query = file($url);
		/*
		if($query == '200'){
			return true;
		}else{
			return false;
		}*/

	}

	private function CheckAccount($account){
		$regexString = '^\\w+([-+.]\\w+)*@\\w+([-.]\\w+)*\\.\\w{2,5}$';
		echo ereg($regexString, $account);
		if (ereg($regexString, $account) != true){
			#throw new Exception("Value not a Email account! ");
		}

	}

	private function CheckMessage($messageBody){
		$regexString = '^.{1,140}';
		if (ereg($regexString, $messageBody) != true){
			#throw new Exception("Message not a allowed format! ");
		}
	}
}

?>

看了看要上传的文件夹，5000多个文件，小气的google根本满足不了我。 想到Python的灵活性，在手册中翻了到了zipfile类库。有门！就上传zip文档，边解压边浏览。Google要用时间来换空间那就累死他的CPU 写个GAE应用loadzip.py：

#!/bin/env python
##
##	This is a project for Google App Engine
##		that support create a webisite by ZIP packages!
##
##	By Litrin J. 2010/11
##	Website: www.litrin.net
##	Example: android-sdk.appspot.com
##

import wsgiref.handlers
from google.appengine.ext import webapp
from google.appengine.api import memcache
from zipfile import ZipFile
import os
import logging
import mimetypes
import re

class MainHandler(webapp.RequestHandler):
	'''
This is a project for Google App Engine that support create a webisite by ZIP packages!
	'''
	URL = ''
	CACHEDTIME = 60*60*24*30
	#setting memcaching time (seconds)

	def get(self):

		self.URL=self.request.path

		if ( self.URL[-1:] == '/'):
		#Get the defaule file for the path
			self.URL+='index.html'

		sRealFileName = os.getcwd() + self.URL

		if (os.path.exists(sRealFileName)):
		#If the file not be ziped, read it drictory
			fNoZipedFile = open(sRealFileName,'r')
			Entry = fNoZipedFile.read()
			fNoZipedFile.close()

		else:
			Entry = self.loadFile()

		self.buildMineType()
		#Set the Mine type in header

		if (self.response.headers['Content-Type'] == 'text/html'):

			Entry = self.regex(Entry)

		self.response.out.write(Entry)
		#Response building finished!

	def loadZipFile(self):
	#Load the file from zip files. This is the core function!
		lFilename = self.URL.split('/')

		iPathLevel = 1
		#Loop count, The dir layers
		bLoaded = False
		#Sucessful marks

		while(iPathLevel < = len(lFilename)):
		#Get the zip file name and the filename from the URL, support muli-layer
			sFilePath = os.getcwd()
			sFileName = ''
			iElementCount = 1

			for sElement in lFilename:
			#Set or reset the Zip filename
				if ( iElementCount <= iPathLevel):
					sFilePath += sElement + '/'

				if ( iElementCount >= iPathLevel ):
					sFileName += sElement + '/'

				iElementCount += 1

			sFileName = sFileName[0:-1]
			sZipFilename = sFilePath[0:-1] + '.zip'

			if (os.path.exists(sZipFilename)):
			#Found the Zip file
				ZipFileHandle = ZipFile(sZipFilename)
				Entry = ZipFileHandle.read(sFileName)
				bLoaded = True
				ZipFileHandle.close()

				if (Entry is not None):
					logging.info(sFileName + " in " + sZipFilename + " Loaded!")
					return Entry
					break

			iPathLevel +=1

		if (bLoaded==False):
		#Can't file the file in Zip packages
			logging.error('No found ' + self.request.path + '' +sZipFilename+' !')
			self.error(404)

			return None

	def loadFile(self):
	#Load in from memcache if cached
		Entry = self.loadFromMemcach()

		if Entry is None:
		#If not cached, cache it
			Entry = self.loadZipFile()
			if(Entry is not None):
				self.writeToMemcache(Entry)

		return Entry

	def loadFromMemcach(self):
		memcachkey = self.URL
		#The cache key is URL

		Entry = memcache.get(memcachkey)
		if Entry is not None:
			return Entry

		else:
			return None

	def writeToMemcache(self, data):
		memcachkey = self.URL
		#set the URL as the key
		memcache.add(memcachkey, data, self.CACHEDTIME)

		logging.info(memcachkey + ' cached!')
		return True

	def buildMineType(self):
	#Building the MineType in Http header
		sFilename = os.path.basename(self.URL)
		lFileName = sFilename.split(".")
		sExFilename = lFileName.pop()
		#Get the file ex-filename

		mimetypes.init()
		sMineType = mimetypes.types_map['.'+sExFilename]

		if (sMineType == ''):
		#Others can't be idented, set to HTML
			sMineType = 'text/html'

		self.response.headers['Content-Type'] = sMineType
		#Send Content-type

	def regex(self, Entry):

		lRegGroup=(
			('\n+', '\n'),
			#
			('\t+', '\t'),
			#
		)

		for sRegCell in lRegGroup:
			(sSource, sTarget) = sRegCell
			rInfo = re.compile(sSource)
			Entry = rInfo.sub(sTarget, Entry)

		return Entry

def main():
	application = webapp.WSGIApplication([('.*', MainHandler)], debug=True)
	wsgiref.handlers.CGIHandler().run(application)

if __name__ == '__main__':
	main()

比较简单，我也没有写太多注释。考虑到Google一直被这么搞，挂掉也不好，于是启用了memcache。 重写app.yaml

application: android-sdk
version: 1
runtime: python
api_version: 1

handlers:

- url: .*
 script: zipload.py

#- url: /
# static_files: index.html
# upload: index.html

准备就绪，把手册中每一个子目录压缩成zip，极限大小也无所谓，然后把手册根目录下的所有文件和这两个文件放在同一目录下。上传至GAE便可。 捎带说下，由于GAE还有对文件大小的限制。用此方法还无法完全解决Adroid手册上传的问题，后来我用了分级的目录结构搞定的，原理上跟上面是一致的，在此不再累述了。 把我的Android手册网站共享给大家 http://android-sdk.appspot.com/index.html PS:

1. Linux下的Idle工具真烂，远不及以及够烂的windows版。好在SPE这个工具很好用。
2. GAE的sdk for linux没有桌面工具，只能用命令行方式，在此代表Linux用户表示抗议！

本项目的后续版本已经通过google code开源，敬请访问：

http://code.google.com/p/zipsite/ 

获取最新版本！

安装nginx
老一套的把戏 sudo apt-get install nginx

安装好之后sudo /etc/init.d/nginx restart 启动服务，正常情况下，你应该可以访问它获得经典的Welcome to nginx!欢迎界面。

安装php5

不同于apache的mod方式，nginx只限于fastcgi模式调用php。说道fastcgi，之前一直有兄弟问过我CGI和FastCGI的区别。其实FastCGI就是一个预先启动的进程，减少了CGI方式每次启动解释器的资源耗用。当然，这个方式带来的缺陷就是很容易因为解释器的挂死而失效。

sudo apt-get install php5-cgi

修改nginx的配置，使其支持php5

sudo /etc/nginx/sites-available/default

location ~ \.php$ {
 fastcgi_pass   127.0.0.1:9000;
 fastcgi_index  index.php;
 fastcgi_param  SCRIPT_FILENAME  /var/www/nginx-default$fastcgi_script_name;
 include fastcgi_params;
 }

需要注意的是，默认nginx默认配置中注释掉的那一段中对于fastcgi_param的那段配置是有问题的，需要设置正确的路径。

如果你重启nginx的话，这里是无法正常使用php的，原理是php的fastcgi进程还没有启动。

sudo php-cgi -b 127.0.0.1:9000  & //与上面的fastcgi_pass设置是同一端口

正常情况下，nginx已经支持了php。

由于这种方式容易出现问题导致php失效。这里我建议使用spawn-fcgi守护进程。

sudo apt-get install spawn-fcgi

sudo spawn-fcgi -a 127.0.0.1 -p 9000 -c 5 -f /usr/bin/php5-cgi //其中的 -c意味着同时同时启动5个进程

为了更加方便，不妨修改下nginx的启动脚本

sudo nano /etc/init.d/nginx //修改

start)
 echo -n "Starting $DESC: "
 test_nginx_config
 start-stop-daemon --start --quiet --pidfile /var/run/$NAME.pid \
 --exec $DAEMON -- $DAEMON_OPTS || true
 echo -n "Starting Php FastCGI"
 /usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -c 5 -f /usr/bin/php5-cgi
 echo "$NAME."

stop)
 echo -n "Stopping $DESC: "
 start-stop-daemon --stop --quiet --pidfile /var/run/$NAME.pid \
 --exec $DAEMON || true
 echo -n "Stopping Php FastCGI"
 killall php5-cgi
 echo "$NAME."
 ;;

查阅了官方网站，发掘Google Syntax Highlighter for WordPress插件用的1.5版已经停止更新，只能使用2.0以上的版本，但2.0版本和之前的版本又存在兼容的问题，直接替换是不行的。不想每篇文章的修改<pre>标记，那就改插件喽。

1. 下载最新版本的Syntax Highlighter，解压。
2. 将原来/wp-content/plugins/google-syntax-highlighter目录下的Scripts和Styles目录清空后，分别用新版本的对应路径中的文件替换，注意大小写方式请不要变动。
3. 修改google_syntax_highlighter.php文件，我用了minify的插件，这里就直接调用了。

<?php

function insert_header() {
 $current_path = get_option('siteurl') .'/wp-content/plugins/' . basename(dirname(__FILE__)) .'/';
 ?>
 <link href="<?php echo $current_path; ?>Styles/shCore.css" type="text/css" rel="stylesheet" />
 //可根据自己的需要选择不同的Styles
 <link href="<?php echo $current_path; ?>Styles/shThemeEclipse.css" type="text/css" rel="stylesheet" />
 <?php
}

function insert_footer(){
$current_path = 'wp-content/plugins/' . basename(dirname(__FILE__)) .'/';
 ?>
<?php
/*
<script src="<?php echo $current_path; ?>Scripts/shCore.js"></script>

<script src="<?php echo $current_path; ?>Scripts/shLegacy.js"></script>
<script src="<?php echo $current_path; ?>Scripts/shBrushCSharp.js"></script>
<script src="<?php echo $current_path; ?>Scripts/shBrushPhp.js"></script>
<script src="<?php echo $current_path; ?>Scripts/shBrushJScript.js"></script>
<script src="<?php echo $current_path; ?>Scripts/shBrushJava.js"></script>
<script src="<?php echo $current_path; ?>Scripts/shBrushVb.js"></script>
<script src="<?php echo $current_path; ?>Scripts/shBrushSql.js"></script>
<script src="<?php echo $current_path; ?>Scripts/shBrushXml.js"></script>
<script src="<?php echo $current_path; ?>Scripts/shBrushDelphi.js"></script>
<script src="<?php echo $current_path; ?>Scripts/shBrushPython.js"></script>
<script src="<?php echo $current_path; ?>Scripts/shBrushRuby.js"></script>
<script src="<?php echo $current_path; ?>Scripts/shBrushCss.js"></script>
<script src="<?php echo $current_path; ?>Scripts/shBrushCpp.js"></script>
*/
<script src="/wp-content/plugins/wp-minify/min/?b=<?php echo $current_path; ?>Scripts&f=shCore.js,shLegacy.js,shBrushPhp.js,shBrushSql.js,shBrushPython.js"></script>
<script>
dp.SyntaxHighlighter.ClipboardSwf = '<?php echo $current_path; ?>Scripts/clipboard.swf';
SyntaxHighlighter.all();
dp.SyntaxHighlighter.HighlightAll('code');
</script>
<?php
}
add_action('wp_head','insert_header');
add_action('wp_footer','insert_footer');
?>

测试，通过！

CVS结构示例：1300428,浙江省嘉兴市,联通130卡 （一个手机号码的对应归属地列表）

configfile:

from google.appengine.ext import db
from google.appengine.tools.bulkloader  import Loader

class MobilePhone(db.Model):
  Number = db.StringProperty()
  Area = db.StringProperty()
  BrandType = db.StringProperty()

class MPLoader(Loader):
  def __init__(self):

    Loader.__init__(self, 'MobilePhone',
                    [('Number', unicode),
                     ('Area', unicode),
                     ('BrandType', unicode),
                     ])

loaders = [MPLoader]

主要分析了一下，问题分为几类。

1.验证不能通过的问题：

这个问题很多时候是一个低级错误，之前我曾经犯过类似的错误。在app.yaml中的handlers

handlers:
- url: /remote_api
  script: $PYTHON_LIB/google/appengine/ext/remote_api/handler.py
  login: admin
- url: /*
  script: main.py

这个/*的配置必须放在最后。否则所有的访问都会直接匹配main.py自然出现问题。

2.跟编码有关的错误：

这个错误是GAE SDK的一个bug，恐怕对于ASCII系统的用户没什么关系，对于我们UTF-8，GB2312，ASCII已经昏倒的用户来说，这是个严重的问题。

在GAE的安装目录下 google\appengine\tools\bulkloader.py文件中2521行

    for (name, converter), val in zip(self.__properties, values):
      if converter is bool and val.lower() in ('0', 'false', 'no'):
        val = False
      properties[name] = converter(val)

修改为：

    for (name, converter), val in zip(self.__properties, values):
        if converter is bool and val.lower() in ('0', 'false', 'no'):
            val = False
        if isinstance(val,str) and not isinstance(val, unicode):
            val=unicode(val,'utf-8')
        properties[name] = converter(val)

系统会将unicode类型的变量转换。

3.对于大容量数据的删除

GAE的限制，一次最多载入1000行的数据，每次最多删除500行数据，这对于像我制作的手机号码归属之类的大数据库是远远不够的，多次删除又会导致500报错，我的方法是使用task queue。
Task Queue在官方的中文文档中没有提及，在英文文档中介绍的也不够详细。个人的理解就是让系统定期的去访问一个页面而已，我的例子：

from google.appengine.ext import webapp
from google.appengine.ext.webapp import util
from google.appengine.ext import db
from google.appengine.api.labs import taskqueue

class MobilePhone(db.Model):
    Number = db.StringProperty()
    Area = db.StringProperty()
    BrandType = db.StringProperty()

class Delete(webapp.RequestHandler):
    def get(self):
        q = db.GqlQuery("SELECT * FROM MobilePhone limit 100")
        results = q.fetch(100)
        db.delete(results)
        q = db.GqlQuery("SELECT * FROM MobilePhone limit 100")
        if (q.count() > 0):
            self.addqueue()

        self.response.out.write('Hello world!')

    def addqueue(self):
        taskurl = 'http://ip-and-mp.appspot.com/'
        taskqueue.add( url='/del', params=dict(url=taskurl))
        self.response.out.write('added!')

每次删除100行，使用默认的default queue，即每秒一次。

4.关于命令行的问题

我按照中文文档的办法始终有问题，添加了–email=xxxx –passin的参数才成功。手册已经远远落后了。

GAE对于很多人来说只不过是当作撑杆来翻墙的。其实不管从哪个方面来说，GAE的理念就是一个搭载了Java或Python页面框架的虚拟主机，而且支持一大堆的扩展（google wave上的机器人）。借助了Microblog，我在GAE上架设了本站的镜像站点。

相对来说Google提供的SDK目前只能说是一个上传工具而已。很多功能，例如Xmpp，数据存储还没有办法完全模拟，只有页面框架和Memcache还算能用。相信google也会不断的加以完善。

说起Microblog，首先是一个不错的CMS系统。但可能是版本较低，加之GAE程序的调试比较麻烦，功能和结构上只能实现简单的blog功能。相比现成的blog空间反而麻烦不少。相信随着逐步的升级，这个系统将成为一个优秀的CMS。
想用Wordpress的导出工具直接生成一个新站，发现此功能还有问题，至少本站无法成功。于是只能顺手写一个扩展实现两地同步，尽管问题也不少。

说起Python，个人觉得是一个效率很高的语言，缺点就是产生这高效率的扩展太多，太混乱，初学起来很迷糊。顺手之后你就会觉得它作为高级语言，可以操纵的资源丰富的惊人。不过在此插一句，python3的转变真是太突兀了，大部分2.6之前的代码都要重新写过，对于GAE的目标环境还是用2.6以下搭建吧。

反复检查代码，无果。将文件上传到另外一台机器后IE也正常。反复修改KeepAlive，disk-cache之类的设置，完全没有效果。

真是叫人郁闷。

检查了apache的配置，感觉问题应该跟mod_deflate模块有关，相应的代码如下：

    <IfModule deflate_module>

        SetOutputFilter DEFLATE
        BrowserMatch ^Mozilla/4 gzip-only-text/html
        BrowserMatch ^Mozilla/4\.0[678] no-gzip
        BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
        SetEnvIfNoCase Request_URI \
                \.(?:gif|jpe?g|png)$ no-gzip dont-vary

    </IfModule>

关闭后IE恢复正常，考虑到一般情况下，mp3和swf压缩不了多少，但是却经常需要断点续传，重新修改相应配置：

    <IfModule deflate_module>

        SetOutputFilter DEFLATE
        BrowserMatch ^Mozilla/4 gzip-only-text/html
        BrowserMatch ^Mozilla/4\.0[678] no-gzip
        BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
        SetEnvIfNoCase Request_URI \
                \.(?:gif|jpe?g|mp3|swf|png)$ no-gzip dont-vary

    </IfModule>

完全正常！

分析下来大致原理如下（个人分析，无依据）：
首先假设的是我没有踩中任何一个bug。这个问题似乎跟原先出现过deflate的文件不能断点续传为同一个问题。

mp3采用流格式传输，没有完全下载结束就被暂停下载，由于系统启用了mod_deflat的压缩传输模块，本地保存的实际上是一个gzip过的mp3文件。

由于目前主流浏览器都支持断点续传，而对于断点续传的处理却各有不同，IE和chromium可能会先对于gzip之前的文件进行校验，发觉校验失败，认为这是一个错误的文件，不再进行续传；FF则是先不进行校验，或者校验失败后重新下载续传。

尚为猜测，希望各位朋友给个确凿的解释。

作为网站运行来说，日志分析是一个很重要的工作。当一个网站的日志到了一定程度，或者一个网站同时有多台服务器的时候，传统的文本日志分析总会遇到瓶颈。

这个时候我就会想起强大的sql语句。看了网上很多人的帖子，都是将日志转成sql语句再导入的，搞得有点复杂。本方案不需要任何多余的软件和操作，一切全是实时、自动，供各位参考。

主机至少需要预安装apache(废话！)和mysql的客户端。如果访问量不大且服务器的资源管够的话可以将mysql装在本地，否则建议一台独立的mysql服务器。

在apache配置文件或者虚拟主机配置文件中面添加

LogFormat INSERT INTO apacheLog (ID, dateTime, IP, URL, code, referer, userAgent, size, request) VALUES ( NULL , \"%{%Y-%m-%d %H:%M:%S}t\", \"%a\", \"%U\", \"%>s\", \" %{Referer}i\", \"%{User-Agent}i\", %b, %T);" sqlcomm
CustomLog "| /usr/local/Mysql --host=HOST --user=USER --password=PASSWORD --database=LITRIN_NET" sqlcomm

建立数据库apacheLog。

CREATE TABLE ` apacheLog ` (
  `ID` int(11) NOT NULL auto_increment,
  `dateTime` datetime NOT NULL,
  `IP` varchar(15) NOT NULL,
  `URL` varchar(256) NOT NULL,
  `code` varchar(3) NOT NULL,
  `referer` varchar(256) NOT NULL,
  `userAgent` varchar(256) NOT NULL,
  `size` int(11) NOT NULL,
  `request` float NOT NULL,
  PRIMARY KEY  (`ID`),
  KEY `dateTime` (`dateTime`)
) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=latin1;
SET character_set_client = @saved_cs_client;

 确认无误后重启apache生效！

其实整个流程很简单：先是利用LogFormat设置将日志转换为接近sql的格式，再通过CustomLog 调用pipe实现mysql写入。你也可以参照http://httpd.apache.org/docs/2.2/mod/mod_log_config.html#formats的格式设置写入自己关心的数据。
此外，你也可以使用SetEnvIf配合正则表达式过滤掉诸如图片、CSS、JS之类相对不重要的信息。

很多企业对互联网的访问进行了限制，如何突破防火墙的限制成了一个问题。本文就是利用了SSH tunnel搭建了socket5代理。

首先，申请一个外网的ssh帐户，个人建议使用http://www.unix-center.net/提供的免费资源，该网站还提供多种平台主机可供测试之用，非常不错！当然，如果可以使用密钥方式登录那就完美了。

申请好账户之后，依然在本地安装ssh的客户端，windows推荐putty。

安装好后执行putty，在hostname里面输入主机名，或者用户名@主机名。我选了FreeBSD的那台，有兴趣的话还有ubuntu，Sun，甚至龙芯一系列主机可供挑选

Putty 主界面

选择ssh->tunnels，在source栏里添加你要提供的端口号，一般随便填一个未使用的端口就可，我用了8080端口。选择Dynamic，点击add。这里需要说明的是，如果你的主机允许别人使用的话，请勾选最上面的Local ports accept connection from other hosts。

Putty ssh tunnel界面

点击Open确认连接，在接下来的窗口中输入用户名和密码。最小化窗口，不要关闭。

打开命令行，输入命令netstat -an，如果出现了你刚才输入的那个端口号的侦听，说明搭建成功！socket服务已经完成。

netstat -an

浏览器设置，IE:internet选项，连接，局域网设置，勾选“为LAN使用代理服务器”，高级，套接字选择127.0.0.1并填写端口号。完成设置。

IE 设置

对应的命令行：

1. plink : plink -C -N -f -D 端口号 用户名@主机名
2. ssh: ssh  -C -N -f -D 端口号 用户名@主机名

PS:
话两头说，如果你负责一个企业局域网的话，稍大点的企业如果要限网，SSH端口是绝对要加以限制使用的。伟大的防火墙亦是如此。