Diff

  1. Select Edit | Preferences.
  2. Go to Tools > Diff Tools.
  3. Click Add.
  4. File Pattern: *
  5. Select External diff tool.
  6. CommandC:\Program Files (x86)\Beyond Compare 4\bcomp.exe
  7. Arguments/readonly /lefttitle="${leftTitle}" /righttitle="${rightTitle}" "${leftFile}" "${rightFile}"

Merge Pro only

  1. Select Edit | Preferences.
  2. Go to Tools > Conflict Solvers.
  3. Click Add.
  4. File Pattern: *
  5. Select External Conflict Solver.
  6. CommandC:\Program Files (x86)\Beyond Compare 4\bcomp.exe
  7. Arguments"${leftFile}" "${rightFile}" "${baseFile}" /mergeoutput="${mergedFile}"

浓共分为四个步骤 ( 官方有个一键搞定的方案不知为啥失败 ~ ):

1. 使用密码登录并勾选那个生成公钥的选项 ( 会自动的在软件的公钥目录生成 rsa 文件 )

 

2. 查看公钥串并复制public ssh key setting 5

3. 将复制的公钥串插入到目标系统的 ~/.ssh/authorized_keys 中 ( 注意字符串的最后不要有多余的空格 ), 然后保存

 

4.下次登录的时候就可以使用第二项公钥登录, 注意选择 rsa 格式

网络加载资源不仅慢而且代价高。对访问者来说,除了数据传输成本,即使资源可以用并且浏览器可以处理,大量的响应需要客户端和服务器进行多次交互,这会造成延时问题。总之,将之前获取的资源从新利用是性能优化的关键。

好消息是,每个浏览器都具备 HTTP 缓存的能力, 你唯一要做的就是确保每次相应提供了正确的 HTTP 响应头,指导浏览器能在什么时间缓存资源多久。

http-request brower cache

http-request brower cache

当服务器响应时,通常带有一系列的响应头,描述了 content-type, length, 缓存级别和缓存版本号以及其他。比如, 在上图中,服务器返回 1024 字节的响应, 指示客户端缓存 120 秒, 缓存版本号 ( “x234dff” ), 该版本号用于检查在响应过期之后资源是否被修改过。

假设,第一次请求某一资源 A 之后,已经经过了 120 秒, 浏览器再次请求该资源 A。首先, 浏览器检查本地并找到了上次的缓存数据。但是很遗憾,浏览器不能使用这个数据,因为它过期了。此时,浏览器可以从新发送请求来获取该数据文件。但是这样做很不划算,因为该数据文件并没有变更过,重新请求一个已经被缓存的文件毫无道理。

这时 ETag 就排上用场啦。服务器生成并返回一个任意 token, 它可以是该文件一个特定的哈希或者指纹。客户端并不关心这个哈希是如何生存的,它唯一要做的事情就是在下一次请求头中带上这个 token, 服务器据此判断请求的资源如果已经缓存,则不会发送资源给客户端。

http cache control

在上图示的请求中, 客户端自动的提供 If-None-Match: x234dff 请求头。服务器检查该 token 是否与当前资源匹配,如果 token 没有发生变化,服务器会返回一个 304 Not Modified 的响应, 用来告诉浏览器请求的资源没有变更, 可以将过期时间向后推迟 120 秒。注意,无需重新下载,节约了时间和带宽。

作为一个程序员, 要如何利用这一机制呢 ? 浏览器已经为你搞定了绝大多数工作。浏览器自动的检查 token 是否已经存在,   然后在请求上带上这个有效的 token, 并且根据响应在必要的时候更新缓存的时间戳。剩下的唯一需要你确认的事情就是, 服务器提供了必要的 ETag, 检查你的服务器文档查看必要的配置标记。

做性能优化的角度看来, 请求最理想的状态就是不请求服务器: 一个本地的响应副本可以消除网络延迟和数据的传输开销。为达到这个目标, 服务器通过特殊的响应头 Cache-Control 控制浏览器及其他介质如何缓存以及缓存多久独立的响应体来实现。

http cache control ETag

“no-cache” 与 “no-store”

“no-cache” 表示,在请示服务器之前,不能用之前保存本地的响应副本响应后续的同 URL 请求。然而, 如果合适有效的 ETag 存在, no-cache 会发送请求去要求授权允许使用副本进行响应, 这样, 在资源没有变更的情况下, 就可以避免一次下载了。

与之对照的 no-store 就浅显易懂许多, 它不允许浏览器以及其他媒介进行任何版本的缓存 —- 比如, 私人或者银行数据, 客户端每次请求, 服务器每次都会完整的下发一次请求的数据。

“public” 与 “private“

如果响应被标记为 “public”, 则它将被缓存, 即使有 HTTP 认证关联着, 即使响应的状态码不能被正确的缓存。多数时候, ”public“ 不是必要的, 因为特定的 max-age 决定了响应无论如何都会缓存。

