都2021移動端適配你還用flexible.js嗎?vw+rem一行代碼搞定

了解一下rem

rem(font size of the root element)是相對長度單位。相對於根元素(即html 元素)font-size 計算值的倍數。

適配原理:將px 替換成rem,動態修改html 的font-size 適配。它可以很好的根據根元素的字體大小來進行變化,從而達到各種屏幕基本一致的效果體驗

u 同學給的設計稿

常見的設計圖寬度,當然也可以是其他的寬度,比如720 像素的

  1. 375 iPhone7
  2. 750 二倍圖
  3. 320 iPhone5
  4. 640 二倍圖

為什麼給的是375?因為這個是iPhone7 的寬度,

也就是說最低兼容到375 像素的屏幕。(低於375 佈局可能會亂)

其他的同理

1. vw + rem 方案

如果效果圖是375px 的,

html 的style 屬性的font-size 設置為26.666666vw

css 中20px 改寫為0.2rem 即可

<!DOCTYPE html>
<html lang="en" style="font-size: 26.666666vw">
    <head>
        <meta charset="UTF-8" />
        <!--
        下面一行代码的解析:
        width=device-width 内容宽度 等于 设备宽度,换句话说 网页宽度为设备宽度
        initial-scale=1.0 初始缩放比等于1.0倍,换句话说 网页初始化缩放比为1.0 就是默认不缩放
    -->
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <meta http-equiv="X-UA-Compatible" content="ie=edge" />
        <title>Document</title>
        <style>
            /* 设置 div 为宽度100px高度18px */
            .app-main {
                /* 移动端写法 */
                width: 1rem;
                height: 0.18rem;
                /* 
                PC端写法
                width: 100px;
                height: 18px; */
            }
        </style>
    </head>
    <body>
        <div class="app-main"></div>
    </body>
</html>
复制代码

為什麼是26.666666vw?得了解下面幾個問題

-   1. 什么是 viewport?
-   2. 为什么要用它?
-   3. 怎么用?
-   4. `vw`、`vh`是什么?

答:

1. 什么是 viewport?
   [MDN viewport](https://developer.mozilla.org/zh-CN/docs/Web/CSS/Viewport_concepts)的解析是
   视口(viewport)代表当前可见的计算机图形区域。在 Web 浏览器术语中,通常与浏览器窗口相同,但不包括浏览器的 UI, 菜单栏等——即指你正在浏览的文档的那一部分。

2. 用它来移动端适配,兼容不同的设备,当然不局限于移动端,这里只讨论移动端

3. 只需要在`head`中定义 `<meta name="viewport" content="width=device-width, initial-scale=1.0" />`就行,具体如下:

`
<head>
    <meta charset="UTF-8" />
    <!--
        下面一行代码的解析:
        width=device-width 内容宽度 等于 设备宽度,换句话说 网页宽度为设备宽度
        initial-scale=1.0 初始缩放比等于1.0倍,换句话说 网页初始化缩放比为1.0 就是默认不缩放
    -->
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta http-equiv="X-UA-Compatible" content="ie=edge" />
    <title>Document</title>
</head>
`

4.  `vw` 是视口宽度的一个单位,viewport width 的简称,根据 viewport 相关定义,
    已经定义好了的,PC 端 100vw 就等于浏览器的宽度,移动端 100vw 就是设备的宽度(按照上面的 width=device-width)
    `vh` 同理,是视口高度,viewport height 的简称,100vh 就是可视窗口的高度
复制代码

了解完上面的知識點,我們可以回答

為什麼font-size 設置成26.666666vw?

设计图的宽度 = 设备宽度
假如 设计图的宽度为 375px,当然可以是其他的,这里是一个假如,如果是640,750就把375换成对应的数值按照以下方法换算就行就行
因为
    375px = 100vw
那么
    1px = 100 / 375 vw = 0.26666666666666666vw(约等于)

为了方便计算,放大一百倍,精确到6位,只能下取舍,因为上取舍,计算宽度的时候会大于页面宽度,从而出现滚动条
故:
    100px = 26.666666vw(约等于)

又因为给 html 标签设置 font-size 为 26.666666vw (约等于)

1rem为font-size的大小

所以:
    1rem = 100px
    0.2rem = 20px
也就是说:
    设计图上的 12px 换算成rem就是0.12rem,20px就写成0.2rem即可
复制代码

優點:不需要引入新的js,一行代碼搞定適配問題缺點:瀏覽器兼容性差,IE9 以下不支持,但現代瀏覽器,特別是移動端,基本都支持


可以參考:

設計圖大小(單位px) html 的font-size(單位vw) 備註
375 26.666666 效果圖20px,代碼應該寫0.2rem
750 13.333333 效果圖20px,代碼應該寫0.2rem
320 31.25 效果圖20px,代碼應該寫0.2rem
640 15.625 效果圖20px,代碼應該寫0.2rem

2. flexible 方案,(阿里)

lib-flexible的github 上有著這樣的一句話。

由於 viewport 單位得到眾多瀏覽器的兼容,lib-flexible這個過渡方案已經可以放棄使用,不管是現在的版本還是以前的版本,都存有一定的問題。建議大家開始使用viewport 來替代此方案。vw的兼容方案可以參閱《如何在Vue 項目中使用vw 實現移動端適配》一文。

我們可以得到一個很明確的信息,lib-flexible 這個方案已經被放棄使用了,我們可以去擁抱 vw 的那套實現方案。

3. 基於flexible 的hotcss方案

圖片上傳在ios中click事件無效

addImage方法中的this.input.click()在ios中無法生效。
網上提供的幾種解決方法,供大家參考:

1、​將click 事件直接綁定到目標​元素(​​即.target)上;
2、將目標​元素換成a 或者button 等可點擊的​元素;
​3、將click 事件委託到​​​​​非document 或body 的​​父級元素上;
​4、給​目標元素加一條樣式規則cursor: pointer。

我最後採用了直接調用dom的原生方法觸發input的點擊事件

addImage = () => {
const event = document.createEvent(‘MouseEvents’);
event.initMouseEvent(‘click’,false,false);
this.input.dispatchEvent(event)
};

upgrade tomcat6xx to tomcat7xx with 3 problem3

今天把tomcat从6.0.18升级到7.0.25,发现了两个问题

问题1

java.lang.ClassNotFoundException: org.apache.catalina.mbeans.ServerLifecycleListener

发现居然找不到这个类,然后把catatina.jar下载下来反编译一看mbenas这个文件夹居然是空的

解决办法

6.0.18以前,conf/server.xml里面的配置有这项

注释掉就可以了

问题2

严重: Begin event threw exception
java.lang.IllegalArgumentException: taglib definition not consistent with specification version

tomcat 6.0.18里面的web.xml里面的tab配置如下
http://java.sun.com/jstl/core
/WEB-INF/c.tld

tomcat 7.0.25里面web.xml的tag配置应该如下所示

http://java.sun.com/jstl/core
/WEB-INF/c.tld

 

问题2

Aug 11, 2015 10:41:11 AM org.apache.jasper.compiler.JDTCompiler$1 findType
SEVERE: Compilation error
org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException

 

原来是JDK的版本问题,系统自是OpenJDK 1.8,

要改回OpenJDK 1.6

yum install java-1.6.0-openjdk

用bash解决hadoop的磁盘空间检查性能问题

项目使用的hadoop已经存放了3000W+的文件,

为了节省成本,当时抢建平台时,使用了组装服务器+普通硬盘

hadoop每次做du操作都非常耗时,于是把hadoop代码改了一个

使用一个bash脚本替代原来du操作。

bash:

#/bin/sh
mydf=$(df $2 | grep -vE ‘^Filesystem|tmpfs|cdrom’ | awk ‘{ print $3 }’)
echo -e “$mydf\t$2”

java:hadoop\src\core\org\apache\hadoop\fs\DU.java:168行的toString()及getExecString()方法

public String toString() {
return
“mydu -sk ” + dirPath +”\n” +
used + “\t” + dirPath;
}

protected String[] getExecString() {
return new String[] {“mydu”, “-sk”, dirPath};
}

改造后,原来的du操作其他不耗时。

只是存在统计不准确的问题,不过并不影响hadoop运作。

NginX 1.2.0 versus Resin 4.0.29 performance tests

Recently, we decided to spend some extra time improving Resin’s performance and scalability. Since we like challenges, we set a goal of meeting or beating nginx, a fast C-based web server. When working on performance, we use benchmarks to see which proposed changes improve Resin’s performance, and which proposed changes do not. The autobench/httperf benchmark is particularly interesting because it simulates high load rates and exposes scalability issues better than some other benchmarks like ab. After completing the Resin performance work, it turned out that we exceeded our goal and were actually able to beat nginx, and thought we’d share our results.

We have recently run some performance benchmarks comparing Resin 4.0.29 versus NginX 1.2.0. These benchmarks show that Resin Pro matches or exceeds NginX’s throughput.

We tested 0k (empty HTML page), 1K, 8K and 64K byte files. At every level Resin matched or exceeded NginX performance.

 

 

Contents

Benchmark tools

The benchmark tests used the following tools:

  • httperf
  • AutoBench

 

httperf

httperf is tool produced by HP for measuring web server performance. The httperf tool supports HTTP/1.1 keepalives and SSL protocols.

 

AutoBench

Autobench is a tool for automating the process of performing a comparative benchmark test against two a web servers. Autobench uses httperf. Autobench runs httperf against each host. AutoBench increases the number of requests per seconds on each iteration. AutoBench delivers output in a format that can be easily consumed by spreadsheet tools. AutoBench has a mode where it can drive multiple clients against a set of servers to minimize the possibility of testing your client throughput instead of server throughput. The command autobenchd is used to run a daemon on client machines. The autobench_admincommand drives many clients to run test at same time by communicating with autobenchd.

Setup Overview

Setup benchmark diagram.png

Configuration

The only change that was made was the worker_processes were set to 8 for NginX to improve throughput.

Hardware Software Specifications

Client HW/OS specs:

  • i7 4 core / 8 HT, 2.8 GHZ, 8Meg Cache, 8 GB RAM.
  • Ubuntu 12 / Linux Kernel 3.2.0-26-generic

Server HW specs:

  • i7 4 core / 8 HT, 2.8 GHZ, 8Meg Cache, 8 GB RAM.
  • Ubuntu 12 / Linux Kernel 3.2.0-26-generic

Test software:

  • Autobench 2.1.1
  • httperf 0.9.0

Software under test:

  • Resin Pro 4.0.29
  • nginx 1.2.0

0k test

We want to make sure Resin can handle as many concurrent connections as possible without glitches or blocking. The tiny 0k file is a good test for high concurrency, because it spends less time on network overhead and more time stressing the threading and internal locks. Because we used an 8-core machine, we can be certain that we’re avoiding unnecessary locks or timing problems.

For most sites, the small file stress test simulates heavy ajax use, and small file use. As sites become more interactive, this small file test becomes ever more important.

As a comparison of a threaded Java web server with an event-based C web server, the 0k test is a good test of the threading and event manager dispatch. Because most of the time in the test is establishing a connection or switching between requests at the very highest rate, both the threading and the event management get a tough work-out.

Command Line Arguments

0k.sh

./admin.sh 300000 2000 20000 1000 0k

admin.sh

autobench_admin
--clients xen:4600,lancre:4600
--uri1 /file_$5.html
--host1 ch_resin --port1 8080
--uri2 /file_$5.html
--host2 ch_nginx --port2 80
--num_conn $1
--num_call 10
--low_rate $2
--high_rate $3
--rate_step $4
--timeout 3
--file out_con$1_start$2_end$3_step$4_$5.tsv

Above is used to setup 300,000 connections at a rate of 20,000 to 200,000 requests per second. Each iteration increases the rate by 10,000 from 20,000 to 200,000.

0k html file file_0k.html

 <html> 
 <body>
 <pre></pre>
 </body>
 </html>

0k full Results for 0K test

Resin nginx 0k full2.png

Resin nginx response time.png

Nginx resin 0k IO throughput.png

Nginx resin errors 0k.png

 

1K test

Command line

1k.sh

./admin.sh 200000 1000 10000 250 1k

 

admin.sh

autobench_admin
--clients xen.caucho.com:4600,lancre.caucho.com:4600 
--uri1 /file_$5.html
--host1 ch_resin --port1 8080
--uri2 /file_$5.html
--host2 ch_nginx --port2 80
--num_conn $1
--num_call 10
--low_rate $2
--high_rate $3
--rate_step $4
--timeout 3
--file out_con$1_start$2_end$3_step$4_$5.tsv

 

1k.html

<html>
<body>
<pre>
0 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 
1 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 
2 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 
3 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 
4 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 
5 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 
6 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 
7 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 
8 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 
9 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 
</pre>
</body> 
</html>

1k full Results for 1K test

Resin nginx 1k requests per second.png

Resin nginx 1k response time.png

Resin nginx IO 1k.png

Resin nginx 1k errors.png

64 K test results

Result

PUT IMAGES HERE

64k.sh

./admin.sh 10 50 1500 50 64k
====admin.sh====
<pre>
autobench_admin
--clients xen.caucho.com:4600,lancre.caucho.com:4600 
--uri1 /file_$5.html
--host1 ch_resin --port1 8080
--uri2 /file_$5.html
--host2 ch_nginx --port2 80
--num_conn $1
--num_call 10
--low_rate $2
--high_rate $3
--rate_step $4
--timeout 3
--file out_con$1_start$2_end$3_step$4_$5.tsv

64 test file

<html>
<body>
<pre>
0
0 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789
1 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789
2 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789
3 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789
4 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789
5 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789
6 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789
7 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789
8 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789
9 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789 0123456789

[Repeats 63 more times, there are 0-7 blocks repeated 0-7 times]

</pre>
</body>
</html>

kingston sd card vs toshiba sd card

前段時間買了一張kingston class10 32G 的SD card,放在D7000上,發現沒有原來的TOSHIBA CLASS4 8G的速度快,於是就個測試工具測試咗一下,O曬嘴。。。。。。

兩張CARD的前後合照:
TOSHIBA是09年買的,KINGSTON是前天買的;都是MAKE IN JAPAN。

KINGSTON的讀寫測試:

TOSHIAB的讀寫測試:

這說是為什麽KINGSTON這麽便宜的原因了;天下沒有又便又好的東西,別相信什麽 CLASS10標準;然後很多廠家都寫住CLASS10,但實際讀寫速度肯定大打折扣。當然如果你追求是不速度而是容量和價錢,二三線廠家嘅SD CARD是首先。

測試工具:USB Flash Benchmark

Comparing HTML5 Mobile Web Framework

Comparing HTML5 Mobile Web Framework

It’s been an exciting year for the mobile Web. Adoption of HTML5 and CSS3, improved performance in mobile browsers, and an explosion of mobile app frameworks mean it’s more feasible than ever to create rich, interactive Web experiences for mobile devices. Using a wrapper like PhoneGap, you can distribute them via the native app stores for iPhone, iPad, and Android —targeting multiple platforms with a single code-base.

Mobile Web developers have a plethora of frameworks to do the heavy lifting for them: animated transitions, toolbars, buttons, list views, even offline storage. Most of these are new and the landscape is shifting rapidly. I have gone through many of the Mobile web frameworks and compared and analyzed them. And here is something what I found:

jQTouch is easy to use and relatively well-documented. It’s featured in the excellentBuilding iPhone Apps with HTML, CSS, and JavaScript. jQTouch takes a progressive-enhancement approach, building an iPhone-like experience on top of your appropriately-constructed HTML. It’s simple, providing a basic set of widgets and animations and just enough programmatic control to permit more dynamic behavior.

But even in my simple test app there were performance issues. Page transitions can be jumpy or missing, and there are periodic delays in responding to tap events. And while the project is technically active, the original author has moved on and development seems to have slowed.

jQTouch is available under the permissive MIT License, one of my favorite open source licenses.

jQuery Mobile was the new kid on the block. Announced in August 2010, it’s quickly progressed to a very functional Alpha 2 and now on February 28 it comes with a JQM 1.1.0. It takes a similar – but more standards-compliant – approach to jQTouch and feels very much like that framework’s successor, with a broader array of UI controls and styles.

jQuery Mobile’s performance is variable (though better than that of jQTouch), particularly in responding to tap events rendering animations. It also lacks a small number of key programmatic hooks that would permit easy creation of more dynamic apps. For instance, there’s an event that triggers when a page is about to load (i.e. slide into view) but no way to tell the associated handler code what UI element resulted in the page switch, or to pass additional information to that handler. I was able to create workarounds but hope that future versions will take a cue from jQTouch and build out this functionality a little more.

In the 2011 end and the starting of 2012 the JQM catched the eye of lot of web geeks. And it is the most improving framework in the Mobile Web industry.

jQuery Mobile is available under either the MIT or the GPL2 license.

Sencha Touch is the mobile counterpart to the Ext JS framework. Its approach differs significantly from jQTouch and jQuery Mobile: instead of enhancing preexisting HTML, it generates its own DOM based on objects created in JavaScript. As such, working with Sencha feels a little less “webby” and a little more like building apps in other technologies like Java or Flex. (It’s also a bit more like YUI than like jQuery.) I personally prefer the progressive enhancement approach, but it really is a matter of preference.

Sencha is far more extensive than its competitors, with a vast array of UI components, explicit iPad support, storage and data binding facilities using JSON and HTML5 offline storage, and more. (It’s very cool to manipulate app data in one of Sencha’s data structures and watch the corresponding list update in real time.) It’s also the only Web framework I’ve seen with built-in support for objects that stay put (like a toolbar) while others scroll (like a list).

For all that apparent extra weight, Sencha performed noticeably better and more reliably than either jQTouch or jQuery Mobile in my tests, with the exception of initial load time.

When working with a library or framework, it’s usually counterproductive to “fight the framework” and do things your own way. Given how extensive Sencha Touch is, that means your app will probably end up doing just about everything the Sencha way. I’d originally usedWebKit’s built-in SQLite database for offline storage but ultimately eliminated both complexity and bugs by moving that functionality into Sencha’s data stores.

The documentation, while extensive, has odd holes. Between those and the sheer size of the framework, I spent a lot of time fighting bugs that were difficult to trace and to understand. Responses to my questions in the developer forums were more frequent and helpful than with the other frameworks, but still ultimately insufficient. Sencha provides paid support starting at $300/year; I strongly considered purchasing it but oddly, their response to my sales support inquiries was incredibly underwhelming given my interest in sending them money.

Sencha Touch is available under the GPL3; under a somewhat confusing set of exceptions to the GPL that seem similar to the LGPL; or under a free commercial license.

Much like Sencha Touch, Appcelerator’s Titanium Mobile allows you to write apps using a JavaScript API. But unlike Sencha, it compiles most of your code into a native iPhone or Android app. That means it isn’t really a Web framework, but a compatibility layer or compiler. (Note that its cousin Titanium Desktop is Web-based, allowing you to write HTML/JS applications that run inside a native wrapper on the desktop.)

So Titanium allows Web developers to produce high-performance, easily skinnable native apps using JavaScript and a little XML, i.e. without learning Objective-C or Cocoa Touch. My simple test app blew away the true Web frameworks in terms of performance, and wasn’t much harder to put together.

But that advantage is also its greatest disadvantage: you can only target the platforms Titanium supports, and you’re tied to their developer tools. As if to prove this point, my test app quickly got into a state where it wouldn’t launch on the iPhone. Titanium doesn’t include much of a debugger; Titanium projects can’t be run and debugged in XCode; and it ran fine in the simulator, leaving me with no real way to attack the problem.

Rebuilding my app on three of these four frameworks was tedious but educational. I like jQTouch but have trouble believing it will evolve much from here. I’m rooting for jQuery Mobile for its simplicity and its very Web-centric approach to development…but it lacks a few key features and doesn’t perform as well as Sencha Touch.

It’s unfair to compare an Alpha 2 product with a 1.0 one, except in one respect: I need something now. Which brings me to Sencha Touch. I was initially impressed with its performance and breadth, but put off by its development style. As I’ve dug in, the holes in its documentation have been frustrating but the breadth has continued to impress me, and I’ve gotten more used to the coding style. The option for paid support is tempting, and I’d probably buy it if they’d answer my emails. But for now, Pints is a Sencha-based app.

I haven’t answered the big question: can a Web-based app really hold its own alongside native apps? And if so, are the challenges of getting it there worth the benefit of a single codebase?

The answer is YES ! Because the Web-based apps needs the core knowledge of HTML5 and CSS3.

Asterisk

Asterisk是一款实现电话用户交换机(PBX)功能的自由软件、开源软件。Asterisk提供完善PBX功能,可以连接多种不同的电话终端,包括普通电话机,IP电话机,软电话等,支持多种主流的IP电话协议和系统接口。软件名称Asterisk-星号(*),在Unix(包括Linux)和DOS操作系统中是通配符,用来在查找中适配任何字符,寓意该软件广泛的适用性。
Asterisk软件提供很多以前只有昂贵的专业PBX系统才支持的功能,比如:语音信箱,会议电话,交互式语音应答和自动电话转接等。由于该软件开放的性质,用户可以灵活的配置方便的扩展系统的功能,甚至编程开发自己所需功能的模块。Asterisk通常都运行在Linux操作系统下,当然它也可以在其他系统,如BSD,Windows或OS X下编译并安装。
Asterisk服务器不需要任何特殊的硬件即可提供VoIP的服务,只需服务器有网络连接即可。它支持主流VoIP协议,包括会话发起协议(SIP)、H.323,既可作为IP电话服务器也可以作IP电话和PSTN之间的转接。Asterisk系统还设计了一个新协议,IAX,用于在Asterisk服务器之间维护话路通道。如果需要连接普通电话或PSTN中继线,运行Asterisk的服务器则需要安装相应的硬件接口板。许多厂商都生产用于连接普通电话、T1、E1中继线、ISDN等的接口板。
由于是自由软件且具有丰富的系统功能,Asterisk提供给用户一个廉价并功能强大的PBX解决方案。它被越来越多的用于代替传统专用的PBX,或被用于跨国VoIP电话以节省长途费用。一些国家的VoIP电话公司已经开始支持Asterisk,提供IAX2接口或允许用户的Asterisk服务器使用SIP协议连接。
截止2010年10月28日,Asterisk的最新版本是1.8.0版。
由于Asterisk过于专业,所以目前也存在大量的基于Asterisk开发的容易使用的通信系统,比如在欧美比较流行的elastix、trixbox、或以中文为基础的Freeiris等。

 

初步试用Squid的替代产品──Varnish Cache网站加速器

Varnish是一款高性能的开源HTTP加速器,挪威最大的在线报纸 Verdens Gang (vg.no) 使用3台Varnish代替了原来的12台squid,性能比以前更好。

Varnish的作者Poul-Henning Kamp是FreeBSD的内核开发者之一,他认为现在的计算机比起1975年已经复杂许多。在1975年时,储存媒介只有两种:内存与硬盘。但现在计算机系统的内存除了主存外,还包括了cpu内的L1、L2,甚至有L3快取。硬盘上也有自己的快取装置,因此squid cache自行处理物件替换的架构不可能得知这些情况而做到最佳化,但操作系统可以得知这些情况,所以这部份的工作应该交给操作系统处理,这就是Varnish cache设计架构。

Varnish可以在FreeBSD 6.0和Linux 2.6内核上运行。

1、编译安装varnish HTTP加速器:

引用
wget http://blog.s135.com/soft/linux/varnish/varnish-1.1.1.tar.gz
tar zxvf varnish-1.1.1.tar.gz
cd varnish-1.1.1
./configure –prefix=/usr/local/varnish
make && make install

2、简单启动varnish守护进程,用本机80端口去反向代理加速127.0.0.1:81上的Apache服务器:

引用
/usr/local/varnish/sbin/varnishd -a :8080 -b 127.0.0.1:81 -p thread_pool_max=1500 -p thread_pools=5 -p listen_depth=512 -p client_http11=on -w 1,10000,120

Varnish官方网站:http://www.varnish-cache.org/

另有一份PDF文档,说明Varnish原理的:http://ishare.iask.sina.com.cn/cgi-bin/fileid.cgi?fileid=2163384

我测试了一下,在同等配置环境下,Varnish的性能确实要超过Squid,稳定性也不错,值得继续去深入研究。

 

原文地址:http://blog.s135.com/post/290/