车东[Blog^2]

■70厘米 ■2尺1 ●26英寸
■74厘米 ■2尺2 ●28英寸
■76厘米 ■2尺3 ●29英寸
■78厘米 ■2尺35●30英寸
■80厘米 ■2尺4 ●31英寸
■82厘米 ■2尺45●32英寸
■84厘米 ■2尺5 ●33英寸
■86厘米 ■2尺6 ●34英寸
■88厘米 ■2尺65●35英寸
■90厘米 ■2尺7 ●36英寸
■92厘米 ■2尺75●37英寸
■94厘米 ■2尺8 ●38英寸
■96厘米 ■2尺85●39英寸
■98厘米 ■2尺95●40英寸
■100厘米■3尺 ●41英寸
■102厘米■3尺05●42英寸
■104厘米■3尺1 ●43英寸
■106厘米■3尺2 ●44英寸

按此阅读全文 "腰围2尺1,2,3,4,5,6,7,8寸分别等于是多少厘米/英寸(对照表)" »

面向机器的抓取优化
1 缺省域名唯一化：缺省foobar.com 设置301跳转到 www.foobar.com 一方面减少搜索引擎页面消重的负担，一方面可以将针对相同内容的反向链接权重汇总。对于缺省使用https访问的网站，如果不跳转（比如以前的支付宝），往往还会有浏览器提示安全证书路径不匹配的问题； 另外： 在Google Webmaster tools中也有缺省域名的配置；
2 被遗忘的流量：想办法搜集域名解析失败和拼写错误导致的流量流失；曾经启用过的域名，就尽量不要删除，一直保留并设置转向到最新的地址；有渠道取到DNS的这种记录吗？
3 404页面的运营：返回hard 404(返回http header而不是html 404 header)，统计并跟踪带有referer的404日志，修正这些问题；
4 节省HEAD类请求：对于一些蜘蛛（主要是百度蜘蛛），经常使用head请求来检查旧链接的有效性，启示可以针对这些请求做直接返回304处理，以节省服务器的处理资源；
5 永久转向：避免302，转向尽量使用301到最终地址；
6 重视站内搜索： 利用搜索做内容之间的关联和发现，每篇文章提供相关文章等功能；而能解析出搜索来源关键词的404访问尤其应该通过站内搜索为用户提供其他可选内容。
7 利用google webmaster tools等跟踪收录和错误抓取问题并及时修正；
8 归档页面URL标准化：虽说搜索引擎声称动态页面和静态页面收录和RANK不受影响，但为了方便管理，最好还是将内容页面尽量标准化成静态地址，并页面中尽量加上唯一化的地址，减少搜索引擎抓到相同内容的不同链接后消重的麻烦，比如各种论坛的内页： <link rel="canonical" href="http://www.example.com/discuz/thread-405413-1-2.html" />

面向用户的内容优化
1 自身主动检查spam，防止大量的镜像内容，搜索引擎对于spam处理不利的站点，往往也只好使用整体降权的方式；
2 避免用户因为使用第三方计数器，JS小功能（比如：样式很炫的用户鼠标指针等）被植入病毒木马，Google会向比较严重的站点的webmaster@信箱发送邮件提醒相关问题，所以这个邮箱一定要创建并定期查看；
3 结构化数据源： RSS、sitemaps归档入口，而最高效率的是利用各种ping接口将最新内容即时发送给搜索引擎（最近百度也都支持相应接口和协议了）；
4 重视标题和meta description在搜索结果页上的可读性： meta description不参与排序，但良好的标题和meta description往往比纯算法提示出来的摘要更接近用户目标，在现有排名位置下，争取吸引用户更多的点击也是一个有效的策略；
5 应有的反向链接的获得： 主动加上版权声明；

按此阅读全文 "内容型网站面向搜索引擎蜘蛛和搜索用户的优化" »

日志统计和各种负载监控：
AWStats
全面统计原始日志，分析浏览器和非浏览器的流量，在很多应用中蜘蛛抓取已经超过了浏览器访问； 而搜索引擎的来源也和蜘蛛的遍历有很大的关系； 使用Cacti对服务器的各种指标进行监控，对于系统优化重构后的跟踪也有非常直观的表现，页面YSlow得分，甚至Google Webmaster统计都会比较有用； 进行重构前先进行一些统计和分析工作，在重构后也便于评估和量化重构的效果。

前端优化： Nginx
对照YSlow进行前端优化的主要是：
实现统一的expires配置： 实现客户端的缓存；
解决HTTP压缩： 减少文本的传输；
解决日志问题：更方便的增加针对cookie等字段的记录；
通过代理实现实现负载均衡： 将原有单机应用通过路径规则分布到后台多台应用服务器上而不用增加域名；
解决URL Rewrite等问题：相比IIS自身，nginx的配置都相对简单；

