22:38 基于AWStats的统计扩展 JAWStats Web Site Statistics & Analytics | An AWStats Companion » Delicious/chedong
增加了不少awstats本身缺乏的汇总，报表等功能。JAWStats is a free, open-source website statistics and analytics package. It runs in conjunction with AWStats and produces clear and informative charts, graphs and tables about your website visitors.
13:34 Fix of InnoDB/XtraDB scalability of rollback segment » MySQL Performance Blog

Recently I wrote about InnoDB scalability on 24-core box, and we made research of scalability problems in sysbench write workload (benchmark emulates intensive insert/delete queries). By our results the problem is in concurrency on rollback segment, which by default is single and all transactions are serialized accessing to segment.
Fortunately InnoDB internally has mechanism to support multiple rollback segments - and Yasufumi just made patch to enable it.

I rerun benchmarks on different server (Dell PowerEdge R900, 16-way Intel Xeon, 32GB of RAM, RAID 10 on 8 disks) to compare mysql-5.1.30-XtraDB-1.0.2-pre-release3 with default (1) and 16 rollback segments.

For reference
MySQL parameters:

PLAIN TEXT
CODE:
  1. [mysqld]
  2. #mysqld options in alphabetical order
  3. user=root
  4.  
  5. default_table_type=MYISAM
  6.  
  7. innodb_buffer_pool_size=6G
  8. innodb_data_file_path=ibdata1:10M:autoextend
  9. innodb_file_per_table=1
  10. innodb_flush_log_at_trx_commit=2
  11. innodb_log_buffer_size=8M
  12. innodb_log_files_in_group=2
  13. innodb_log_file_size=128M
  14. innodb_thread_concurrency=0
  15.  
  16. innodb_extra_rsegments=16
  17.  
  18. max_connections=3000
  19. query_cache_size=0
  20. skip-name-resolve
  21.  
  22. table_cache=2048

sysbench parameters

PLAIN TEXT
CODE:
  1. /data/vadim/benchwork/benchmarks/sysbench/bin/sysbench --num-threads 1 --max-requests 0 --max-time 300 --thread-stack-size 32K --init-rng on --validate off --test oltp --oltp-test-mode complex --oltp-sp-name  --oltp-read-only off --oltp-skip-trx off --oltp-range-size  --oltp-point-selects  --oltp-simple-ranges  --oltp-sum-ranges  --oltp-order-ranges  --oltp-distinct-ranges  --oltp-index-updates  --oltp-non-index-updates  --oltp-nontrx-mode select --oltp-auto-inc off --oltp-connect-delay 10000 --oltp-user-delay-min 0 --oltp-user-delay-max 0 --oltp-table-name sbtest --oltp-table-size 10000000 --oltp-dist-type uniform --oltp-dist-pct  --oltp-dist-res  --db-ps-mode auto --mysql-host localhost --mysql-port 3306 --mysql-socket /data/vadim/benchwork/var/mysql_benchwork.sock --mysql-user user --mysql-password  --mysql-db sbtest --mysql-table-engine innodb --myisam-max-rows 1000000 run

Entry posted by Vadim | 2 comments

Add to: delicious | digg | reddit | netscape | Google Bookmarks

Memcached的代理服务器软件：magent使用小记[原创]回忆未来[张宴] » 车东's shared items in Google Reader
　　magent是一款开源的Memcached代理服务器软件，其项目网址为：

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

　　一、安装步骤：
　　1、编译安装libevent：
wget http://monkey.org/~provos/libevent-1.4.9-stable.tar.gz
tar zxvf libevent-1.4.9-stable.tar.gz
cd libevent-1.4.9-stable/
./configure --prefix=/usr
make && make install
cd ../


　　2、编译安装Memcached：
wget http://danga.com/memcached/dist/memcached-1.2.6.tar.gz
tar zxvf memcached-1.2.6.tar.gz
cd memcached-1.2.6/
./configure --with-libevent=/usr
make && make install
cd ../


　　3、编译安装magent：
mkdir magent
cd magent/
wget http://memagent.googlecode.com/files/magent-0.5.tar.gz
tar zxvf magent-0.5.tar.gz
/sbin/ldconfig
sed -i "s#LIBS = -levent#LIBS = -levent -lm#g" Makefile
make
cp magent /usr/bin/magent
cd ../



