Mysql的优化经验

1. 从数据库结构做起 1. 字段类型的定义时遵循以下规则: 1. 选用字段长度最小 2. 优先使用定长型 3. 尽可能的定义 “NOT NULL” 4. 数值型字段中避免使用 “ZEROFILL” 5. 如果要储存的数据为字符串, 且可能值已知且有限, 优先使用 enum 或 set 2. 索引的优化至关重要(以下如果没有特殊说明, 均指查询密集的情况)

让nodejs 快如风的十个小技巧

1、避免使用同步的方法   nodejs 是基于单线程。为了让单线程能够处理高并发的请求,我们尽量要避免让线程等待,阻塞,同步,和长时间运行某项操作。nodejs 一个显著的特点就是彻头彻尾的异步。这个特性在基于事件驱动的应用上表现的非常的出色。   不幸的是在nodejs 中仍然存在可以同步或者阻塞调用方法。例如,许多的文件系统操作既有异步的方法也有同步的方法,像 fs.writeFile 和 fs.writeFileSync。尽管你避免在代码中使用同步的方法,但你引用的外部库中可能包含致使阻塞的方法调用。一旦这种情况出现,将会对性能产 生显著的影响。   // 正确写法: 异步的写文件 fs.writeFile(‘message.txt’, ‘Hello Node’, function (err) { console.log(“It’s saved and the server remains responsive!”); }); // 音响性能的写法: 同步的写文件 fs.writeFileSync(‘message.txt’, ‘Hello Node’); console.log(“It’s saved, but you just blocked ALL requests!”);

Facebook图片管理架构

Facebook 的照片分享很受欢迎,迄今,Facebook 用户已经上传了150亿张照片,加上缩略图,总容量超过1.5PB,而每周新增的照片为2亿2000万张,约25TB,高峰期,Facebook 每秒处理55万张照片,这些数字让如何管理这些数据成为一个巨大的挑战。本文由 Facebook 工程师撰写,讲述了他们是如何管理这些照片的。 旧的 NFS 照片架构 老的照片系统架构分以下几个层: # 上传层接收用户上传的照片并保存在 NFS 存储层。 # 照片服务层接收 HTTP 请求并从 NFS 存储层输出照片。 # NFS存储层建立在商业存储系统之上。 因为每张照片都以文件形式单独存储,这样庞大的照片量导致非常庞大的元数据规模,超过了 NFS 存储层的缓存上限,导致每次招聘请求会上传都包含多次I/O操作。庞大的元数据成为整个照片架构的瓶颈。这就是为什么 Facebook 主要依赖 CDN 的原因。为了解决这些问题,他们做了两项优化: # Cachr: 一个缓存服务器,缓存 Facebook 的小尺寸用户资料照片。 # NFS文件句柄缓存:部署在照片输出层,以降低 NFS 存储层的元数据开销。

Facebook 的 PHP 性能与扩展性

  炙手可热的 Facebook 是用 PHP 开发的。随着一些技术交流,逐渐能看到 Facebook 技术人员分享的经验。近期这个 geekSessions 站点上看到 Facebook 的 Lucas Nealan 分享的文档比较有参考价值。 Cache 为 王 任何一个成功的站点都有一套最合适自己的 Cache 策略。 Note:这个层次图画的稍微有点问题,不是严格从上到下的。

走进内心深入的活法

一、空白也是一种色彩 佛在菩提树下大彻大悟,我在灶台旁茅塞顿开,世界上并非所有的事情都值得全心全意去做,适当的空白也是一种色彩。 我花很长时间吃一枚很小的水果,我用一上午读一本很久没有读完的闲书,我整整一天都穿着睡衣在房间里游来荡去。有时,我就这样悠闲地度日,因为我发现事业固然是我必须营造的圣殿,但在这个圣殿的后面还应该有一个花园。 男人们忙忙碌碌,争取金钱和地位,沉溺于琐事和俗务,让头衔、身份,财产充满生命的每一个角落,这种没有空白的生命,最终有几个不是赢了别人,输了自己。 空白是不着一字的风流,是无为而至的悠然,是一种闲适而富有的自然存在,是人生的一种智慧和哲学。空白能解开功名的绳索,能卸下利禄的重负,它是享受生活的营地,是生命大吐芬芳的良宵。 没有空白的人生是一个充满欲望的人生,这样的人生永远都不会有心灵的宁静,不会有恬静的陶醉,不会有精神的愉悦,更不会有人与自然的交融。 在这个世界上,生活的艺术,有时就是一门留白的艺术。

20个佛教经典故事—开悟人生

1、泥泞路上 某日,坦山和尚与一道友一起走在一条泥泞小路上,此时,天正下着大雨。 他俩在一个拐弯处遇到一位漂亮的姑娘,姑娘因为身着绸布衣裳和丝质衣带而无法跨过那条泥路。 “来吧,姑娘,”坦山说道,然后就把那位姑娘抱过了泥路,放下后又继续赶路。 一路上,道友一直闷声不响,最后终于按捺不住,向坦山发问:“我们出家人不近女色,特别是年轻貌美的女子,那是很危险的,你为什么要那样做?” “什么?那个女人吗?”坦山答道,“我早就把她放下了,你还抱着吗?” 2、四个老婆 释迦牟尼在一次法会上说:“某地有个富商共讨了四个老婆:第一个老婆伶俐可爱,整天作陪,寸步不离;第二个老婆是抢来的,是个大美人;第三个老婆,沉溺于生活琐事,让他过着安定的生活;第四个老婆工作勤奋,东奔西忙,使丈夫根本忘记了她的存在。 “有一次,商人要出远门,为免除长途旅行的寂寞,他决定在四个老婆中选一个陪伴自己旅行。商人把自己的想法告诉了四个老婆,第一个老婆说:‘你自己去吧,我才不陪你!’ “第二个老婆说:‘我是被你抢来的,本来就不心甘情愿地当你的老婆,我才不去呢?’ “第三个老婆说:‘尽管我是你的老婆,可我不愿受风餐露宿之苦,我最多送你到城郊!’ “第四个老婆说:‘既然我是你的老婆,无论你到哪里我都跟着你。’ “于是商人带着第四个老婆开始了旅行!” 最后,释迦牟尼说:“各位,这个商人是谁呢?就是你们自己。” 在这则故事里,第一个老婆是指肉体,死后还是要与自己分开的;第二个老婆是指财产,它生不带来,死不带去;第三个老婆是指自己的妻子,活时两个相依为命,死后还是要分道扬镳;第四个老婆是指自性而言,人们时常忘记它的存在,但它却永远陪伴着自己。

Web安全黑盒测试之保证测试的全面性

在目前的 WEB 安全黑盒测试方法中,一般是按照黑客攻击的手法进行测试,以达到准确性与全面性。那么,如何保证黑盒测试的全面性与准确性呢?总结一下,可以有以下几个方面: 1、对产品项目的熟悉程度。 测试之前,对项目进行了解跟踪,熟悉项目的所有功能、接口以及与其他项目的关联性(有时候A项目的功能会造成B项目存在安全风险)。 2、全面的技术知识。 由于每个项目的功能都不同,可能涉及到的应用就不同,有的项目是视频应用,就要了解flash脚本编写技术与前端配置知识,大多数 flash蠕虫都是因为前端配置问题造成的。有些项目用到了AJax,那么测试人员就必须了解AJax的知识。有的项目用到 ActiveX 插件,那么就要知道 ActiveX 可能造成的安全问题,等等。所以,安全测试人员要掌握全面技术知识,才可以对每个项目进行测试,并不因为新项目中包含新的技术而放弃测试。同时还要有不断的学习能力,遇到未知的技术要进行快速学习,然后对项目进行测试。 3、超强的漏洞挖掘能力,以及实战能力。 安全测试时,必须按照黑客攻击的手法进行测试,所以,这就要求WEB安全测试人员拥有超强的漏洞挖掘能力与漏洞认知度。同样还要拥有实战经验,一个没有 实践经验的测试人员,不是一个好的安全测试人员,当安全测试人员并不知道安全BUG所造成的的方式与利用后所造成的影响,就不能全部的发现所有安全 BUG,同时又不能在各个安全BUG危险度上进行分级,这就造成一些安全BUG的疏漏。

MySQL的表分区

MySQL的表分区 文章分类:数据库 一、什么是表分区 通俗地讲表分区是将一大表,根据条件分割成若干个小表。mysql5.1开始支持数据表分区了。 如:某用户表的记录超过了600万条,那么就可以根据入库日期将表分区,也可以根据所在地将表分区。当然也可根据其他的条件分区。   二、为什么要对表进行分区 为了改善大型表以及具有各种访问模式的表的可伸缩性,可管理性和提高数据库效率。 分区的一些优点包括: 1)、与单个磁盘或文件系统分区相比,可以存储更多的数据。 2)、对于那些已经失去保存意义的数据,通常可以通过删除与那些数据有关的分区,很容易地删除那些数据。相反地,在某些情况下,添加新数据的过程又可以通过为那些新数据专门增加一个新的分区,来很方便地实现。通常和分区有关的其他优点包括下面列出的这些。MySQL分区中的这些功能目前还没有实现,但是在我们的优先级列表中,具有高的优先级;我们希望在5.1的生产版本中,能包括这些功能。 3)、一些查询可以得到极大的优化,这主要是借助于满足一个给定WHERE语句的数据可以只保存在一个或多个分区内,这样在查找时就不用查找其他剩余的分区。因为分区可以在创建了分区表后进行修改,所以在第一次配置分区方案时还不曾这么做时,可以重新组织数据,来提高那些常用查询的效率。 4)、涉及到例如SUM()和COUNT()这样聚合函数的查询,可以很容易地进行并行处理。这种查询的一个简单例子如 “SELECT salesperson_id, COUNT (orders) as order_total FROM sales GROUP BY salesperson_id;”。通过“并行”,这意味着该查询可以在每个分区上同时进行,最终结果只需通过总计所有分区得到的结果。 5)、通过跨多个磁盘来分散数据查询,来获得更大的查询吞吐量。