缓存优化：
静态文件缓存服务器：Varnish
分布式应用缓存： Memcached；

epoll推动web发展：在各种服务中都能看到epoll机制的影子；

而各种平台之间的数据交换尽量使用json XML等格式便于未来跨平台调用；

按此阅读全文 "使用开源软件对IIS应用进行重构" »

类型             购买比例    相对平均差异
车载MP3/视听	2.68%	92.8%
数码相机其他配件	2.33%	84.9%
笔记本电脑	3.26%	69.8%
数码摄像机	1.12%	62.3%
GPS配件/车载通讯	7.31%	61.4%
品牌家饰	0.70%	55.6%
GPS	2.07%	54.5%

职业套装/学生校服/工作制服	0.72%	-41.0%
运动装外套	0.51%	-42.0%
热水器/浴霸	0.26%	-42.2%
围巾/丝巾/披肩	0.26%	-42.2%
运动裤/裙	0.27%	-42.6%
胶卷相机	0.27%	-43.8%
女装羽绒服	0.27%	-43.8%
装潢二手/闲置专区	0.27%	-44.9%
文胸套装	0.26%	-46.9%
运动套装	0.34%	-50.7%
装饰画/无框画	0.26%	-52.7%

按此阅读全文 "雅虎统计 chedong.com 读者基于淘宝购物行为的访客网购兴趣分析" »

这里将一些利用Google analytics _trackPageview()进行URL改写实现别名统计的方案样例整理如下：
1 自定义链接改写（rewrite）： 将URL变成可读性更好的地址， 例如：

/index.php ==> 部署 pageTracker._trackPageview('/首页');
/photos/sun_rise.html ==> 部署 pageTracker._trackPageview('/相册/日出');

2 对动态参数网页进行别名统计：Google统计会忽略掉动态网页 ? 后面的参数，但将 /?a=1&b=2 在统计中改写变成 /a/1/b/2 后，就可以通过pageTracker._trackPageview("/a/1/b/2") 后不修改URL也能变相统计出来；

3 结合前台js，cookie信息和后台注册信息和后台程序组合逻辑进行扩展统计：用前端脚本或者后台程序动态生成： pageTracker._trackPageview("参数") 实现更复杂的统计别名
例如：
用户注册天数： pageTracker._trackPageview("/user/age/203days")，用于登录用户的注册时间分布；
分析性别分布： pageTracker._trackPageview("/user/sports/male") 分析每个频道的用户性别比例；
记录用户ID： pageTracker._trackPageview("/username/chedong/channel_a") 导出报表后，结合用户数据库信息，获得每个用户在各个频道的行为特点；
区分referer： 在同一个页面按referer不同分别进行统计：
pageTracker._trackPageview("/reg/from/partener")
pageTracker._trackPageview("/reg/from/baidu")

4 点出统计：通过onclick事件发出一个虚拟URL统计请求，这个机制可以用于统计flash，下载或点击到外站等无法部署统计代码的目标地址；

另外： Google提供的API大部分是部署时的接口/方法，更关心获得报表输出的批量导出API， 据说正在开发中：近期只对Trusted Tester开放，这样就更加方便和其他报表系统/应用集成了；

按此阅读全文 "使用Google analytics的 _trackPageview()对网页进行重新命名统计" »

Eldy赶在新年前把AWStats 6.9发布了： 主要的蜘蛛定义和搜索引擎定义修改以及本站的配置样例我已经打包在这里；AWStats虽然是perl写的，但是基本上要用起来不需要对perl熟悉，主要是配置的修改，并且可以适用于于大部分网站的流量，结合Google Analytic统计作为网站状况的轻量级基础统计解决方案；

相关的更新也已经提交： 欢迎各位补充，争取在下一个版本中发布
AWStats - Patches - 4 items
1569229 Simplified Chinese language file update
1569201 top Chinese browser and robot update
1569151 TOP Chinese local search engines update
2499455 robots.txt: clfmerged log files maybe not start with /
AWStats - Feature Requests - 2 items
2498163 configurable $LIMITFLUSH and increase default value to 50000
706297 IIS timezone:change the timeline instead of change time

完整的diff附后： 包含了awstats.pl本身的2个小修改；
1 针对大量URL：增大$LIMITFLUSH减少临时文件I/O；
2 针对泛域名型应用的修改：使用clfmerge -b合并后的日志无法匹配"GET /robots.txt" (因为被clfmerge拼上域名，变成了 "GET http://foo.example.com/robots.txt")；

按此阅读全文 "AWStats 6.9发布： 补充中文搜索引擎定义和配置样例下载" »

早上收到了一封貌似正常的邮件：

