1月 252015
 

Firefox 35 was released this week and became the first browser to enable support for the HTTP/2 protocol by default.

The HTTP/2 specification has not been finalised so Firefox actually enabled the Draft 14 version of HTTP/2 but little is expected to change in the final draft. Google is now supporting HTTP/2 draft 14 on its web servers alongside the SPDY protocol giving us a chance to compare the performance of raw HTTPS, SPDY and HTTP/2 on the same web page.

We also updated HttpWatch this week so that it supports HTTP/2 within Firefox. It has new columns to display information about the protocols being used by each request:

New HTTP/2 Columns

The Performance Comparison

The performance test used HttpWatch with Firefox to run a series of simple page load tests against the Google UK home page using the three protocols:

  • Raw HTTPS
  • SPDY/3.1
  • HTTP/2

We switched between the protocols by enabling and disabling the following entries in Firefox’s about:config page:

Controlling FIrefox Protocol Support

Each test was performed in a fresh instance of Firefox with an empty browser cache. Although this testing was simplistic and only used a simple page it does highlight some important differences between the protocols.
Continue reading »

6月 172014
 

Time is money. This somewhat shallow and overused saying fits perfectly well into any on-line business. Users are impatient and every millisecond brings them closer to leaving your website.

If you’ve ever been trying to squeeze more out of hardware you must have come across Nginx (engine x). Nginx usually appears in context of PHP-FPM (FastCGI Process Manager) and APC (Alternative PHP Cache). This setup is often pitched to be the ultimate combo for a web server but what that really means? How much faster a PHP application is going to be on a different web server? I had to check it and the answer as often is – that depends.

I benchmarked three different types of PHP software:

– Large application based on Zend Framework 1
– Small PHP script
– WordPress

The software was hosted on Amazon EC2 large instance. All benchmarks were run from EC2 Tiny instance to be as close as it possible to the web server.

To make sure I benchmark web servers instead of disk I/O I set all logs to go to memory (/dev/shm). PHP sessions were directed to memcached.
Both servers were using Zend Optimizer Plus with opcache.revalidate_freq set to 1 hour. I use Zend Optimizer because APC wasn’t stable for me with PHP 5.4.x.
If you aren’t familiar with PHP accelerators they convert PHP scripts into byte code and keep them in shared memory. That brings significant boost of performance (40-90%) because PHP scripts don’t have to be read from a disc and parsed on every request. Using the accelerator helped me removing I/O from the equation.

It’s very important to make sure Apache won’t read .htaccess. You can achieve it by setting Allow Overwrite to none. Parsing htaccess in real time will drop performance on the Apache side. It’s recommended to not use this file in production environment. Continue reading »

12月 192012
 

1.重要的就是RAM,对应到参数设置,就是要设置合理的Maxclients值,避免进程运行在swap里。

2.HostnameLookups 要设置为Off,避免处理每次请求前还要查询dns

3.避免使用SymLinksIfOwnerMatch,即除非必要,一般最好全部设置成FollowSumLinks

Options FollowSymLinks

4.避免使用AllowOverride,即除非必要,则最好全部设置为None Continue reading »

10月 152011
 

话说nginx在大压力的环境中比apache的表现要好,于是下载了一个来折腾一下。

下载并编译安装,我的编译过程有点特别:

1。去除调试信息,修改$nginx_setup_path/auto/cc/gcc这个文件,将 CFLAGS=”$CFLAGS -g”  这一行注释掉。

2。由于仅测试WEB服务器的性能,所以不安装FastCGI。 Continue reading »

7月 142011
 

原则1 减少HTTP请求数

构造请求、等待响应需要时间,因此请求数量越少越好。减少请求的总体思路就是合并资源,减少显示一个页面需要的文件数。

1. Image Map

通过设置<img>标签的usemap属性与使用<map>标签可以在一幅图片上切分出多个区域,指向不同的链接。比起使用多幅图片分别构造链接减少了请求数。

2. CSS Sprite(CSS贴图整合/贴图拼合/贴图定位)

