寻梦那个园,香草那个场

寻梦园香草农场,这地名取的真不错,但应该说是寻梦烧烤场。也可能是我们去的时间不对,没看见大面积开花的场景。零散的人为建筑,营造出些许浪漫。巴黎婚纱的摄影队,带着新娘新郎田间地头摆pose。

天空的白云很美,空气也很新鲜。晒晒太阳,看看小狗是一种享受。同事们拿了五个炉子。那炉烤好吃那炉,基本可以发现都是男同事在烤。(*^__^*)难怪现在的女士们不变黄脸婆,变“肥婆”了。

DSC03471
鸡翅阵

DSC03472

骨肉串

DSC03536
玉米山

DSC03483

大棚的确很温暖

DSC03509
零星的薰衣草

DSC03518

有点“梦”的感觉了

DSC03544

最后一张“世博-中国馆”?

日志de大数据

最近看到漆兴关于这方面的文章,也有了想借鉴的地方。对类似问题的处理方式应该都是一样的。总的来说还是可以分为采集模块、分析模块、数据存储、展示模块、配置模块。对于展示,就是类似WEB页面,这部分经验不多分享。更多是对于其他模块的对比。

采集方式基本都是通过http请求过来的数据。自定义或是使用服务器本身的日志。但这里关键的一点是要统一日志格式。采集的效率问题,可以参考,通过队列、缓存可以满足要求。不会产生大量的写IO操作。如果采用Web-Servier本身的日志机制也是不错选择。

分析模块按目前的日志量,不存在什么大问题,而且基本是文本文件读取到内存操作。可优化部分也是启用多线程或进程,这个就看部署了。而且需要配置管理,不过也许是近期最值得改进的地方。当然也可以把分析时间间隔变短,按天运行、按小时运行。

数据存储基本表现在将运算好的结果写入数据库太慢。上千万条记录一条条运行,显然是下策。如果将文件生成数据文件一次导入,肯定效率高。但有一点没明白,生成的文件是SQL脚本,再运行,这样也能提高效率?是理解错误,其实是生产批量插入数据,50000条数据在我测试的机器相差20秒,所以还是有效果的。

数据分析中,按我们目前的需求(可能是有需求,但没发掘),可以将部分计算好的数据固化就可以了。其实日志不多,简单的处理还应附的过来。如果真的T级了,恐怕Hadoop,Infobright要用上。具体也没怎么深入过,也不细谈了。

Mysql的存储上可借鉴不少。使用MyISAM,但奇怪实际使用该引擎,有时会出现表crash,可能是有什么地方没配置好。数据库设计上,基本上肯定是按时间创建索引,可能有两个地方不能偷懒,要使用数值类型的日期格式和IP地址。Mysql分区、Merge表、或是按统计的类型对数据做水平分割。Config文件的配置,这个要另开一文总结和整理一下,也避免自己忘记了。

其实想想当初觉的写的优秀的东西,现在发现问题还不少。看来数量或是某层级的提高,才是技术的驱动力噢!量变引起技术的质变,貌似说的通。大数据量的处理经验已经不仅仅是索引和结构优化了。

洗牙电池煎饺

第一回洗牙。洗好的牙缝还是蛮透风的。不过明显是舒服了不少。用舌尖舔自己的牙齿不会觉的那么粗糙了。不过洗牙不是美牙。医生更多的是清理你牙齿缝里的脏东西。MM说现在洗牙比以前先进了,原来现在会有一根管子把洗的水吸出去。所以我也觉的奇怪,牙医怎么老不叫我吐冲的水呢!

继续忙碌WAP的M版本,多少有些失望。Myssql下继续处理一堆莫名的错误。对于RSS的访问量还是有所保留。这些事足够忙到五一放假了。期盼世博的政府假期,但这也有可能是场愚人节的笑话。谁知道呢!不过闭上眼,还是能找到不少乐趣,就怕人多是个问题。纪念卡是不能出门坐车的,我一般都自备电池。

如果一台手机,不定时的死机,不定时的出现花屏,不定时的无法开机。你会认为是什么原因?排线问题?线路接触?NO,电池出了问题。花了不是很贵的价格,买了一个不算牌子的牌子的电池。终于把问题给解决了。又开始就此和MM展开了成本与收入的对话。

这是第一锅煎出的饺子。要煎饺子不碎,可是有学问的。治大国若烹小鲜,厨房之事,绝非菜谱啊。在外吃饭,地沟油、卫生筷都是个问题,还是自己做饭比较好。

DSC03452-1

黑匣子

performance-test

关于性能这个问题,不同平台不同语言也各有技巧,经验的积累也显得比较重要。相比开发而言,测试和性能的关系更为紧密。就像一个小型网站,你用词条表完成搜索,远远比你使用一个搜索引擎来的“效率”高的多。网站大了,总归是要鸟枪换炮的,而这过程,应该由测试和监控来回答。

性能优化的过程,是一个代码质量改进的过程,也是一个部署资源分配的过程。机器、人、代码你希望优先扩充的是那个呢?当问题开始发散时,就会牵涉到监控、分布式、缓存,某些特定的应用还要关注到IO,流量等。

监控报告一个让人迷糊的地带。有时会怀疑这个数据准确吗!这组结果和预期或所想并不吻合,这就需要进一步的验证,也正是这份报告存在的意义。不是吗?当然不要选择一个太离谱的工具,导致一个本身就不靠谱的结果,就失去了讨论的基石。对于报告的态度,要相信它是个趋势,如果你要细微到每秒,你只会发现漏洞太多,不能解释的原因太多。

黑匣子,最应该有的东西,技术实现简单。如果可能,它将是你获得系统运行状态的最佳方式。正常高值、异常访问、吞吐量、响应时间,还有更多。这样也能体会到把事情记录下来的价值。黑匣子是基于APP本身的,会有其自身的缺陷,它也不是万能的。

性能杀手中的Spider&Robot,不知道这样说是否正确。但的确有很多非正常访问给系统照成的开销,包括某个高点上的疯子行为。是访问机制问题,还是有硬件设备的支持。你不可能每个系统都去处理一遍,难道没有专用“设备”。

一组测试结果,这个结果不具备真实环境,但可以回答几个关注点:Requests per second,Request Time,Percentage of the user requests

Concurrency Level: 10
Time taken for tests: 101.156 seconds
Complete requests: 4000
Failed requests: 3999
(Connect: 0, Receive: 0, Length: 3999, Exceptions: 0)
Write errors: 0
Total transferred: 118866774 bytes
HTML transferred: 116247427 bytes
Requests per second: 39.54 [#/sec] (mean)
Time per request: 252.891 [ms] (mean)
Time per request: 25.289 [ms] (mean, across all concurrent requests)
Transfer rate: 1147.54 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 1.8 0 16
Processing: 78 252 88.2 234 1453
Waiting: 78 250 88.1 234 1438
Total: 78 253 88.1 234 1453

Percentage of the requests served within a certain time (ms)
50% 234
66% 266
75% 281
80% 297
90% 344
95% 375
98% 453
99% 500
100% 1453 (longest request)

对于测试技术本身,要问测试专家了。更关心的是测试所带来的性能分析及优化本身。系统性能到底能跑到什么指标,你能相信的是黑匣子,而测试绝对是个参考值。