Hello,
Dear Gmail customer
After our free email services we offer you to sing up for our free hosting services.
This service currently is in beta test.
And we choose you to test this services and report us any bug you may find.We give you unlimited webspace on your own domain name you must only change your dns services to ns1.google.com and ns2.google.com and enter your domain name in our special control panel.
Our servers are linux based and we support PHP, SSL (Secure Shell),FTP,Stats,CGI,Perl,Unlimited email address and finaly 500 MySQL Database.

Notice :
Dont sell this invitation code in auction website that may cause we disable your account in the future.

Your invitation code :
http://gmail-application.com/cvw2p99ah7dtV1bFJyacSHUQcdROroysWeaIkkATEXaZUJ7n6wwXjzlyFVEYfJyB74Y66qln8VSP1Njjbp4zW/

Need help ? Hosting-Support@google.com
Google Webhosting Team

为什么是欺诈邮件，whois一下邀请链接的域名就知道了：详情附后，注册人好像在香港，搜索 Hosting-Support@google看，1月份，4月份，8月份都有类似邮件发出；

按此阅读全文 "关于Google FREE Webhosting !的欺诈邮件 200∞" »

年初的时候收藏过一篇关于mysqlreport的报表解读，和内置的show status,和show variables相比mysqlreport输出一个可读性更好的报表；但Sundry MySQL提供的脚本相比mysqlreport更进一步：除了报表还进一步提供了修改建议。安装和使用非常简单：

wget http://www.day32.com/MySQL/tuning-primer.sh
chmod +x tuning-primer.sh
./tuning-primer.sh

[client]
user = USERNAME
password = PASSWORD
socket = /tmp/mysql.sock

样例输出：在终端上按照问题重要程度分别用黄色/红色字符标记问题

-- MYSQL PERFORMANCE TUNING PRIMER --
- By: Matthew Montgomery -

MySQL Version 5.0.45 i686

Uptime = 19 days 8 hrs 32 min 54 sec
Avg. qps = 0
Total Questions = 264260
Threads Connected = 1

Server has been running for over 48hrs.
It should be safe to follow these recommendations

To find out more information on how each of these
runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html
Visit http://www.mysql.com/products/enterprise/advisors.html
for info about MySQL's Enterprise Monitoring and Advisory Service

SLOW QUERIES
The slow query log is NOT enabled.
Current long_query_time = 10 sec.
You have 0 out of 264274 that take longer than 10 sec. to complete
Your long_query_time may be too high, I typically set this under 5 sec.

BINARY UPDATE LOG
The binary update log is NOT enabled.
You will not be able to do point in time recovery
See http://dev.mysql.com/doc/refman/5.0/en/point-in-time-recovery.html

WORKER THREADS
Current thread_cache_size = 0
Current threads_cached = 0
Current threads_per_sec = 1
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 100
Current threads_connected = 1
Historic max_used_connections = 33
The number of used connections is 33% of the configured maximum.
Your max_connections variable seems to be fine.

MEMORY USAGE
Max Memory Ever Allocated : 96 M
Configured Max Per-thread Buffers : 268 M
Configured Max Global Buffers : 7 M
Configured Max Memory Limit : 276 M
Physical Memory : 1.97 G
Max memory limit seem to be within acceptable norms

KEY BUFFER
Current MyISAM index space = 8 M
Current key_buffer_size = 7 M
Key cache miss rate is 1 : 1817
Key buffer fill ratio = 6.00 %
Your key_buffer_size seems to be too high.
Perhaps you can use these resources elsewhere

QUERY CACHE
Query cache is supported but not enabled
Perhaps you should set the query_cache_size

SORT OPERATIONS
Current sort_buffer_size = 2 M
Current read_rnd_buffer_size = 256 K
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 132.00 K
You have had 0 queries where a join could not use an index properly
Your joins seem to be using indexes properly

OPEN FILES LIMIT
Current open_files_limit = 1024 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
Your open_files_limit value seems to be fine

TABLE CACHE
Current table_cache value = 64 tables
You have a total of 125 tables
You have 64 open tables.
Current table_cache hit rate is 9%, while 100% of your table cache is in use
You should probably increase your table_cache

TEMP TABLES
Current max_heap_table_size = 16 M
Current tmp_table_size = 32 M
Of 564 temp tables, 6% were created on disk
Effective in-memory tmp_table_size is limited to max_heap_table_size.
Created disk tmp tables ratio seems fine

TABLE SCANS
Current read_buffer_size = 128 K
Current table scan ratio = 1 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 0 : 264392
Your table locking seems to be fine

