yahoo的关于大型网站前端性能加速的实践指南
[
2009/04/27 17:49 | by askwan ]
2009/04/27 17:49 | by askwan ]
很早就看到yahoo性能团队的这篇文章
http://developer.yahoo.com/performance/rules.html
逢今日再读，仍旧令人拍案叫绝，若大中型网站，特别是以静态内容为主的网站，能做到其十之八九，
那我想访问响应性能速度定能提升几个档次。
这段时间 自觉需要好好学习研究一下这些方法 希望将来尽力用得上
然而这个必然需要需要前端开发工程师，程序开发设计人员和系统运维相关人员通力合作才行
顺便做个自己的土笔记 留以后备忘。
大致从文章看下来说 这篇文章中一共34种方法 分为7个类别
分别是
1.Content
2.Server
3.Cookie
4.Css
5.Javascript
6.Image
7.Mobile
几乎牵涉到了网站前端的方方面面 实为猛料！
这上34种实践方法 如下 ：
http://developer.yahoo.com/performance/rules.html
逢今日再读，仍旧令人拍案叫绝，若大中型网站，特别是以静态内容为主的网站，能做到其十之八九，
那我想访问响应性能速度定能提升几个档次。
这段时间 自觉需要好好学习研究一下这些方法 希望将来尽力用得上
然而这个必然需要需要前端开发工程师，程序开发设计人员和系统运维相关人员通力合作才行
顺便做个自己的土笔记 留以后备忘。
大致从文章看下来说 这篇文章中一共34种方法 分为7个类别
分别是
1.Content
2.Server
3.Cookie
4.Css
5.Javascript
6.Image
7.Mobile
几乎牵涉到了网站前端的方方面面 实为猛料！
这上34种实践方法 如下 ：
- Make Fewer HTTP Requests
- Use a Content Delivery Network
- Add an Expires or a Cache-Control Header
- Gzip Components
- Put Stylesheets at the Top
- Put Scripts at the Bottom
- Avoid CSS Expressions
- Make JavaScript and CSS External
- Reduce DNS Lookups
- Minify JavaScript and CSS
- Avoid Redirects
- Remove Duplicate Scripts
- Configure ETags
- Make Ajax Cacheable
- Flush the Buffer Early
- Use GET for AJAX Requests
- Post-load Components
- Preload Components
- Reduce the Number of DOM Elements
- Split Components Across Domains
- Minimize the Number of iframes
- No 404s
- Reduce Cookie Size
- Use Cookie-free Domains for Components
- Minimize DOM Access
- Develop Smart Event Handlers
- Choose <link> over @import
- Avoid Filters
- Optimize Images
- Optimize CSS Sprites
- Don't Scale Images in HTML
- Make favicon.ico Small and Cacheable
- Keep Components under 25K
- Pack Components into a Multipart Document
Sun ，还是下山了！！
Solaris，Java，Sunmicrosystems 这些都是每个IT人都无比尊敬的字眼，08年收购Mysql，还让人精神一振,
如今这一切要改头换面了……
Oracle 真是一条超级具攻击性的鲨鱼，这些年一路 狼吞虎咽，BEA ，INNODB，SUN , Mysql……，
我们不禁要开始猜想了，下一个被吃掉的会是谁呢？RedHat？ Vmware? Novell？ IBM? Microsoft？
Mysql的前途在那里？因为开源事业发展起来的东西现在都一股脑子的全部都被商业公司控制，mysql的未来？
资本世界的games，说不清楚了，但也许Sun被Oracle收购不见得就是坏事，咱们还是拭目以待吧！
Solaris，Java，Sunmicrosystems 这些都是每个IT人都无比尊敬的字眼，08年收购Mysql，还让人精神一振,
如今这一切要改头换面了……
Oracle 真是一条超级具攻击性的鲨鱼，这些年一路 狼吞虎咽，BEA ，INNODB，SUN , Mysql……，
我们不禁要开始猜想了，下一个被吃掉的会是谁呢？RedHat？ Vmware? Novell？ IBM? Microsoft？
Mysql的前途在那里？因为开源事业发展起来的东西现在都一股脑子的全部都被商业公司控制，mysql的未来？
资本世界的games，说不清楚了，但也许Sun被Oracle收购不见得就是坏事，咱们还是拭目以待吧！
mysql replication多源服务器下的auto_increment冲突问题
[ 2009/04/25 08:05 | by askwan ]
2009/04/25 08:05 | by askwan ]
在以前的文章中《mysql同步复制M-M(master master)模式》 里，配置了这样一种双向同步机制，两台服务器都可以保持同步并且都可以读写，但是这种配置方案还不完善，生产上实际可能出现很多问题，最突出的一点就是库中某些表有自增长auto_increment字段的时候，容易产生键值冲突错误！
熟读过mysql的replication的docs，我们发现mysql其实对这个主键冲突已经有相应的解决方案，只是互联网很多配置过程都没有加进去这点，直接拿来用，出问题的概率是比较大的。
mysql的服务器变量auto_increment_increment【增长值】和auto_increment_offset【偏移量】可以协调多主服务器复制和AUTO_INCREMENT列。并且每个变量有一个默认的(并且是最小的)值1，有一个最大值65,535。把这些变量设置为非冲突的值，例如在同一个表插入新行时，多主服务器配置主的服务器就不会发生AUTO_INCREMENT值冲突，这里就可以解决这个问题，比如就这里的两台服务器A和B为例：
在A的[mysqld]字段下增加：
在B的[mysqld]字段下增加:
这样，两台服务器同时有数据插入到有auto_increment的字段是，就不会发生冲突，一个简单的例子就是A下插入的ID为1，3，5，7……，以此类推，B下插入的ID就为2，4，6，8，……，以此类推，但即使这样，mysql建议也不要使用这种双向同步机制，主要的原因是目前的同步还不支持在多源服务器上同步更新锁协议，从而无法保证数据库数据操作的“原子性”问题。那么本文就算对上篇mysql复制文章的补充。
----------End-----------
熟读过mysql的replication的docs，我们发现mysql其实对这个主键冲突已经有相应的解决方案，只是互联网很多配置过程都没有加进去这点，直接拿来用，出问题的概率是比较大的。
mysql的服务器变量auto_increment_increment【增长值】和auto_increment_offset【偏移量】可以协调多主服务器复制和AUTO_INCREMENT列。并且每个变量有一个默认的(并且是最小的)值1，有一个最大值65,535。把这些变量设置为非冲突的值，例如在同一个表插入新行时，多主服务器配置主的服务器就不会发生AUTO_INCREMENT值冲突，这里就可以解决这个问题，比如就这里的两台服务器A和B为例：
在A的[mysqld]字段下增加：
auto-increment-increment = 2
auto-increment-offset = 1
auto-increment-offset = 1
在B的[mysqld]字段下增加:
auto-increment-increment = 2
auto-increment-offset = 2
auto-increment-offset = 2
这样，两台服务器同时有数据插入到有auto_increment的字段是，就不会发生冲突，一个简单的例子就是A下插入的ID为1，3，5，7……，以此类推，B下插入的ID就为2，4，6，8，……，以此类推，但即使这样，mysql建议也不要使用这种双向同步机制，主要的原因是目前的同步还不支持在多源服务器上同步更新锁协议，从而无法保证数据库数据操作的“原子性”问题。那么本文就算对上篇mysql复制文章的补充。
----------End-----------
公司与上海电信某3A机房带宽租用合同到期 本周和下周 将搬迁所有在电信机房的服务器 这两天都在连夜忙着转移数据
忙碌的日子……
忙碌的日子……
