九月 3 rd

4

哆啦A梦生日快乐！

2009-09-03  |  分类：菜田琐事

doraemon09

今天是9月3日，哆啦A梦的生日，也是我的生日，同时也是迈克尔杰克逊的下葬日。

大家都生日快乐吧～

补充：今天也是Google Crome一周岁生日！

标签：、 22 次访问  |  4 条评论

九月 3 rd

5

不知道哪篇文章触动了某些人的神经，今天我的博客域名blog.blakehan.com居然被加入GFW关键字黑名单了。

请注意不是DNS劫持，也不是IP被封，而是域名被当作关键字被过滤了！也就是说只要某个网站的URL里包含了“blog.blakehan.com”这个词，那么恭喜你，在你的IP C段里你的网站都要被Block一会儿了。大家经常在公司发现Google不能用就是这个道理。想到自己的域名居然和“无界”，“XX功”相提并论，自豪感不禁油然而生～

摄于GFW的淫威，blog.blakehan.com域名停用，现启用新域名b.blakehan.com。麻烦大家更新外部链接～

最后也感叹下“百毒”的强大，在百毒上搜索任何关键字都不会被屏蔽域名……

google_blocked

baidu_passed

标签： 261 次访问  |  5 条评论

九月 1 st

0

Benchmark Test of DBM Brothers

2009-09-01  |  分类：architecture