更有用是作者总结的处理MySQL性能问题处理的优先级：尤其是头3条，基本上可以解决大部分瓶颈问题的原因。
# Slow Query Log 慢查询 尤其是like操作，性能杀手，轻易不要使用，让全文索引交给Lucene或者利用Tag机制减少like操作；
# Max Connections 并发连接数：一个MySQL deamon缺省最大连接数是100，调到更高只是为了出现问题是给我们更多的缓冲时间而不是任其一直处于那么高的状态，并发连接数类似于等候大厅：当等候人数过多的时候，一味扩大等候厅不是根本解决问题的办法，提高业务的处理速度，多开几个窗口才是更好的解决方法；我的经验就是超过100： 数据就要想办法（镜像或者分片）分布到更多Deamon上；
# Worker Threads： Jeremy Zawondy 曾在部落格上說到：Thread caching 並不是我們最需要關心的問題，但當你解決了所有其他更嚴重的問題之後，它就會是最嚴重的問題。(thread caching really wasn't the worst of our problems. But it became the worst after we had fixed all the bigger ones.)
# Key Buffer
# Query Cache
# Sort Buffer
# Joins
# Temp Tables 临时表
# Table (Open & Definition) Cache 表缓存；
# Table Locking 表锁定
# Table Scans (read_buffer)
# Innodb Status

按此阅读全文 "MySQL的性能调优工具：比mysqlreport更方便的tuning-primer.sh " »

图片服务的特点就是：不修改，少量新增/极少删除，存储量大，需要尽量避免迁移和复制；旧的集群锁定后：对于原来的文件基本上就只删不增了；虽然目前有很多开源的分布式文件系统，但是目前比较便宜的解决方法还是本地硬盘服务器不断一组一组的增加，相互备份的一组服务器作为基础存储，然后前端使用缓存服务器；通过LVS或者CDN进行负载/分布的均衡。

目前一台服务器配上T的存储也相对比较便宜；关键是如何尽量避免使用NFS进行使用；目前我们选择的办法是：图片服务器一组使用2台，一组服务器之间使用NFS相互mount用于备份；另外有上传文件服务器会NFS访问；对外服务文件使用Web服务器负载均衡。而在2台服务器上，会给予基于ID将用户的图片进行存储，存储的分布化会遇到一个问题：固定存储空间随着时间增加再次达到系统的空间/负载的瓶颈。观察了一下Flickr的图片存储地址：好像是在定期启用新的集群，各个时期的域名分布如下：

http://farm1.static.flickr.com 2006年中以前；
http://farm2.static.flickr.com 2006年底；
http://farm3.static.flickr.com 2007年底；
http://farm4.static.flickr.com 2008年底；

user_foo - farm1.static....../20060124_003.jpg
\ farm1.static....../20060324_005.jpg
\ farm1.static....../20060824_021.jpg
\ farm2.static....../20070124_006.jpg
\ farm3.static....../20080124_002.jpg
\ farm4.static....../20081124_001.jpg

另外如果希望前端存储使用的域名一直保持不变，通过目录规则进行rewrite的方式也是可以的，比如：将要发布的内容，后端按时间建立一个域名进行存储；

200711.foo.example.com
200712.foo.example.com
200801.foo.example.com
...
200811.foo.example.com

foo.example.com/200711/ >> 200711.foo.example.com
foo.example.com/200712/ >> 200712.foo.example.com
...
foo.example.com/200811/ >> 200811.foo.example.com

这样就简单的实现了图片存储随时间增加而扩展的，每隔一定时间将上传服务器指向到新的服务器集群；

按此阅读全文 "图片存储：随时间增加新域名进行扩容的办法" »

Phase 2 : Now process new records (Flush history on disk after 20000 hosts)...
Flush history file on disk (unique url reach flush limit of 5000)
Flush history file on disk (unique url reach flush limit of 5000)
Flush history file on disk (unique url reach flush limit of 5000)
是AWStats统计常见的输出，每行都是在处理完一定数量的URL(缺省是5000个)后，AWStats将统计结果临时写入磁盘。最近使用AWStats处理百M级别的日志时：磁盘IO居然非常高，
发现有时候遇到页面URL个数非常多的时候（比如：在搜索引擎蜘蛛对网站进行深度遍历deep crawl时），经常会使得AWStats对缓存文件的读写过于频繁，随着生成的数据文件越来越大，每次几百M的临时文件读写也会导致统计速度越来越慢；经常一次统计数据下来会Flush history file on disk (unique url reach flush limit of 5000) 几百次；

记得以前是对AWStats进行过简单的参数配置的，可以修改flush的周期，但现在的文档中没有找到相应的配置，只好Hack了一下：awstats.pl文件将每隔发现5千个新链接改为5万个；

> $LIMITFLUSH=5000; # Nb of records in data arrays after how we need to flush data on disk
---
< $LIMITFLUSH=50000; # Nb of records in data arrays after how we need to flush data on disk

按此阅读全文 "增大AWStats的$LIMITFLUSH，减少磁盘临时文件读写 Flush history file on disk (unique url reach flush limit of 5000)" »