今天与某中等规模app开发者交流。有所收获。
对方的设计参考“开心农场”，用户库和应用库独立,基于Uid做hash.数据库只做定期数据归档,数据的实际读写操作都在memcache进行,memcache中维护一张1分钟变更数据key值的大表,由定时脚本,一分钟从memcache中获得一次变更key值，然后将数据从memcache更新到数据库。
开发者很明确的说:SNS app经常是读多,写更多。
确实是，我们现在的app,读写比例4:1,但是写确实很频繁,10个用户库,每个库每秒50,60的写。按照这个模式，单纯使用mysql最终只能走上拼服务器数量的道路，之前建议开发

昨晚在机房大干一场,装服务器。
装完后和老服务器对比发现有不少差别。
老服务器是REDHAT4,新服务器是CentOS5.4.
新装的服务器前端机cpu load average都不低,php每个cgi进程都要30%,load average 3,而同样配置的老服务器load average 0.5。
对比发现新服务器没装eaccelerator，抱着试一试的态度装了一台，对比发现cpu和load average马上降低到合理数值。

现在还有个问题在解决，老服务器netstat看端口 连接关闭都很快，新服务器存在大量time_wait，但是nginx php的keepalive timeout配置都一样，sysctl.conf也

上次有个任意地区ping你的服务器，今要查网络发现还有个traceroute的网站。
太方便了，方便你了解世界各地到你服务器经过的路由。

http://www.traceroute.org/

www.just-ping.com
这工具不错,尤其是你的服务是提供全球用户的话~~特别是放在国外的服务器。
用它,输入一个网址或IP，就会列出全世界各地PING你的机器的速度,丢包等情况，相当COOL的服务。

如果404页面的容量小于512字节的话，IE 和chrome会使用默认的404页面，而不使用你自定义的~~ff到是没问题。。。。

真恶心,产品人员对如何让一个简单的页面增加几百字节容量很不关心，我只好在404页面里，加了些注释，本来打算写:fuck ie fuck chrome fuck 404~~考虑的公司形象问题,只好复制了产品名称100遍~~~~~

最近一直在和朋友搞一个小网站玩玩,昨天夜里网站刚上线,然后向BAIDU,GOOGLE,YAHOO,MSN提交了网站地址收录,今查看access log,百度是第一个过来抓取的,百度的Spider在提交3个小时后就来抓了,速度很快。不知道多久会收录到索引里。

前阵子优化公司的网站,学会了不少SEO技巧,总的原则就是:不要为了SEO而SEO，不要为了做垃圾站而垃圾站。百度的机器人会分析你的页面,如果你的页面的构成就很类似垃圾站的结构，那很有可能会降低你页面的质量。
比如:关键词过多,连接过多,有意义内容过少,页面相似度高。这四个部分网上很多SEO的基

办法就是,FLASH设置为最底层,加背景透明,上面增加一个透明图片浮层,浮层加连接
<div style="position:relative;">
    <div style="position:absolute; top:0; left:0; width:240px; height:180px; z-index:99;"><a href="http://www.sina.com.cn" target="_blank"><img src="space.gif" width="240" height="180" /></a></div>
    <div style="z-index:-1;"

freebsd下我使用的是diablo-jdk。
先在/usr/port/java/diablo-jdk16 make install会提示我去哪里下载对应的diablo-jdk版本已经对应的其他补丁包，把下载的包放在/usr/port/distfiles/下，在执行make install安装

设置JAVA_HOME
vi ~/.cshrc 增加“setenv JAVA_HOME       /usr/local/diablo-jdk1.6.0”

port安装tomcat6

按照如下转载的方法调试nutch运转，在执行nutch时，需要使用/bin/sh nutch，否则会提示Command not found.

下载nutch0.9

从昨晚8点某新产品上线后,陆续出现多次nginx 504错误，开始第一次没有注意重启nginx恢复，今早7点再次出现，11点第三次出现,觉得灵异了,与系统管理员高手一起查原因，系统管理员说流量大,以为是用户请求高，因为头天上线过新功能于是联系兄弟们查查新上的程序有没有远程调用的，两手准备,管理员在往负载POOL里加新机器，一边查查程序是否有远程调用导致504。

程序查了查也没什么异常的,后来某兄弟突然说昨天上的FLASH尺寸有点大,以前是30k现在增加到了600K，于是赶紧问系统管理员是出站流量大,还是入站流量大,结果果然是

今早听朋友说某大部服务全部瘫痪，由于一个机房突然莫名的断电。
其他产品我到不担心，断电在恢复呗，天灾人祸谁也挡不住，但是我担心BLOG服务，因为BLOG服务压力太大，做了静态化和读写分离后只是指标，一旦出现缓存全失效的情况就会出现泄洪情况，数据库抗不主请求压力，又会陆续OVER。这样的情况一旦出现就会持续很久，至少要到高峰过去，缓存逐渐恢复。

数据库的独立静态缓存还是很必要的，需要一个中间层。数据库的分发和多机房部署也很重要啊。