　　二、使用实例：
memcached -m 1 -u root -d -l 127.0.0.1 -p 11211
memcached -m 1 -u root -d -l 127.0.0.1 -p 11212
memcached -m 1 -u root -d -l 127.0.0.1 -p 11213
magent -u root -n 51200 -l 127.0.0.1 -p 12000 -s 127.0.0.1:11211 -s 127.0.0.1:11212 -b 127.0.0.1:11213

　　1、分别在11211、11212、11213端口启动3个Memcached进程，在12000端口开启magent代理程序；
　　2、11211、11212端口为主Memcached，11213端口为备份Memcached；
　　3、连接上12000的magent，set key1和set key2，根据哈希算法，key1被写入11212和11213端口的Memcached，key2被写入11212和11213端口的Memcached；
　　4、当11211、11212端口的Memcached死掉，连接到12000端口的magent取数据，数据会从11213端口的Memcached取出；
　　5、当11211、11212端口的Memcached重启复活，连接到12000端口，magent会从11211或11212端口的Memcached取数据，由于这两台Memcached重启后无数据，因此magent取得的将是空值，尽管11213端口的Memcached还有数据（此问题尚待改进）。


　　三、整个测试流程：
[root@centos52 ~]# telnet 127.0.0.1 12000
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
stats
memcached agent v0.4
matrix 1 -> 127.0.0.1:11211, pool size 0
matrix 2 -> 127.0.0.1:11212, pool size 0
END
set key1 0 0 8
zhangyan
STORED
set key2 0 0 8
zhangyan
STORED
quit
Connection closed by foreign host.


[root@centos52 ~]# telnet 127.0.0.1 11211
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
get key1
END
get key2
VALUE key2 0 8
zhangyan
END
quit
Connection closed by foreign host.


[root@centos52 ~]# telnet 127.0.0.1 11212
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
get key1
VALUE key1 0 8
zhangyan
END
get key2
END
quit
Connection closed by foreign host.


[root@centos52 ~]# telnet 127.0.0.1 11213
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
get key1
VALUE key1 0 8
zhangyan
END
get key2
VALUE key2 0 8
zhangyan
END
quit
Connection closed by foreign host.


模拟11211、11212端口的Memcached死掉
[root@centos52 ~]# ps -ef | grep memcached
root      6589     1  0 01:25 ?        00:00:00 memcached -m 1 -u root -d -l 127.0.0.1 -p 11211
root      6591     1  0 01:25 ?        00:00:00 memcached -m 1 -u root -d -l 127.0.0.1 -p 11212
root      6593     1  0 01:25 ?        00:00:00 memcached -m 1 -u root -d -l 127.0.0.1 -p 11213
root      6609  6509  0 01:44 pts/0    00:00:00 grep memcached
[root@centos52 ~]# kill -9 6589
[root@centos52 ~]# kill -9 6591
[root@centos52 ~]# telnet 127.0.0.1 12000
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
get key1
VALUE key1 0 8
zhangyan
END
get key2
VALUE key2 0 8
zhangyan
END
quit
Connection closed by foreign host.


模拟11211、11212端口的Memcached重启复活
[root@centos52 ~]# memcached -m 1 -u root -d -l 127.0.0.1 -p 11211
[root@centos52 ~]# memcached -m 1 -u root -d -l 127.0.0.1 -p 11212
[root@centos52 ~]# telnet 127.0.0.1 12000
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
get key1
END
get key2
END
quit
Connection closed by foreign host.


Tags - , ,
加速你的工作-介绍GTDXiaoxiao's Weblog » 车东's shared items in Google Reader

index

　　上周分享的一个PPT，介绍了GTD系统和自己应用的一些心得体会。下面是几张重要的Slide，放出来分享学习下。有很多网站和论坛都在讲GTD，感觉太复杂了，用我们这行的话说就是可用性不好。（本篇所有的图片和资料都来自于网上，记不清出处，有版权问题请直接留言。）

　　GTD就是Get Thing Done的缩写，翻译过来就是“尽管去做”。GTD的核心理念说白点儿，就是你必须记录下来你要做的事，然后整理安排自己一一去执行就OK了。

　　一、第一张Slide有四条GTD的好处，简单而言就是可以帮助你更合理更高效的完成工作。

　　对于第四点，我似乎还没看到，但对于自己的工作是很相当清晰了。也可能和我应用GTD系统时间长短有关，我大约用了八个月左右。

 

