一个程序猿

那个500错误快把我整死了，结果才分析可能django把静态文件当脚本处理了。

对于线上部署，完全可以用rewrite的方式进行解决。可本机调试，用的是自带的server，可搞死人了。

不过搜索后发现，django解决这个问题了，使用一个叫做 django.views.static.serve 的方法处理这些静态文件。

实现代码如下:

然后，把所有静态文件放到 static 目录下，即可。

不过这种方式只适合开发环境，在线上的时候还是需要把这个问题交给httpserver

平时还是windows用的多，所以很多测试也习惯用windows。

首先下载mongodb的windows编译版本：

http://www.mongodb.org/display/DOCS/Downloads http://downloads.mongodb.org/win32/mongodb-win32-i386-1.2.4.zip

解压后存放于 D:\mongodb

创建数据存放目录 D:\data

启动数据库 D:\mongodb\bin\mongod –dbpath D:\data

然后测试连接情况 D:\mongodb\bin\mongo

因为都是使用默认配置，如果出现以下回显，则证明安装成功

进阶：为了平时使用方便，把mongod注册为系统服务

D:\mongodb\bin\mongod –dbpath D:\data –install #注册为系统服务

修改服务的端口 D:\mongodb\bin\mongod –dbpath D:\data –port 10001

其他配置 敲 mongod -h 就会出来

1、千万别碰网游，除非你靠网游吃饭
2、多看书总是有用的，包括闲书
3、多交朋友，多帮助别人。感情是个银行，利息很大
4、学习依然是最重要的
5、虽然很俗，虽然通货膨胀，但人民币是最可爱的东西

没想到这两个词具体是什么意思，但这肯定是我的缺陷了。

前几天培训，被指出这个毛病，其实仔细回想，工作中何尝不是没有头绪条理，很多事情忙的团团转，搞的一团糟。

改正这个毛病其实用了很长时间，从期初开始做简单的文件记录，到后来大量的纸质手稿，到现在详细的记录和思维软件(mindmanage)的应用，对做事有了很多提高。

昨天晚上加班，自愿加班，去完成一个我所认为半天就能完成的工作，其实用了将近一天，实际工作时间也算半天吧。时间浪费了一大半，是因为以前已经实现的一个冗杂的逻辑又去想了一遍，结果还没想明白。后把之前的逻辑拿来，20分钟顺利结束了战斗。

非常勤恳的工作不是啥好事，漂亮得完成工作并把时间留给自己才是王道。

最近一直在折腾dz的sessions表优化。经过某群好友的各种方法提示和一些高数据量用户论坛的鼎力支持，总结以下优化方案。部分方案是在某些论坛正在使用的，部分方案是我发散思维总结的，没有经过大数据量和大负载下的应用，只是作为一个备选的方案，当然欢迎朋友们拿去实践。

1、分库

这个方法至少两三个注册用户百万级至千万级的论坛在使用。实施也比较简单，只需要把sessions表放在其他的库中，跟论坛主库分离，这样，就可以用多台服务器来分担论坛压力。sessions表查询的地方，如果直接查询，则连sessions表所在的库，如果是联查，则分别查询后，合并插叙结果。

2、砍功能

这个方法虽然不实用，但的确有效。仔细看看dz的一些sql语句，就知道砍掉某些功能摆脱sessions表的约束，性能会有多大的提高。砍功能，最终还是为了提升性能。但如果不砍功能又提升性能，才是终极目的。此方法适用于对某些统计功能要求不高的论坛使用。

3、memcached存储sessions，异步统计用户的在线数据

此方法其实还是砍掉了论坛的用户在线统计功能而独立开发一套统计系统。此思路来源于我们的统计服务器。如果统计服务器已经统计了部分信息，就没必要再去耗费大量的sql效率去进行统计。当时我们负责统计的吴同学正好也要开发一套针对不同系统的统计代码，我可以直接把要统计的数据提交给统计服务器，再由统计服务器返回统计结果。以异步的方式来统计，化解dz sessions表的性能瓶颈。而统计信息的异步提交，可以提交到本地数据库，可以提交到第三方统计系统，当然也可以根据需要独立开发一套小型统计系统。

方案3是本人原创方案，方案的修改代码在以下附件中： 异步session统计信息同步，欢迎大家使用。

由于dz的开发考虑的是大众市场，功能冗余代码逻辑复杂。但优化dz并不是那么的困难，而优化的思路，也是跟其他系统优化相似：mysql瓶颈。一个即将崩溃的系统，或者频繁崩溃的系统，是进行优化的最好示例：减少sql查询，提高sql语句查询效率。dz考虑大众市场，为了提高产品兼容性，并没有引入太多的第三方软件：比如memcached，bdb，ttserver等，虽然内部已经为主从预留了接口，但未见很明显的文档支持。
第三个方案优化的思路也很明显，减少sessions表的慢查询而改为memcached高速的数据存储，把统计功能做接口留出，此功能给第三方来做。这样sessions表的瓶颈即可消除。