作为对照, 浏览器能缓存 private 的相应, 这些相应具有特殊的倾向性, 其他中间媒介不允许进行缓存。举例来说, 浏览器能缓存 private 标记的 HTTP 信息, 但是 CDN 不允许。

”max-age“

这个标记表示的是,从第一次请求成功起,缓存可以重用的最大时间范围,单位是秒。举例来说, “max-age=60” 表明, 响应能被缓存和从用 60 秒。

理想的缓存控制策略

http cache control flow tree

上面的流程图可以描述一个或多个资源的缓存路径。理想情况下, 你应该致力于在客户端缓存尽可能长时间的, 尽可能多的响应, 提供高效的有效期延迟策略。

审计你的网页弄清楚哪些资源能被缓存,确保返回合适的缓存标记 (cache-control  ETag …)。

延迟过期以及更新响应缓存文件。

  • 本地缓存在过期之前可以一直使用
  • 在 URL 中嵌入版本号,可以强制客户端更新服务器资源
  • 每一个应用应该针对性的定义自己的缓存策略来达到性能的最优化

所有的 HTTP 请求都应该在发往服务器之前检查看看是否有对应的本地缓存可以满足, 如果可以,则从缓存中读取响应, 免去了请求服务器的网络延时和数据传输开销。

但是, 如果想更新资源或者强制缓存失效呢 ? 比如, 你告诉过请求者缓存一个 CSS 样式表文件 24 小时, 但是网站设计师刚刚提交了一个这个 CSS 的新版本你希望立刻对所有的用户生效。你要如何通知所有的用户他们的 CSS 过期了, 需要他们更新样式表文件 ? 你只有更新资源的 URL 才能办到。

当浏览器缓存了响应之后, 这个缓存在他们被标记为过期之前都将有效 ( 过期标记: max-age   expires), 又或者缓存被因为一些其他原因丢弃了 —- 比如用户清理了他们的浏览器缓存。总之, 不同的用户将使用着不同版本的文件: 那些刚刚获取了资源的用户使用新资源, 早些时候缓存了旧版本资源的用户使用的旧版本文件。

如何两全其美呢, 客户端缓存还是快速更新 ? 你可以通过更改资源的 URL 来实现强制浏览器下载资源而忽略资源的更新的状态。典型的做法是, 在资源文件的名称中包含文件的哈希或者版本号。

这种定义资源的技巧, 可以让你忽略文件缓存多久, 直接对客户端何时收到新的版本进行完全控制。为了诠释这个, 举例如下:

  • HTML 使用 no-cache 标记, 以为了浏览器每次请求都会延时过期资源, 当内容变更的时候, 浏览器会获取最新的版本。还有, HTML 作为框架,嵌入了包含版本号的 CSS 、JavaScript资源连接: 当这些内容变更的时候, HTML 也应该做对应的变更
  • CSS 允许浏览器或者其他的中间媒介缓存 ( 比如说 CDN ), 然后设置为 1 年过期。注意, 你可以使用”far future expires” 来代替 1 年更加保险, 因为你把文件的版本号嵌入在它的文件名中: 如果 CSS 内容变更, 则 URL 也会随之变化
  • JavaScript 也可以设置 1 年过期, 但是属性是 private 的, 因为它可能包含私人的信息以至于 CDN 不允许缓存
  • 图片被缓存一天, 不带有版本号

ETag, Cache-Control, 唯一 URL 联合起来让你满足各方的需求:  最长的过期时间, 响应的缓存的控制以及按照要求的更新。

没有银弹, 三思慎行,送君几支锦琅妙计:

  • 使用一致的 URL : 如果你给相同的内容定义了不同的 URL, 则该内容会被存取多次。TIP: URL 是大小写敏感的。
  • 确认服务器提供了有效的 token  ( ETag ): 有效的 token 杜绝了当服务器上的资源没有变更的时候, 传输相同的资源的浪费。
  • 甄别哪些资源能被中间媒介缓存: 这些响应的资源对 CDN 或者其他中间媒介等候选者来说都是平等的
  • 决定各种资源的缓存周期: 不同的资源有不同的更新过期时间的需要, 审计并决定各种资源的  max-age 。
  • 为网站决定最佳的缓存优先策略: 带有版本号的资源 URL, 和可控的  HTML 缓存周期, 让客户端的更新完全可控。
  • 变动局部化原则: 有些资源的更新教其他资源频繁许多。如果某一资源 (比如, JavaScript 方法 或一段样式表)的特定部分频繁变动, 考虑将这一部分独立成一个单独的文件,这样剩下的不易变动的部分可以很好的利用缓存优势。

原文:

https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#cache-control

今天忽然发现 nginx 会莫名的挂掉,尝试从起之后,不一会有自己挂掉了。