通过设置元素的background-position样式做到。一般用于界面图标。典型的可以参考TinyMCE编辑器上方的那些小按钮。多个小图实质是从一个统一的大图通过不同的偏移量裁剪而来,这样加载界面上的众多按钮实际上只要请求一次(请求大图一次),从而减少HTTP请求数。 Continue reading »

4月 272011
 

10.6 选择一种表类型

用MySQL,当前(版本 3.23.5)你能从一个速度观点在4可用表的格式之间选择。

静态MyISAM

这种格式是最简单且最安全的格式,它也是在磁盘格式最快的。速度来自于数据能在磁盘上被找的难易方式。当所定有一个索引和静态格式的东西时,它很简单,只是行长度乘以行数量。而且在扫描一张表时,用每次磁盘读取来读入常数个记录是很容易的。安全性来自于如果当写入一个静态MyISAM文件时,你的计算机崩溃,myisamchk能很容易指出每行在哪儿开始和结束,因此它通常能回收所有记录,除了部分被写入的那个。注意,在MySQL中,所有索引总能被重建。

动态MyISAM

这种格式有点复杂,因为每一行必须有一个头说明它有多长。当一个记录在更改时变长时,它也可以在多于一个位置上结束。你能使用OPTIMIZE table或myisamchk整理一张表。如果你在同一个表中有象某些VARCHAR或BLOB列那样存取/改变的静态数据,将动态列移入另外一个表以避免碎片可能是一个好主意。

压缩MyISAM

这是一个只读类型,用可选的myisampack工具生成。 Continue reading »

4月 272011
 

10.3 使你的数据尽可能小

最基本的优化之一是使你的数据(和索引)在磁盘上(并且在内存中)占据的空间尽可能小。这能给出巨大的改进,因为磁盘读入较快并且通常也用较少的主存储器。如果在更小的列上做索引,索引也占据较少的资源。

你能用下面的技术使表的性能更好并且使存储空间最小:

尽可能地使用最有效(最小)的类型。MySQL有很多节省磁盘空间和内存的专业化类型。

如果可能使表更小,使用较小的整数类型。例如,MEDIUMINT经常比INT好一些。

如果可能,声明列为NOT NULL。它使任何事情更快而且你为每列节省一位。注意如果在你的应用序中你确实需要NULL,你应该毫无疑问使用它,只是避免缺省地在所有列上有它。

如果你没有任何变长列(VARCHAR、TEXT或BLOB列),使用固定尺寸的记录格式。这比较快但是不幸地可能会浪费一些空间。见10.6 选择一种表类型。

每张桌子应该有尽可能短的主索引。这使一行的辨认容易而有效。

对每个表,你必须决定使用哪种存储/索引方法。见9.4 MySQL表类型。也可参见10.6 选择一种表类型。

只创建你确实需要的索引。索引对检索有好处但是当你需要快速存储东西时就变得糟糕。如果你主要通过搜索列的组合来存取一个表,以它们做一个索引。第一个索引部分应该是最常用的列。如果

你总是使用许多列,你应该首先以更多的副本使用列以获得更好的列索引压缩。

如果很可能一个索引在头几个字符上有唯一的前缀,仅仅索引该前缀比较好。MySQL支持在一个字符列的一部分上的索引。更短的索引更快,不仅因为他们占较少的磁盘空间而且因为他们将在索引缓存中给你更多的命中率并且因此有更少磁盘寻道。见10.2.3 调节服务器参数。 Continue reading »

4月 272011
 

10.2.3 调节服务器参数
你能用这个命令得到mysqld服务器缺省缓冲区大小:

shell>; mysqld –help

这个命令生成一张所有mysqld选项和可配置变量的表。输出包括缺省值并且看上去象这样一些东西:

Possible variables for option –set-variable (-O) are:
back_log              current value: 5
connect_timeout       current value: 5
delayed_insert_timeout  current value: 300
delayed_insert_limit  current value: 100
delayed_queue_size    current value: 1000
flush_time            current value: 0
interactive_timeout   current value: 28800
join_buffer_size      current value: 131072
key_buffer_size       current value: 1048540
lower_case_table_names  current value: 0
long_query_time       current value: 10 Continue reading »