　　二、接着看一下GTD的工作流。这里主要是记住工作流，然后严格按这个工作流来处理你手头上的工作。

gtd_flow

　　我一直感觉老外很笨，但人家最牛的地方就是把经验上升为理论，然后很撤底的执行，不断的优化。这里有另外一张工作流，点此查看。

 

　　三、下面一张Slide讲的是GTD的五个核心原则：收集、整理、组织、回顾、执行。OK，记住这五个原则的先后顺序就可以了。

gtd_princple

　　很简单吧，最重要的是：执行。另外借用老大的一个词“集中精神”，结合在一起就是：集中精神执行。

 

　　四、下面的Slide是收集的流程。把所有的事情从你的脑子里记录清出来，记录在一个可以看到的地方。GTD认为大脑是应该去思考如何去做一件事，而并不是用来存储N多个事。

collect_flow

　　我的一些经验：在纸上或其它设备里记录下的任务或工作时，应该注意安排优先级，比如你今天重点的工作是画一个视觉设计，那么其它的工作就要安排在次要的位置，集中精力去做今天最重要的事情。另外，如果一天重要的事情在上午做完了，就应该重新回顾，列出下午最重要的工作，然后其它的事情靠后。

　　记录也有技巧，涉及到记录的工具和线上和线下两种情况。我的处理方式是线上能提醒的是Outlook的任务和日历，比如几点要找谁谁打个打电话，几点要发某某邮件，几点去开会。

　　线下的工具是纸笔和手机，我一般是记录每天所有的工作，我用的本本是“是日”，一是这个本本是广州一家设计团队做的，相当有感觉，特别是“是日”的名字，相当有个性；二是“是日”的扩展性，正面可以按时间记待办的工作，背面可以写写总结什么的，淘宝这里有卖。

 

　　这个是官方给出的正面照片。

　　日历同步方式我同时使用两种：一是Google日历和Outlook同步，我使用Google Calendar Sync，在办公机上自动同步到Google日历上去，在任何地方，在我的几台电脑中都可以看到我的日历。

　　另外是Iphone日历和Google日历同步，同步工具是NemusSync。想查看的时候工作Outlook日历的时候，点一下，很完美。手机上我用的是广东06前五元包月100M的GPRS服务，我不觉得Wifi那么快有什么特别的优势，像我，每天除了上下班，使用iphone上网的时候也就在班车的时候，顶多也就一个小时吧，所以、查看天气、股票、看看订阅文章、同步日历基本上是我的操作。换句话说50M的包月也够了。

　　下面这几张图是Things软件的截屏，Iphone上的一个GTD软件，虽然他有很漂亮的原型手绘稿，我试用过后不如Todo这款软件，后来放弃了。有喜欢的可以去下载个试试。things

 　　五、“处理（整理）”，英文原意是Process。我提取了三点重要的内容：

　　不能不提一下处理的两分钟原则。我想更细的是：1秒+2分钟原则，对突然打断的事情，一秒钟评估，两分钟内能解决，无论是任何事情，马上着手解决掉。如果不能在两分钟内解决，就进行下一步处理。这里坚决不能拖，一件事一件事的来，一心别二用，两分钟处理完一件事，马上回到你的主要事情上来。

2min_princeple

 

　　六、“组织”应该是最关键的一点。“组织”主要分成对备份资料的组织与对下一步行动的组织。

　　备份资料来自于对任务可行动的处理结果。对备份信息的组织主要就是一个文档管理系统，可用很多工具去存档这些资料，我以前用网文快捕，现在发现Onenote也不错，因为公司都是Office办公，所以后来家里和公司的系统上全都装上了Onenote。

　　下一步行动的组织则一般可分为：等待处理清单、将来处理清单、下一步行动清单。

　　1. 等待处理清单主要是记录那些委派他人去做的工作，比如有个邮件问你这件事有谁负责，你可转交处理，如果你是主管，可安排下属去做。

　　2. 将来处理清单则是记录延迟处理且没有具体的完成日期的未来计划等等。

　　3. 下一步处理清单则是具体的下一步工作。而且如果一个任务涉及到多步骤的工作，那么需要将其细化成具体的项目。老外认为不能在两分钟钟内完成的、需要一系列动作来进行的任务叫作“项目”。