今天一天没干别的，没写程序，没玩游戏，除了中午参加公司的一个吹气球比赛得了第一，获得“**公司第一吹”的称号。

一天都在考虑使用完全开源的方案来解决dz sessions表的性能问题。中午大脑极度紧张，以至于撞在关兄的工位，工位几近散架。

在轻度震荡中想到一个优化方案，就是分离sessions表的一些功能，把sessions会话和统计功能分离，并且统计使用异步提交。

这样，如果sessions会话生存期10分钟的量计算，20万人同时在线，sessions会话存memcached，而统计只用少量字段在独立的表中。因为php的sessions操作速度高，而统计信息调用并不是非常频繁，并且查找也是简单的int型查询，速度快，并且也进行memcached缓存。

下午吴同学详细讲述了我们的统计系统的负载和数据量，在大量实际应用的基础上，我的方案应该能很好的实施。

这样算来，连接瓶颈跟存储瓶颈似乎都能解决。明天集中时间实现这个方案。

最近一直在寻找一个开源的方案来解决discuz的性能瓶颈。在做完几个关键表的分表后，sessions表又成了最大的瓶颈。因为页面每次刷新，至少两个sql语句在session表上，究其原因，session表的最大作用在于对用户行为的统计。

曾经尝试过使用php的session，不过支持phpsession的几个sever都不支持条件查询，除非是遍历匹配。这样也不能起到提高性能的作用。

在以上条件下，我寻找了两套方案：ttserver mongodb。

在session表100w数据的测试下，得出以下数据：

连接测试-只测试连接释放
tt:40.0904033184
mysqldb:0.0669066905975

mongodb:226.840053558
mysqldb:0.154407262802

经过一万次的连接测试，同一个脚本中，
ttserver连接耗时 40.09 秒，而mysql连接耗时0.07秒 linux下测试
mongodb 连接耗时 226.8 秒，而mysql连接耗时0.15秒 linux下测试

但是在500次的查询测试中，同一个脚本中，主键查询和索引优化后的复杂查询
mongodb 查询耗时 0.021 秒
mysql 查询耗时 0.123 秒

可以看出，tt和mongo两个功能上完全支持此表优化的数据库，在连接性能上远不如mysql，而web为频繁连接中断的服务，显然并不适合做这项功能。

继续寻找支持此功能的开源方案，欢迎大家提供线索。

editplus默认是不支持python开发的，但官方提供了相关的支持：

http://www.editplus.com/dn.cgi?python3.zip

在 菜单->工具选择->语法 中，可以新建语法类型 python,扩展名 py,语法文件为python.stx,自动完成文件为python.acp

即可。

以前用apache，很多虚拟主机的时候，用 mod_vhost_alias 模块去解决。nginx似乎没有这样的功能。

原来为了做这个功能，我用python写了一堆脚本，去自动管理nginx的配置文件，结果还是不理想。频繁重写配置文件，频繁重启，总会出现点问题。

在nginx的0.8.*下，发现了这样的功能：http://wiki.nginx.org/NginxHttpCoreModule

Since nginx 0.8.25 named captures can be used in server_name:
server {
server_name ~^(www\.)?(?.+)$;
location / {
root /sites/$domain;
}
}

大喜，于是乎做出如下配置，实现了nginx下自动虚拟主机的功能：

测试通过。

我的开源虚拟主机管理系统nginx版本指日可待。

新浪微博，就是迷你博客（废话）。我关心的不是博客，是url。里边的url全部使用了一种很短的url，比如 http://sinaurl.cn/**** 这里猜测了这种url的实现意义：

1：减少url所占的字数，优化排版。微博就是一个小，如果我贴了一个地址就占一半的字数，那作者很不爽，读者很不爽，做页面那哥们(MM)肯定跟不爽。所以，咱弄个短的url，岂不皆大欢喜。

2：排挤灌水广告者。众所周知，很多广告者为了广告，或者为了页面优化，得群发垃圾消息增加反向链接数。而短url跳转这种方式根本无法增加反向链接数。也就是这种方式从根本上掐断了垃圾群发者的命根子，这样也就减少了垃圾信息的量，节约了信息审核的人工成本（这项成本随着严打是越来越高啊）。

3：暂时没想出来。

实现，其实很简单，就是接收个id，然后找到对应记录就行。根据新浪信息的量，不可能用mysql的，成本高（负载和硬件消耗）。不可能用oracle，凭我的了解，不可能用。

新浪在小日本那个ttserver的基础上开发了个支持分布式的key->value型的数据库，这玩意正好用上，支持高并发大负载，逻辑简单还支持分布式，这么实现貌似最好不过。

吃饱没事，大半夜写文章。欢迎大家来讨论。