作者文章: Fenng

Web 前端优化最佳实践之 CSS 篇

Web 前端优化最佳实践第四部分面向 CSS。目前共计有 6 条实践规则。另请参见 Mozilla 开发者中心的文章：Writing Efficient CSS

1. 把 CSS 放到代码页上端 (Put Stylesheets at the Top)

官方的解释我觉得多少有点语焉不详。这一条其实和用户访问期望有关。CSS 放到最顶部，浏览器能够有针对性的对 HTML 页面从顶到下进行解析和渲染。没有人喜欢等待，而浏览器已经考虑到了这一点。

2. 避免 CSS 表达式 (Avoid CSS Expressions)

个人认为通过 CSS 表达式能做到的事情，通过其它手段也同样能做到而且风险更小一些。

3. 从页面中剥离 JavaScript 与 CSS (Make JavaScript and CSS External)

剥离后，能够有针对性的对其进行单独的处理策略，比如压缩或者缓存策略。

4. 精简 JavaScript 与 CSS (Minify JavaScript and CSS)

如果没有 JavaScript 与 CSS 可能更好。但，这是不可能的，SO，尽量小点吧。语法能简写的简写。

5. 使用 <link> 而不是@importChoose <link> over @import

在 IE 中 @import 指令等同于把 link 标记写在 HTML 的底部。而这与第一条相违背。

6. 避免使用Filter (Avoid Filters)

–EOF–
延伸阅读：

Oracle Hint: GATHER_PLAN_STATISTICS

今天 Oracle 公司 Real-World Performance Group 的 Andrew J. Holdsworth 与 Bob Carlin 来阿里作交流。尽管语言沟通上不是很顺畅，还是讨论的不亦乐乎。Andrew 过去也来过阿里巴巴作交流。

Andrew 今天提到了 GATHER_PLAN_STATISTICS ，这已经是短短一段时间第三次遇到这个 Hint 了，上次看到是在 Lewis 的 BLOG：DBMS_xplan in 10g，第二次在 Greg Rahn (也是 Real-World Performance Group 的成员)的 BLOG：Troubleshooting Bad Execution Plans ，以前或许也看到过，可能忽略了。

这个 Hint 在调查执行计划突变的时候非常有用，执行 SQL 的时候收集额外的统计数据。走投无路的时候，或许能用来救急。

另外一个以前忽略的话题是 CARDINALITY 评估错误引起的错误执行计划。事后查了一下，居然还有个 CARDINALITY hint (对，还有个 CARDINALITY Hint! )能直接指定 CARDINALITY 。

一天的讨论学到了两个知识点，已经很不错了. 这一天比较充实的.

–EOF–

下载 PPT : When to Use the Appropriate Database Technology，第二遍阅读的时候，发现这个 PPT 还是很好的。

Facebook 海量数据处理 

对着眼前黑色支撑的天空 /  我突然只有沉默了
我驾着最后一班船离开 / 才发现所有的灯塔都消失了
这是如此触目惊心的 / 因为失去了方向我已停止了
就象一个半山腰的攀登者 / 凭着那一点勇气和激情来到这儿
如此上下都不着地地喘息着 / 闭上眼睛疼痛的感觉溶化了 
--达达乐队《黄金时代》

好几个地方看到这个 Facebook – Needle in a Haystack: Efficient Storage of Billions of Photos，是 Facebook 的 Jason Sobel 做的一个 PPT，揭示了不少比较有参考价值的信息。【也别错过我过去的这篇Facebook 的PHP性能与扩展性】

图片规模

作为世界上最大的 SNS 站点之一，Facebook 图片有多少? 65 亿张原始图片，每张图片存为 4-5 个不同尺寸，这样总计图片文件有 300 亿左右，总容量 540T，天! 峰值的时候每秒钟请求 47.5 万个图片 (当然多数通过 CDN) ，每周上传 1 亿张图片。

图片存储

前一段时间说 Facebook 服务器超过 10000 台，现在打开不止了吧，Facebook 融到的大把银子都用来买硬件了。图片是存储在 Netapp NAS上的，采用 NFS 方式。

图片写入

Facebook_write.png

尽管这么大的量，似乎图片写入并不是问题。如上图，是直接通过 NFS 写的。

图片读取

Facebook.png