　　有很多朋友把Outlook建了@todo，@waiting，@next三个文件夹，我在Gmail上尝试过GTDinbox，后来因为大部份的事情在公司Outlook中，还是转移了。

 

 　　七、“回顾”和“执行”

　　我对回顾的理解是PDCA循环的一种方式，目前是每日回顾、每周回顾一次，对自己的工作和其它事情进行回顾，看看哪里做的不好，需要改进。

　　“执行”就不用说了吧，马上做就OK了。

 

　　八、一些资源和Tips。

 tips

http://www.gtdlife.cn
http://groups.google.com/group/gtdlife?hl=zh-CN
http://www.mifengtd.cn/articles/category/gtd
http://cngtd.com/
http://www.moleskiner.cn

其它的一些资源，也是转载的，不知道出处是哪里了。要详细了解的，可以看下面这些内容，但愿各位能在这个分享中提高自己，也欢迎和我交流，最好用邮箱：xiaoxiao@vip.qq.com。

GTD综述和介绍：
GTD知识深入：
GTD资源下载：
GTD工具介绍（软件）：
GTD移动工具（PDA）：
非电子类GTD工具：
GTD应用延伸：
简单做（ZTD）系列：

Copyright © 2002 - 2008 Blog.xiaoxiao.com.cn
本站所有日志采用知识共享: 署名-非商业性使用-禁止演绎 2.5 中国大陆许可协议进行许可
Wiki的神话与现实internet.solidot.org » 车东's shared items in Google Reader

Wiki的神话与现实

matrix 发表于 2009年1月18日 08时50分 星期日   Printer-friendly   Email story
来自修改和复原部门
评论 互联网
COMSHARP CMS 写道 "诞生于10前的Wiki技术正受到越来越多的欢迎，而许多公司正怀着一种不切实际的期望启动他们的Wiki项目。然而近期的一些报告，如， CMS Watch 的企业社会软件报告，以及企业中的 Wiki，都显示了 Wiki 项目之痛。对于 Wiki，夸夸其谈的项目主管们抱有多种神话心态，而现实却是另外一回事。本文是著名 CMS 研究机构 CMS Watch 发表的一篇关于企业Wiki的文章。"
Wiki 的三个神话
  1. Wiki 会推动员工自觉地贡献信息。
  2. 员工凭直觉就能使用 Wiki 工具。
  3. Wiki 会让信息的管理变得简单明了。
然而现实中，Wiki 虽然确实拥有不小的价值，但象所有信息技术一样，你需要抱着批评的眼光来看待这种技术。

神话 #1: Wiki 将推动员工对信息的贡献

关于 Wiki 一个古老的神话就是，Wiki 技术会推动员工对信息的贡献。很多企业认为，Wiki 会推动员工贡献内容和意见的积极性。看看 Wikipedia ，那些志愿者撰写了700万篇文章，当内容提供者可以自己决定什么可以写，什么不可以写的时候，他们就有了动力。

然而，很多公司的 Wiki 项目总是稍纵即逝，最终只剩下空荡荡的页面，这种情形往往来自那些没有明确目标的 Wiki 项目，这些项目并不知道其服务的对象与原因，或者因为什么都想做而变得空泛。

另一个典型的障碍是文化。信息的自由发布对一些组织化的管理文化来讲并不受欢迎，另外还会引发对内容质量的担忧，就是说，Wiki 中的一些信息可能是错误的。组织化的管理认为，那些一经发布的信息，都应该是权威的，完整的，有良好的文档。而 Wiki 却是边做边说，如果管理方不愿同这种文化对话，同时，员工又特别乐于提交那些未完成的内容时，Wiki 成功的几率就很小了。

象所有信息系统一样，Wiki 必须对员工的日常工作带来帮助，而不是定位于一个没有差错的信息档案系统。多数成功的 Wiki 项目都有明确的目标，而不是为 Wiki 而 Wiki，它们是围绕着信息的协同作业。

在这个基本前提之上，你还要通过各种方式鼓励内容的贡献。首先，不要推出一个空的 Wiki，里面要事先放一些基本内容，如样例内容或基本的信息结构。要将 Wiki 同其它企业工具集成，比如，在公司的 Intranet 上对你们的 Wiki 提供链接，让更多人知道它的存在。记住，没有相应的推动，Wiki 不会自己成长。

