易栈网-膘叔（Neatstudio.COM）

易栈网-膘叔

ucapi手册

清除广告代码，为更换博客系统做准备

google notebook。。。

践行极简风格

NFS,Memcached,Tokyo tyrant实现session共享性能测试

ucapi手册

清除广告代码，为更换博客系统做准备

google notebook。。。

践行极简风格

NFS,Memcached,Tokyo tyrant实现session共享性能测试

日志分类

热门标签

日志归档

搜索文章

最新评论

博客信息

友情链接

浏览模式: 标准 | 列表2024年11月的文章

Submitted by gouki on 2009, September 2, 10:26 AM

搜索ucenter的手册时，发现了ucapi.com网站，上面已经有一些内容了，什么使用手册，官方API，官方例程之类的。
以前下载的都是离线版的chm文件，经常会在硬盘里找不到。现在有一个在线版的。方便很多。查起来也很容易

呵呵。也算是推荐一下了。。
如果是用comsenz系统的人，估计都会用到ucenter吧。那么ucapi这样的东西就必须要看了

Tags: ucenter, api, ucapi

PHP | 评论:1 | 阅读:21557

Submitted by gouki on 2009, September 1, 10:05 AM

清除广告代码，为更换博客系统做准备

sablog确实不错。但我的资源耗费相对来说其实并不厉害。所以我想更换到wordpress看看。
当然，等手头的任务完成后换。

当然，可能会象帕兰映像那样，开始搞WP模版并出售（不是我搞，我只提供一个展示的平台）

更改的另一个原因是，我现在的分类有点乱，有些文章我都不知道放在哪个分类下面，改版时我要仔细规划一下。

Misc | 评论:3 | 阅读:17850

Submitted by gouki on 2009, September 1, 9:50 AM

在很久前，google notebook还是我有点喜欢的一个小功能，方便（有点方便啦）。然而等到ff升级到3。5后就再不支持了。
郁闷啊。

网上也看了很多文章，都是说要改xpi文件里的内容，他们是这么说的：

Firefox 3.5 中使用Google NoteBook插件

首先下载google-notebook.xpi插件包
wget http://dl.google.com/firefox/google-notebook.xpi
将其解压，编辑install.rdf文件
修改第14行 <em:maxVersion>3.0.*</em:maxVersion>
将版本号3.0.*改为3.5.*甚至3.6.*
然后保存，再进行打包，将其重命名为google-notebook.xpi
再在Firefox中打开文件中选中打包后的google-notebook.xpi,接下来的事情就同正常的安装插件一样步骤了
2009.7.11号更新：如上方法最为简便的就是直接用解压缩程序打开然后再双击install.rdf选用记事本(windows)或者gedit(Linux)打开，编辑完成后保存关闭，此时解压缩程序检测到源文件改变自然会提示是否更新，选择是即可。但在Linux下可能需要解决权限问题方可采用此法（此方法可行性较小，建议直接解压）
2009年8月10号更新：当前Google貌似修改了原xpi文件，进行了一些检测机制，所以在打包之前记得将 META-INF 文件夹删除

还有人说，直接安装Nightly Tester Tools就可以了，因为这个插件可以帮忙强制安装。下载地址为： https://addons.mozilla.org/en-US/firefox/addon/6543

试试吧？

旁注：原来，NTT就是可以自定义一些FF的属性，比如版本号啥的。这样可以让插件以为你现在的平台是3.0以前，所以就能够安装了。。。果然狠

Tags: notebook

Software | 评论:1 | 阅读:21251

Submitted by gouki on 2009, September 1, 7:26 AM

原文链接，作者：谭佳理。

本文from apple4us by Oliver.C,来源地址为:http://apple4.us/2009/08/practicing-product-minimalism.html

六年以前，我曾于微软赴任项目经理一职。工作伊始即与上司有一场单独谈话，末了，她问我是否还有疑问。我答：有的，吾等何日方可削减产品中无必要之功能。

她顿陷入惶惑之中，想必这样的问题此前从未有人提及，也从未有人关心，所以不知如何作答罢。

我知其不解，便进一步阐明：其实，功能多并不意味东西好，而是要根据用户的需求来规划，不如考虑何时开始删减吧。

显然，她被吓坏了，楞像只初探尘世的雏鸟般呆定在了巢里，于是我便就此打住。再后来，我终明白为何她如此困惑，历来项目经理的首要职责便是考虑如何谋划产品功能，弃顺归逆岂不是砸人饭碗？这亦令我想到曾制作过浩繁冗长的功能列表，并辅以 P1 ，P2 ，P0 等标签来区分优先等级，有时还会用到 P-1 。对的，负一，这种用法仿佛使项目经理自觉重要的正序标签又升一级，即便实际上无甚新意。

若是乏人使用，移去它也无妨。强留其中只会显得突兀，或藏于说明文书一隅，偶现天地，以示自己来过世间。不过上述所言并非我之要旨，只因解决此类问题还不算是最困难的一环。

软件的日渐臃肿并非全是劣品充斥其中，多数情况下这些功能仅及达标。有些个尚未完成，有些个运作错误，反映在实际中要么用户界面不对，要么内联机制有误，要么未达用户预期。说白了就是自尊心在作祟，是为了不致落后他人，而令项目经理孳生的那苍白而贫乏的自尊。不仅如此，在作品里还可能掺杂有开发者与测试者为证明自我价值所做的多余努力，最后，整个团队一齐陷入到这般狂热的情绪之中。

于是，问题到了无法除残去秽的地步，亦让人无瑕眷顾，最后就纷纷烂在了那里。若不想删掉它们，你就得不断修补、再修补。痛苦，且无止境。

这本该可以避免的。将精力放在真正重要东西上，凡事宜简，并专精于少数。如果是新公司，别忙着扩充人马，请运用好已有的雇员，特别是，别找一个只会开会和召集会议的项目经理。善于招纳实干之士，创造之士，也别忘记保持你自身的努力。赋予创新类团队最大的职权，并落至实处。

寡言行而多思辨，终将至丰饶之地。

Misc | 评论:0 | 阅读:15285

Submitted by gouki on 2009, September 1, 7:06 AM

如果不使用passport，那么把用户session存入数据库留给多个程序调用是最方便的手段了。看到这个性能测试方案，想着留下来以备案。
tokyo tyrant现在开始被人推崇了。记得以前ruby也是。为什么这么多的好东西，都是日本人发明的？真是郁闷。。。。

原文如下：

在我负责的某个项目(调查类型的网站），不久前进行了一次推广调查。因为推广邮件是在同一时间发出，所以在5分钟之内，访问量剧增，发生了15000次左右的并发业务操作，整个系统的反映速度降低很明显。

该项目使用3台web服务器，2台mysql数据库。3台web服务器间的session共享通过NFS实现。经过后来调查，访问速度骤降是session并发导致的。

因此，开始考虑其他的session共享方案。考虑到未来能更容易的进行横向扩展，所以计划采用memcached和Tokyo tyrant。

memcached在国内的应用已经很广泛了。Tokyo tyrant是日本人平林幹雄开发的一款 DBM 数据库，该数据库读写非常快，哈希模式写入100万条数据只需0.643秒，读取100万条数据只需0.773秒，是 Berkeley DB 等 DBM 的几倍，想深入了解的人可以参考：http://blog.s135.com/post/362/。

在论证备选方案的可行性开始之前，先做个压力测试是必须的。

【测试环境】

4台pc安装JMeter模拟client，web服务器一台，一台cache服务器(用来安装NFS服务,Memcached,Tokyo tyrant）。

使用4台pc安装JMeter模拟client的原因是：使用JMETER进行并发测试的时候，单台PC只能发起4100个并发线程（这个不同机器会有不同），因此要做15000的并发测试，必须4*4100.

web服务器上apache设置：MaxClient 256

原来MaxClient 150 的情况下会成为性能瓶颈，改成256之后，apache没有成为瓶颈。针对某个功能做压力测试的时候，务必要做到其他环节不会成为系统贫瘠，不然测试就毫无准确度可言了。

安装NFS, memcached, Tokyo tyrant的cache服务器配置：

CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz

Mem: 256M

HD: 40G

这台机器有点太寒碜了，呵呵，不过据说memcached对硬件配置要求很低，刚好可以验证下。

【测试程序】

因为是测试session的并发性，所以设计成个最简单的session操作流程：

1 page1.php创建session,往session写入1kb的数据,记录$time_start。

2 header至page2.php

3 page.php取得session，记录下$time_end，并计算出时间差$time_end-$time_start。

page1.php代码：

PHP代码

<?php
function microtime_float()
{
list($usec, $sec) = explode(" ", microtime());
return ((float)$usec + (float)$sec);
}
$time_start = microtime_float();
session_start();
$_SESSION['name']='abcdefghjiasdfsadflklklasdlklkjsfdkjkasdflkjsadfkljkljsdfaasdfsafdlklkjsadfkljsdafkljljksdflkflsadflkjlkjsdaflkjdsfaljklsdfajljfsd
sadflsadfljklkjsdfjlksdfaljkfjlkfslkjsadfjlksdflakkljsfdlkjsafdlkjsafdlkjlasdfkjlkjasdfljkasdlkjfsdlkjsdflkjlkasjdfljkasflkjasflkjdsaflkjlksdafklasdljksadkljfjklsdfjklfkjlsafkjlsjkldafljksljksaljklksjfdajklsdfakljsafdkljsafkdljkljsfadjklsafdasdfsfdaabcdefghjiasdfsadflklklasdlklkjsfdkjkasdflkjsadfkljkljsdfaasdfsafdlklkjsadfkljsdafkljljksdflkflsadflkjlkjsdaflkjdsfaljklsdfajljfsd
sadflsadfljklkjsdfjlksdfaljkfjlkfslkjsadfjlksdflakkljsfdlkjsafdlkjsafdlkjlasdfkjlkjasdfljkasdlkjfsdlkjsdflkjlkasjdfljkasflkjasflkjdsaflkjlksdafklasdljksadkljfjklsdfjklfkjlsafkjlsjkldafljksljksaljklksjfdajklsdfakljsafdkljsafkdljkljsfadjklsafdasdfsfdaabcdefghjiasdfsadflklklasdlklkjsfdkjkasdflkjsadfkljkljsdfaasdfsafdlklkjsadfkljsdafkljljksdflkflsadflkjlkjsdaflkjdsfaljklsdfajljfsd
abcdefghjiasdfsadflklklasdlklkjsfdkjkasdflkjsadfkljkljsdfaasdfsafdlklkjsadfkljsdafkljljksdflkflsadflkjlkjsdaflkjdsfaljklsdfajljfsd';
header( "location:./page2.php?sid=".session_id()."&time_start=".urlencode($time_start) );

page2.php代码：

PHP代码

<?php
session_id($_GET['sid']);
function microtime_float()
{
list($usec, $sec) = explode(" ", microtime());
return ((float)$usec + (float)$sec);
}
session_start();
$name = $_SESSION['name'];
$time_start = urldecode($_GET['time_start']);
$time_end = microtime_float();
$time = ($time_end - $time_start)*1000;
$_file = './log/'. $_GET['sid'] . '.log';
$fp = fopen( $_file, 'a');
@fwrite($fp, $time);
@fclose($fp);
echo "$time Millisecond<br>";
echo $name;
?>

从代码可以看出，最后得到的time值并不是单纯的session操作的时间，session操作的时间会比这个值小。这样设计的原因是，这个值更能反映系统session并发操作的真实状况，但需确保测试环境的网络稳定，因为header函数的关系。

最后，再用perl写个简单的统计程序average.pl：

Perl代码

#!/usr/bin/env perl
my $log_dir = "./log/";
my $total_times = 0;
my $file_nums = 0;
opendir DH, $log_dir or die "无法打开 $log_dir: $!";
foreach $file (readdir DH) {
open LOGFILE, "< $log_dir$file";
while (<LOGFILE>)
{
$total_times = $total_times + $_;
$file_nums = $file_nums + 1;
}
}
print $file_nums . " sessions\n";
print "average time is:" . $total_times/$file_nums . "\n";
closedir DH;

【测试过程说明】
1      使用badboy先生成Jmeter脚本，然后用Jmeter进行分布式并发测试。
2      php对于使用memcached来存储session的实现已经非常简单，只需要进行如下配置：
      session.save_handler memcache
      session.save_path tcp://192.168.8.2:11211
3      如何使用Tokyo tyrant来存储session呢？因为Tokyo tyrant完全兼容memcached的client，所以配置和memcache几乎完全一样，只要改下IP和端口号就可以了。

【测试结果】
使用NFS共享session：
2000 sessions
average time is:57.2385746240701

3000 sessions
average time is:188.679696798311

4000 sessions
average time is:1139.70507353546

5000 sessions
average time is:5486.23318772304

5000 sessions
average time is:5526.97186436598

5670 sessions（说明：发起了6000个访问，却只成功了5670）
average time is:8324.00726914608

5489 sessions（说明：发起了6000个访问，却只成功了5489）
average time is:9749.52457159197

从上面的结果看，NFS支持并发能力非常有限。根本没有办法支持到15000个session。在6000个session的时候，就会发生session 丢失等未知的状况。即使在5000个session以内，虽然可以完成测试，但性能低下。
当然，这和我使用的NFS服务端的机器配置很低有关，相信优化配置，或者“采用session存储的时候，进行目录分级”可以进行一定程度的优化，但NFS的并发操作确实存在问题。
因为有另一个理由：为了方便测试，我写了个perl程序用来删除session目录下的所有文件。
del_files.pl代码：

Perl代码

#!/usr/bin/env perl
my $log_dir = "./log/";
unlink glob "$log_dir/*.*";
my $session_dir = "./session_tmp/";
unlink glob "$session_dir/*";
my $session_dir2 = "./session_nfs/";
unlink glob "$session_dir2/*";

当这个程序用于删除NFS目录下的session文件时，程序运行的时间明显比用于删除非NFS目录慢非常的多。

使用Memcached共享session：
5000 sessions
average time is:8.691506099701

10000 sessions
average time is:9.07290377616917

15000 sessions
average time is:9.10538846651721

15000 sessions
average time is:9.42796174685197

15000 sessions
average time is:9.43535621960958
从以上结果可以看出，memcached性能很稳定，在5000，10000，15000个session几种情况下，每个流程处理的平均时间稳定在8毫秒到10毫秒之间。

使用Tokyo tyrant共享session：
5000 sessions
average time is:8.92114758491478

10000 sessions
average time is:8.35826919078823

15000 sessions
average time is:10.7764382680262

15000 sessions
average time is:11.4394629955285

15000 sessions
average time is:8.92091128031373

15000 sessions
average time is:10.3760389963784

tokyo tyrant速度也很快。但稳定性不如memcached，可能对机器的配置要求会高些吧，或者我对tokyo tyrant配置不了解也有可能。

从测试结果看，NFS用于存储session时候的并发性能明显不如memcached和tokyo tyrant。memcache和tokyo tyrant还可以进行更大规模的并发测试。但是限于我当前的硬件，没有再进行更大规模的测试。

ok了，Memcached和tokyo tyrant的表现都让人满意，符合预期。至于要选择哪个，就得考虑其他因素了：
1 是否需要持久存储，Memcached是不支持持久存储的，当然可以考虑使用 Memcached+DB的方式来达到“一定程度上的持久存储”，即Memcached实时保存session，在每隔一段时间（比如1分钟）将 session保存到DB，至于能否接受这种方案，得看业务需求而定了。Memcached和tokyo tyrant的其他差别，可以参考下http://blog.s135.com/post/362/等资料

2 对于这两项技术的掌握程度，整体上说，这两个技术应该都是靠得住，tokyo tyrant在日本也有不少成功的应用。但从国内来看，Memcached应用得较多，使用tokyo tyrant的话，还是要有一定的钻研精神才行。

原文请见:NFS,Memcached,Tokyo tyrant实现session共享性能测试

Tags: tokyo tyrant, session共享

PHP | 评论:0 | 阅读:18552

Records:3094«‹444 445 446 447 448449450 451 452 453 ›»

« 2024年11月 »