CDN 和 Cachr 承担了大部分访问压力。尽管 Netapp 设备不便宜，但基本上不承担多大的访问压力，否则吃不消。CDN 针对 Profile 图象的命中率有 99.8%，普通图片也有 92% 的命中率。命中丢失的部分采由 Netapp 承担。

图中的 Cachr 这个组件，应该是用来消息通知(基于调整过的 evhttp的嘛)，Memcached 作为后端存储。Web 图片服务器是 Lighttpd，用于 FHC (文件处理 Cache)，后端也是 Memcached。Facebook 的 Memcached 服务器数量差不多世界上最大了，人家连 MYSQL 服务器还有两千台呢。

Haystacks –大海捞针

这么大的数据量如何进行索引? 如何快速定位文件? 这是通过 Haystacks 来做到的。Haystacks 是用户层抽象机制，简单的说就是把图片元数据的进行有效的存储管理。传统的方式可能是通过 DB 来做，Facebook 是通过文件系统来完成的。通过 GET / POST 进行读/写操作，应该说，这倒也是个比较有趣的思路，如果感兴趣的话，看一下 GET / POST 请求的方法或许能给我们点启发。

Facebook2.png

总体来看，Facebook 的图片处理还是采用成本偏高的方法来做的。技术含量貌似并不大。不清楚是否对图片作 Tweak，比如不影响图片质量的情况下减小图片尺寸。

–EOF–

此文作者:, 位于 Arch 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

招聘：创业团队找 PHPer

我们将基于千万级的用户群基础开发一个互联网网站平台，前所未有，不同以往，寻求开发高手加盟。

开发语言以 PHP 为主，数据库 MySQL，搜索用 Lucene 实现。

您将在以下环境下工作：

1、一个完全自行开发的高度定制 Full Stack PHP 框架，单一入口方式，全面支持分布式部署的多层架构方案。开发简单，安全高效；

2、开发环境与生产环境完全基于 Slackware Linux，软件版本更新与时俱进，高度定制编译优化，大致列举如下：

  • Nginx 0.7.3
  • PHP 5.2.6
  • MySQL 5.1.25
  • jQuery 1.2.6
  • Xcache 1.2.2
  • Memcached 1.2.5
  • ImageMagick 6.4.2-0
  • Varnish 2.0.0 tech preview 1
  • Lucene 2.3.2

等等，不再列举；

3、一个基于 Lucene 实现的可应付高并发请求的搜索框架，集成简单，伸缩性好。

4、高度注重对前端体验的优化，并在框架内实现了透明化的优化处理；

5、注重任何细节，为了减少 1ms 的程序执行时间，或者为了减少哪怕一个 http 请求，我们可以研究一整天，一直到认为最优化为止；

注：我们认为的典型页面请求的合理执行时间为 20ms 以内；

6、对框架和整体代码进行不断的 review，以理论上的的安全和高效执行的标准来严格要求，多一分不行，少一分也不可；

7、注重国内外技术趋势，乐于参加各种业内聚会。第一期上线后，我们也会总结我们的经验教训，与大家共分享。

目前进展

  • 1、第一期功能需求的开发工作即将完成，只要通过最终的代码检查和上线测试，即可上线；
  • 2、在整体框架下实现的前端体验，不需要任何特殊处理，任何页面均可达到 YSlow 的 95-99 分以上的评价；
  • 3、目前正在为各个功能的跨 PC、手持设备的浏览器页面自适应，绞尽脑汁中。

如果您想加入团队，您需要有以下资格：

  • 1、熟悉 Linux 下的 PHP5 + MySQL5 的开发，对面向对象、三层结构开发方式有深刻的理解；
  • 2、逻辑思维能力清晰，有良好的自我管理能力和团队工作心态，乐于沟通、分享和共同成长；
  • 3、有 XHTML+CSS+Javascript 前端能力者更佳。有 Java、C 或者开源软件开发经验者更佳。

如何认定资格?

  • 1、无任何学历限制，通过我们的面试即可。

薪酬待遇

  • 1、以斐波纳契数列中第六个数字为起点。

有兴趣者，请发您的简历与 zhanghe4(at)163.com 联系。

工作地点：北京东北三环。

以上是代朋友发的招聘信息(如果有笔误是我的事儿)。另外，杭州本地也在帮其它朋友找 PHPer ，有兴趣可以联系我。