另外，高度成功的 Wiki 项目经常是那些熟知IT的人推动的，他们对这种技术有一定的了解与经验，或者他们曾在 Wikipedia 写过文章。在向非技术人员介绍 Wiki 时，可能面临着挑战，因为 Wiki 要求一种新的，不熟悉的个工作方式，而且这些系统的易用性常常是个很大的问题。

神话 #2: 员工都知道如何使用 Wiki

很多公司指望他们的员工立即投入到 Wiki 技术中，Wiki 的概念非常简单是否意味着它同样易于使用？

然而，事实上，Wiki 要求以一种新的方式对待内容与结构。那些熟悉 Wiki 的人往往并不知道普通人对 Wiki 的不解。比如，在 Wiki 中，链接以前的内容，在创建新页之前，你需要首先考虑可以从哪些页链接出来，这看上去是个小细节，然而对编辑者来说这是一种新的视角，需要实践。Wiki 的力量在于其自下而上的，基于链接的天性，然而要实现其全部价值，必须从一开始就坚持这种思路。你需要提供一些指引让用户全面用好链接以消除内容的冗余。

另外，多数 Wiki 系统的界面并不是那么用户友好。很多 Wiki 使用专用的置标语言（如 *text* 代表黑体， _text_ 代表斜体），而不是在其它在线出版系统（如 CMS 网站内容管理系统）中已经非常普遍的富内容编辑器。同时，不同的 Wiki 系统可能使用不同的置标语言，这些语言更适合小众的技术人群而非企业用户。因此，技术培训是必需的。

然而，即使是那些熟练的 Wiki 作者，在你的企业环境中，也需要培训，他们或许知道基本的概念，却对一些有用的功能知之甚少，如新内容的邮件提醒功能，版本回溯功能，以及离线工作模式。（ CMS Watch 的企业社会软件报告的读者知道并不是所有 Wiki 系统都支持这些功能）

神话 #3: Wiki 会让你随时找到需要的信息

很多 Wiki 的推广者认为，Wiki 的灵活性可以保证那些最新的，最需要的信息总能被轻易发现，因为员工随时都在更新内容。

事实上，这些企业很快会发现，对 Wiki 的重度依赖将导致内容的增长失去控制。当整个结构陷入混乱，在堆积如山的内容中查找信息如同大海捞针一样。如果每一个新页都需要一个不一样的名字，你如何查找有意义的名字；当发布一个新页比查找一个旧页更简单的时候，你如何避免信息的爆炸。

这还不算，在多数 Wiki 系统中，搜索功能都很弱。搜索结果经常首先显示那些最新改动过的内容，如果你想找一些新东西，这可能有用，但在成千上万的搜索结果中，这没有多少用处。

如果你不事先规划并制定指引，Wiki 最终会不堪重负，信息过载与有限容量之间的鸿沟会给企业带来风险，意味着人们越来越难发现信息，或者信息越来越膨胀。

要实现一个实用的 Wiki，你需要专门的努力。你需要指定几个 Wiki 经理或管理员，他们定期检查内容的质量。另外，还需要向用户提供帮助和最佳实践，如怎样创建和维护结构，如何大量使用链接。除此之外，还需要一些简单的指引，帮助用户维护内容，链接，结构。尽管 Wiki 为了保持灵活而不强制使用模板，但开发一些模板指引还是有用的，如，在每页的顶部放一个 TOC 目录，让用户知道这页的主要内容与结构。

Wiki 的现实

Wiki 是一种灵活地创建与分享信息的方法，然而灵活与简单并不能证明 Wiki 的成功。简单还可能给你带来更大的挑战，尽管短期可以获得成效，然而长期来看，有可能导致过度膨胀而失去控制。

因此，尽管 Wiki 是非传统的工具，然而那些传统的技术神话依然会对 Wiki 带来厄运，在开展 Wiki 之前需要仔细规划，保证管理者知道你们有多少资源，尤其是人力资源。最终，你的企业文化可能成为成败的关键，一个鼓励开放式沟通，注重实践的领导者将成为一个成功的 Wiki 项目的基石。

本文国际来源：http://www.cmswatch.com/Feature/190-Wiki-Myths?source=RSS
中文翻译来源：COMSHARP CMS 官方网站（35公里译）

^==Back Home: www.chedong.com

^==Back Digest Home: www.chedong.com/digest/

<== 2009-01-17
  一月 2009  
一 二 三 四 五 六 日
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
==> 2009-01-19