This benchmark test is to calculate processing time (real time) and file size of database. Writing test is to store 1,000,000 records. Reading test is to fetch all of its records. Both of the key and the value of each record are such 8-byte strings as `00000001′, `00000002′, `00000003′… Tuning parameters of each DBM are set to display its best performance. Platform: Linux 2.6.16 kernel, EXT3 file system (writeback), Intel Xeon quad core 2.3GHz CPU, 8GB RAM Compilation: gcc 4.2.3 (using -O3), glibc 2.7

Result

NAME DESCRIPTION WRITE TIME READ TIME FILE SIZE
TC Tokyo Cabinet 1.3.5 0.402 0.334 42583208
QDBM Quick Database Manager 1.8.77 2.779 0.962 56582932
NDBM New Database Manager 5.1 5.118 3.551 834003968
SDBM Substitute Database Manager 1.0.2 6.277 0 621281280
GDBM GNU Database Manager 1.8.3 18.692 3.133 88137728
TDB Trivial Database 1.0.6 7.219 0.789 52523008
CDB Tiny Constant Database 0.75 0.357 0.371 40002048
BDB Berkeley DB 4.6.21 9.108 3.109 41938944
TC-BT-ASC B+ tree API of TC (ascending order) 0.707 0.601 32340739
TC-BT-RND B+ tree API of TC (at random) 2.896 2.263 12532397
QDBM-BT-ASC B+ tree API of QDBM (ascending order) 1.404 0.951 40620715
QDBM-BT-RND B+ tree API of QDBM (at random) 6.311 3.816 15731675
BDB-BT-ASC B+ tree API of BDB (ascending order) 1.354 1.451 57999360
BDB-BT-RND B+ tree API of BDB (at random) 3.751 2.415 29818880
TC-FIXED Fixed-length API of TC 0.248 0.037 9002452


DBM_ProcessingTime


DBM_FileSize

via: http://tokyocabinet.sourceforge.net

标签：、、、 60 次访问  |  发表评论

八月 27 th

0

如何为视频加上活动的台标

2009-08-27  |  分类：互联网

最近的视频网站项目做到尾声的时候碰到了视频加水印的问题。普通的固定台标或者文字都很好加，但如何才能像土豆、优酷那样台标一会儿显示在左边，一会儿显示在右边，一会儿中文，一会儿英文呢？由于项目使用的转码软件是FFMpeg，文档极度缺乏，网络视频这个领域又很窄，网上几乎没人讨论。在研究了半天后终于忍不住去看FFMpeg的源代码了……

终于在FFMpeg的源代码注释中找到了些蛛丝马迹，实现了功能。

首先FFMpeg加台标可以采用vhook方式使用plugin（vhook在下个版本的FFMpeg将被废除，但目前的0.5版本还在使用-_-）。而vhook可以使用imlib，drawtext和watermark三种方式来给视频添加水印。

watermark模块号称可以使用动画GIF文件做水印，不过经过测试后发现只能显示GIF的第一帧，淘汰。

drawtext模块只能叠加文字，而需求要使用图片，也被淘汰。

没得选择，只能使用imlib模块了。要解决的问题有2个，1是如何让水印运动起来，2是如何让2个水印交替显示。 全文阅读 »

标签：、、、 170 次访问  |  发表评论

八月 27 th

0

Milo的创始人之一Ted Dziuba最近对Scalabitily又愤青了一把，大骂创业者或是开发人员不要在总想着系统的扩展性。对此，Ted喷出了三个论点：

1. People Who Talk Big About Scalability Don’t Need To Worry About It

很多Asshole没事就在博客中讨论可扩展性架构，但是自己却写着很烂的代码。好的系统不是靠构架就可以有扩展性的，一个有着很多N平方次循环的code是没有扩展性可言的。所以在你们大谈Memcached之前，先了解下缓存过期策略吧！

2. If You Haven’t Discussed Capacity Planning, You Can’t Discuss Scalability

你不需要去担心怎么扩展基于MySQL的程序，因为根本没人会去用你的应用。就算你有1000个用户，可能只有1%的用户会天天来使用你的系统。扩展系统不重要，重要的是怎么把人吸引过来。当然支撑百万用户的系统和千万用户的系统架构上是不同的，如果你设计的系统不会有100万用户，就不要太考虑扩展性了。

此外，工程师都会幻想着“线性扩展”，觉得如果用户太多，就加机器好了。其实根本没有这回事。去试试Amazon的SimpleDB吧，等你有了足够的用户并且数据存储的延时成为瓶颈时，就尽情的去骂”those shitty Amazon datacenters”吧。

3. Choosing Technology Don’t Mean Shit If You Don’t Know How To Use It

选择正确的技术不会完全解决扩展性问题。如何正确的使用才是王道。

最后引用Ted的话收场：Shut up about scalability, no one is using your app anyway.

注：文章中所涉及的所有脏话及不和谐用语皆为原文直接引用……

标签：、 6 次访问  |  发表评论

八月 24 th

1

Bjorn Hansen的网站性能和可扩展性建议。基本上都是已知的东西。看来我们做的几个项目在这方面都是世界级的了。

Think Horizontally at every point in your architecture, not just at the web tier.

这句话很重要！

Benchmarking
找好基准点
Vertical scaling sucks.
垂直分割是很烂的
Horizontal scaling rocks.
水平分割才是王道
Run many application servers
运行多个应用服务器
Don’t keep state in the app server
不要做应用服务器上保存状态
Be stateless
系统要是无状态的
Optimization is necessary, but is different than scalability.
优化是必要的，但不等同于扩展
Cache things you hit all the time.
缓存所有命中的内容
Measure, don’t assume, check.
测量、检查，不要假设
Make pages static.
页面静态化
aching is a trade-off.
缓存是双刃剑
Cache full pages.
缓存整个页面
Cache partial pages.
缓存部分页面
Cache complex data.
缓存复杂数据
ySQL query cache is flushed on update.
ySQL查询缓存在update操作是会刷新
Cache invalidation is hard.
缓存过期很难做好
Replication scales reads, not writes.
读操作要用复制扩展
Partition to scale writes. 96% of applications can skip this step.
写操作用分区来扩展。96%的应用不需要这步
aster-master setup facilitates on-line schema changes.
？？？
Create summary tables and summary databases rather than do COUNT and GROUP-BY at runtime.
创建统计表和统计数据库，而不要每次使用COUNT和GROUP-BY
Make code idempotent. If it fails you should just be able to run it again.
代码要自省。错误了要能重新运行。
Load data asynchronously. Aggregate updates into batches.
异步加载数据。批量更新数据
Move processing to application and out of the database as much as possible.
数据处理尽量用App服务器做而不要让数据库去计算
Stored procedures are dangerous.
存储过程很危险
Add more memory.
多加内存
Enable query logging and take a look at what your app is doing.
打开查询日志，看看你的程序在干嘛
Run different MySQL instances for different work loads.
为不同的工作负载运行不同的MySQL实例
Config tuning helps, query tuning works.
数据库配置优化是有用的，查询语句优化很有用
Reconsider persistent DB connections.
重新考虑持久化数据库连接
Don’t overwork the database. It’s hard to scale.
不要滥用数据库，他很难扩展
Work in parallel.
并行计算
Use a job queuing system.
采用任务队列系统
Log http requests.
记录HTTP请求
Use light processes for light tasks.
轻量的工作用轻量的处理
Build on APIs internally. Clean loosely coupled APIs are easy to scale.
建立内部接口。松耦合的接口容易扩展。
Don’t incur technical debt.
技术上不要欠债
Automatically handle failures.
自动处理错误
Make services that always work.
服务要能一直运行
Load balancing is the key to horizontal scaling.
负载均衡是水平扩展的核心
Redundancy is not load-balancing. Always have n+1 capacity.
太多冗余不是复杂均衡。始终拥有N+1的容积
Plan for disasters.
考虑到灾难恢复
Make backups.
做好备份
Keep software deployments easy.
简化软件部署
Have everything scripted.
每个步骤都脚本话
Monitor everything. Graph everything.
监控所有的东西，图形化所有的东西
Run one service per server.
每个服务器只运行一个服务
Don’t ever swap memory for disk.
别用内存交换区
Run memcached if you have extra memory.
如果内存赋予就运行memcached吧
Use memory to save CPU or IO. Balance memory vs CPU vs IO.
用内存来节省CPU或IO。掌握好三者之间的平衡
Netboot your application servers.
从网络启动应用服务器
There’s lot of good slides on what to graph.
有很多好的PPT教你要图形化些什么内容
Use a CDN.
使用CDN
Use YSlow to find client side problems.
用YSlow来发现浏览器端问题
  • Benchmarking
  • 找好基准点
  • Vertical scaling sucks.
  • 垂直分割是很烂的
  • Horizontal scaling rocks.
  • 水平分割才是王道
  • Run many application servers
  • 运行多个应用服务器
  • Don’t keep state in the app server
  • 不要做应用服务器上保存状态
  • Be stateless
  • 系统要是无状态的
  • Optimization is necessary, but is different than scalability.
  • 优化是必要的，但不等同于扩展
  • Cache things you hit all the time.
  • 缓存所有命中的内容
  • Measure, don’t assume, check.
  • 测量、检查，不要假设
  • Make pages static.
  • 页面静态化
  • aching is a trade-off.
  • 缓存是双刃剑
  • Cache full pages.
  • 缓存整个页面
  • Cache partial pages.
  • 缓存部分页面
  • Cache complex data.
  • 缓存复杂数据 全文阅读 »
标签：、、、、、、 20 次访问  |  1条评论

八月 23 rd

0

How Google Serves Data from Multiple Datacenters

Ryan Barrett, Google App Engine datastore lead, gave this talk Transactions Across Datacenters (and Other Weekend Projects) at the Google I/O 2009 conference.

While the talk doesn’t necessarily break new technical ground, Ryan does an excellent job explaining and evaluating the different options you have when architecting a system to work across multiple datacenters. This is called multihoming, operating from multiple datacenters simultaneously.

As multihoming is one of the most challenging tasks in all computing, Ryan’s clear and thoughtful style comfortably leads you through the various options. On the trip you learn:

  • The different multi-homing options are: Backups, Master-Slave, Multi-Master, 2PC, and Paxos. You’ll also learn how they each fair on support for consistency, transactions, latency, throughput, data loss, and failover.
  • Google App Engine uses master/slave replication between datacenters. They chose this approach in order to provide:
    - lowish latency writes
    - datacenter failure survival
    - strong consistency guarantees.
  • No solution is all win, so a compromise must be made depending on what you think is important. A major Google App Engine goal was to provide a strong consistency model for programmers. They also wanted to be able to survive datacenter failures. And they wanted write performance that wasn’t too far behind a type relational database. These priorities guided their architectural choices.
  • In the future they hope to offer optional models so you can select Paxos, 2PC, etc for your particular problem requirements (Yahoo’s PNUTS does something like this).

    There’s still a lot more to learn. Here’s my gloss on the talk:

    全文阅读 »

    • 标签：、 16 次访问  |  发表评论

    八月 23 rd

    0

    这是一篇受密码保护的文章。您需要提供访问密码：


    标签：、、、、、、、、、 372 次访问  |  查看留言请输入密码

    八月 12 th

    0

    入手新域名

    2009-08-12  |  分类：互联网

    0xFACE.com

    想想能搞个啥东西上去。做个Geek的SNS貌似不错。

    标签：、 7 次访问  |  发表评论

    八月 11 th

    2

    天哪，联想的O1送我都不要

    2009-08-11  |  分类：Android

    啥都不说，看看工业设计吧，典型的山寨机风格

    O1

    （点击可看大图）。看到啥了吗？手机电视！还支持拉杆天线@！！天哪，想想以后马路上人手一个O1拉出天线看电视的场景我就要崩溃了。

    机机山寨也算了，弄个广告还那么山寨，搞个不算漂亮的MM坐在游泳池里用O1。难道O1 10米防水么……

    算鸟，还是看看泳装秀好了。

    p5p2

    p3p4p1

    借用外国人的一句话结尾：

    For more OPhone fun, check out the official site of the O1.  There is a lot of crazy stuff in there.
    http://www.ophone001.com/

    标签：、、、、 48 次访问  |  2 条评论
    分页: 上一页 1 2 3 4 5 6 下一页

    ©2008 - 2009 菜田日记 All Rights Reservied

    Powered by WordPress. Theme by Prower, Modified by me

    Search Engine Optimization