于是打开 error.log 日志,发现了大量下面这样的报错:

*43185 upstream timed out (110: Conn ection timed out) while reading response header from upstream …

 

于是经过了一番搜索之后得到的配置方法:

在 nginx.conf    server 模块的最上面做如下的配置

client_header_buffer_size 4k; # 客户端请求头缓冲区大小,如果请求头总长度小于 1k 这个配置生效,否则使用下面的  large_alient_header_buffers
large_client_header_buffers 4 16k; # 申请 4 个 16k 大小的内存空间, 当 http request header 超过这个大小的时候,会导致 414 Request URI too large 或 400 bad request 错误
fastcgi_connect_timeout 300;
fastcgi_read_timeout 300;
fastcgi_send_timeout 300;
fastcgi_buffers 4 32k; # 最多申请 4 个 32k 的缓冲空间
fastcgi_buffer_size 4k; # 这个默认值取决于操作系统,通常是一页内存的大小 4k 或者 8k
fastcgi_busy_buffers_size 64k;
fastcgi_temp_file_write_size 128k;

 

 

# 这是我访问 http://hackoops.com 遇到 "404 The plain HTTP request was sent to HTTPS port" 补上的解决方案
server {
    listen 80;
    server_name www.hackoops.com hackoops.com;
    return https://$host$request_uri;
}


# 下面是 ssl 的配置
server {
    listen 443 ssl;
    server_name hackoops.com;
    ssl_certificate 1_你的域名_bundle.crt; # 根据需要修改
    ssl_certificate_key 2_你的域名.key;      # 根据需要修改
    ssl_session_timeout 5m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; #按照这个协议配置
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;#按照这个套件配置
    ssl_prefer_server_ciphers on;
    # ...
}

 

YUI compressor 官方: http://yui.github.io/yuicompressor/

下载的快速入口: https://github.com/yui/yuicompressor/releases/download/v2.4.8/yuicompressor-2.4.8.zip

 

1.   下载

下载 YUI Compressor 到  D:\Program Files (x86)\yuicompressor-2.4.8.jar 位置

 

2.    设置 File Watchers

Settings -> Tools -> File Watchers 中添加一种需要压缩的文件类型 ( 这里以 CSS 为例, 其他类型设置大同小异 )

在 File Watchers 的类型的设置窗口中,在 Program 位置添加更改参数为 YUI Compressor 在磁盘上的路径,其他

保持默认即可 (我的参数为   D:\Program Files (x86)\yuicompressor-2.4.8.jar)

注意:

设置完成后进行一下两步的设置可以减少编辑器的开销 (如果电脑性能坚挺,请自行忽略)

  1.  取消编辑器的自动保存:

进入 File -> Settings ->Appearance & Behavior -> System Settings

2.  取消 File Watcher 的即使同步

当修改的 CSS 保存的时候,会在同级目录生成   xxx.min.css 的文件, 效果图:

开启  webserver 的伪静态设置后,

将 ecshop 根目录的  htaccess.txt 改名为  .htaccess 文件

将 RewriteBase 行的注释打开, 注意如果 ecshop 不是解压在根目录(比如我在开发环境下 www 是 web 根目录, 我的 ecshop 目录为 www/ecshop) 则需要将改行修改为

RewriteBase /ecshop

然后在后台  “商店设置” -> “基本设置”  -> “URL 重写” 处可以配置简单重写,和复杂重写,后者的将商品名称重写到详情页的 URL 中

开发环境: win10 + php5.4 NTS (phpstudy)

git clone git@github.com:hudeyongs/xhprof.git

 

以 thinkphp 使用为例

// 检测 -- 开始
xhprof_enable();

// 待测试的业务代码  -- 开始
require './ThinkPHP/ThinkPHP.php';
// ...
// // 待测试的业务代码  -- 结束

// 检测 -- 停止
// stop profiler
$xhprof_data = xhprof_disable();
$XHPROF_ROOT = str_replace('\\', '/', 'D:\phpStudy\WWW\xhprof');
include_once $XHPROF_ROOT . "/xhprof_lib/config.php";
include_once $XHPROF_ROOT . "/xhprof_lib/utils/xhprof_lib.php";
include_once $XHPROF_ROOT . "/xhprof_lib/utils/xhprof_runs.php";

// save raw data for this profiler run using default
// implementation of iXHProfRuns.
$xhprof_runs = new XHProfRuns_Default();

// save the run under a namespace "xhprof_foo"
$run_id = $xhprof_runs->save_run($xhprof_data, "xhprof_foo");

// 这里会在页面生成一个连接,点击连接可以看到测试的结果
echo "<pre>".
     "<a href='http://xhprof1.com/index.php?run=$run_id&source=xhprof_foo'>".
     "View the XH GUI for this run".
     "</a>\n".
     "</pre>\n";

效果参考: