• Feeds

  • 第一期广州技术沙龙活动总结

    活动搞完,一般都得总结一下。但人们对自己当事的东西通常很难表达。就像以前学校考试,每次考完被问考得怎样,往往不知道该怎么回答。大部分题目感觉像是做对了,但又不知道是否符合“标准答案”。考试的标准答案是老师定的,那活动或者演讲的“标准答案”呢,则是在每个参与者心中。

    现场情况

    很多参会的同学都做了精彩的总结,很客观,所以我也没必要进一步补充了。本次计划人数是50人,结果超出了一点,所以会场有点挤。(还有不少同学后到的,实际人数比照片上要多)
    第一期广州技术沙龙
    不足

    根据大家的反馈来看,主要有以下几点

    1. 交流机会不足

    本次也是依照传统的活动方式,演讲加提问,然后剩下时间小范围自由交流然后散会。由于会议室较小人又偏多,所以技术沙龙变成了技术演讲会。这个也是我们技术沙龙需要继续思考的一个问题,是限制参加人数以便形成多方讨论?还是召集更多的技术人来进行单向技术分享会?(当然不管哪种方式,并不妨碍我们用视频直播,视频及演讲稿分享等方式传达给更多群体)

    2. 不够专业及深入

    由于我选的Key value store题目过大,所以大部分内容只能蜻蜓点水。最大的价值可能就是给对这些方面感兴趣的同学提供一个参考的学习方向。

    演讲稿说明

    大家感兴趣的可能是Benchmark那部分,其实那个只是花了几个小时的功夫,因为手头的测试试验环境相对比较全面,所以测试起来也没费什么周折。其实我自己最看重、最希望传达的是演讲稿的后半部分,希望大家在设计自己的网络应用的时候,能够借鉴一些先进的分布式思想,指导自己少走一些弯路。部分观点其实我也没有实践经验,但是根据自己目前手头的一些应用的现状,觉得应用这些思想到系统中可以极大的提高系统的可扩展性及可维护性。Dynamo等Paper像一座桥梁,可以拉近我们与国外分布式设计思想的距离,让我们在这些已经被认可的方法的基础上去发现新的问题,迎接更有意义的挑战。

    由于这次要组织活动,所以基本没同来参会的各位向往已久的同学深入交流,这个是最大的遗憾。

    下一期的技术沙龙是zhuzhaoyuan的nginx源码剖析方面话题,预计在9月中上旬召开,地点在网易。

    附:搜集到一些同学的作业

    MemcacheDB, Tokyo Tyrant, Redis performance test

    I had tested the following key-value store for set() and get()

    1. Test environment

    1.1 Hardware/OS

    2 Linux boxes in a LAN, 1 server and 1 test client
    Linux Centos 5.2 64bit
    Intel(R) Xeon(R) CPU E5410  @ 2.33GHz (L2 cache: 6M), Quad-Core * 2
    8G memory
    SCSI disk (standalone disk, no other access)

    1.2 Software version

    db-4.7.25.tar.gz
    libevent-1.4.11-stable.tar.gz
    memcached-1.2.8.tar.gz
    memcachedb-1.2.1-beta.tar.gz
    redis-0.900_2.tar.gz
    tokyocabinet-1.4.9.tar.gz
    tokyotyrant-1.1.9.tar.gz

    1.3 Configuration

    Memcachedb startup parameter
    Test 100 bytes
    ./memcachedb -H /data5/kvtest/bdb/data -d -p 11212 -m 2048 -N -L 8192
    (Update: As mentioned by Steve, the 100-byte-test missed the -N paramter, so I added it and updated the data)
    Test 20k bytes
    ./memcachedb -H /data5/kvtest/mcdb/data -d -p 11212 -b 21000 -N -m 2048

    Tokyo Tyrant (Tokyo Cabinet) configuration
    Use default Tokyo Tyrant sbin/ttservctl
    use .tch database, hashtable database

    ulimsiz=”256m”
    sid=1
    dbname=”$basedir/casket.tch#bnum=50000000″ # default 1M is not enough!
    maxcon=”65536″
    retval=0

    Redis configuration
    timeout 300
    save 900 1
    save 300 10
    save 60 10000
    # no maxmemory settings

    1.4 Test client

    Client in Java, JDK1.6.0, 16 threads
    Use Memcached client java_memcached-release_2.0.1.jar
    JRedis client for Redis test, another JDBC-Redis has poor performance.

    2. Small data size test result

    Test 1, 1-5,000,000 as key, 100 bytes string value, do set, then get test, all get test has result.
    Request per second(mean)key-value-performance-1(Update)

    Store Write Read
    Memcached 55,989 50,974
    Memcachedb 25,583 35,260
    Tokyo Tyrant 42,988 46,238
    Redis 85,765 71,708

    Server Load Average

    Store Write Read
    Memcached 1.80, 1.53, 0.87 1.17, 1.16, 0.83
    MemcacheDB 1.44, 0.93, 0.64 4.35, 1.94, 1.05
    Tokyo Tyrant 3.70, 1.71, 1.14 2.98, 1.81, 1.26
    Redis 1.06, 0.32, 0.18 1.56, 1.00, 0.54

    3. Larger data size test result

    Test 2, 1-500,000 as key, 20k bytes string value, do set, then get test, all get test has result.
    Request per second(mean)
    (Aug 13 Update: fixed a bug on get() that read non-exist key)
    key-value-performance-2(update)

    Store Write Read
    Memcachedb 357 327
    Tokyo Tyrant 3,501 257
    Redis 1,542 957

    4. Some notes about the test

    When test Redis server, the memory goes up steadily, consumed all 8G and then use swap(and write speed slow down), after all memory and swap space is used, the client will get exceptions. So use Redis in a productive environment should limit to a small data size. It is another cache solution rather than a persistent storage. So compare Redis together with MemcacheDB/TC may not fair because Redis actually does not save data to disk during the test.

    Tokyo cabinet and memcachedb are very stable during heavy load, use very little memory in set test and less than physical memory in get test.

    MemcacheDB peformance is poor for write large data size(20k).

    The call response time was not monitored in this test.

    第一期广州技术沙龙演讲稿及视频

    Topic 1: 选好业务与技术,单枪匹马做游戏 (赖勇浩)

    Topic 2: 分布式 Key Value Store 漫谈 (Tim Yang)

    视频(上)

    视频(下)