Apache Traffic Server 3.2.0 正式版，附srpm包

aaaaaa

回復(fù) 273# win_hi


   
1, ram 和 disk比例得看你自己的使用場(chǎng)景，我們推薦1%左右，這樣才經(jīng)濟(jì)啊。

2，回源如果出問(wèn)題，TS會(huì)盡量用stale的數(shù)據(jù)來(lái)給用戶，如果你這個(gè)內(nèi)容是新的，本地沒(méi)cache，那這個(gè)只能會(huì)給用戶一個(gè)502啦

3，TS作hash的優(yōu)勢(shì)在于，減少http封包解包過(guò)程，而這是整個(gè)http協(xié)議里最惡心的地方。http2.0 SPDY等都是在改進(jìn)這個(gè)。而TS的cluster實(shí)現(xiàn)是在cache層實(shí)現(xiàn)的，已經(jīng)屏蔽了http引入的問(wèn)題。這是它的天然優(yōu)勢(shì)。在TS里，cluster是cache文件系統(tǒng)的一個(gè)延伸。而如果用nginx haproxy等所謂的7層負(fù)載，那是在http層以上的層面實(shí)現(xiàn)，自然差異就大了。

4，varnish具有天然優(yōu)勢(shì)，TS并不是所有的地方都比其他cache/proxy軟件強(qiáng)。相反，在任何方面，其他軟件都有比TS強(qiáng)的地方，如squid功能強(qiáng)，兼容性好，varnish簡(jiǎn)單ram性能好，nginx在簡(jiǎn)單環(huán)境下，性能超好，haproxy7層負(fù)載絕好，等等。TS跟他們的長(zhǎng)處比，都不是最好的。但是TS是一個(gè)整體設(shè)計(jì)的軟件，從一開(kāi)始就是為作一個(gè)各個(gè)方面比較平衡的設(shè)計(jì)，從軟件設(shè)計(jì)角度，這個(gè)是一個(gè)很蠢的設(shè)計(jì)，但是勝在當(dāng)初參與設(shè)計(jì)的很多都是號(hào)稱科學(xué)家級(jí)別的人，因此他們?cè)O(shè)計(jì)的這個(gè)系統(tǒng)，在整體上都可以跟各個(gè)軟件的長(zhǎng)處比一比，呵呵。

從我們的使用中覺(jué)得，用ATS的，都是有需求的人。需求簡(jiǎn)單而且明確的，能找到比TS更合心的，多數(shù)人走不到ATS來(lái)。


FYI

aaaaaa

回復(fù) 278# Jacksonqi


   

1，能。緩存大文件也是一個(gè)通用cache系統(tǒng)的基本要求。底層方法也不特別，就是文件系統(tǒng)的設(shè)計(jì)思想，把多個(gè)塊連成一個(gè)文件。

2，TS能不能作城域網(wǎng)，這個(gè)主要是能力和兼容性的問(wèn)題。就設(shè)計(jì)本身來(lái)說(shuō)，TS是當(dāng)初定位到運(yùn)營(yíng)商級(jí)別的2個(gè)公司之一，另一個(gè)是CISCO公司。當(dāng)然這兩個(gè)公司的發(fā)展都不太好。因此在ISP級(jí)別并沒(méi)有什么很“靠譜”的解決方案。性能方面TS是很好的，阿里用ATS其中性能就是一個(gè)原因，性能測(cè)試方法我還在考慮中，回頭明確確定性能測(cè)試方案后我們?cè)侔l(fā)一個(gè)性能測(cè)試報(bào)告出來(lái)看，就我們測(cè)試來(lái)看，一對(duì)E5 2650的CPU，跑20-30G流量很靠譜。有運(yùn)營(yíng)商在用ATS作透明代理解決方案，并sponser了一個(gè)核心開(kāi)發(fā)人員參與相關(guān)開(kāi)發(fā)。想測(cè)試還是有方法的，如流量鏡像、tcpcopy等的。

3，能，參考插件目錄里的balancer 以及regex_remap等，ATS在功能擴(kuò)展方面一直是走的很遠(yuǎn)的。相信你能想到的大多數(shù)功能都可以用擴(kuò)展插件解決。原inktomi時(shí)代有很多重型業(yè)務(wù)插件實(shí)現(xiàn)了很多復(fù)雜業(yè)務(wù)，yahoo時(shí)代更在插件方面是用到極致。流量導(dǎo)向是一個(gè)很復(fù)雜的問(wèn)題，可以有很多方法，但是合適自身業(yè)務(wù)的方法也很難找到，我們也在探討srv和parent機(jī)制等。


FYI

suran007

回復(fù) 283# aaaaaa


    豪哥，問(wèn)一下關(guān)于parent的配置方法，我的環(huán)境是client->ats->squid(1.1.1.1 1.1.1.2)->realserver,需要配置ats的parent方式,我的配置如下：
1、records.config
CONFIG proxy.config.http.parent_proxy_routing_enable INT 1
2、remap.config
regex_map http://(.*).abc.com/ http://$1.abc.com
3、parent.config
url_regex=http://$1.abc.com scheme=http parent="1.1.1.1:80; 1.1.1.2:80"

配置后，訪問(wèn)ats，檢查日志發(fā)現(xiàn)并沒(méi)有去squid抓取，而是通過(guò)resolv.conf的dns解析的地址去抓取的數(shù)據(jù)，請(qǐng)問(wèn)配置**問(wèn)題么？

aaaaaa

url_regex=http://$1.abc.com scheme=http parent="1.1.1.1:80; 1.1.1.2:80"

這個(gè)是拼寫(xiě)錯(cuò)誤嗎？
應(yīng)該用
url_regex=http://.*.abc.com scheme=http parent="1.1.1.1:80; 1.1.1.2:80"
?

yangyangqq2

回復(fù) 260# aaaaaa


能否貼下日志處理的配置？？？？


   

yangyangqq2

回復(fù) 230# aaaaaa
能簡(jiǎn)單說(shuō)下這種cluster處理流程或者是架構(gòu)，以及配置方法嗎??




   

brianchen829

1、ATS有記錄硬盤(pán)中對(duì)象被交換的日志嗎？最近用ATS硬盤(pán)分配200G后，很快滿了，很想驗(yàn)證一下哪些對(duì)象什么時(shí)候被交換出去。
2、我現(xiàn)在用2G內(nèi)存。發(fā)現(xiàn)內(nèi)存每天都會(huì)增長(zhǎng)。運(yùn)行10多天后內(nèi)存就不足了。機(jī)器重啟后又能運(yùn)行10多天，剛開(kāi)始在想是對(duì)象索引需要內(nèi)存。但也不應(yīng)當(dāng)是無(wú)限的增長(zhǎng)啊。而且這段時(shí)間硬盤(pán)都是滿的。是不是內(nèi)存管理方面有什么問(wèn)題。硬件內(nèi)存可以增加，但ATS使用內(nèi)存一直在增長(zhǎng)，那也總會(huì)有用完的一天。有誰(shuí)能分享一下ATS內(nèi)存使用情況的數(shù)據(jù)的嗎？以前用squid也是內(nèi)存問(wèn)題，頭大啊。

aaaaaa

任何內(nèi)存有問(wèn)題的，請(qǐng)參考 https://issues.apache.org/jira/browse/TS-1006 的說(shuō)明，這里的相關(guān)patch我會(huì)在幾天內(nèi)commit到master里去，如果用stable的分支或版本，這個(gè)優(yōu)化可能沒(méi)這么快port過(guò)去。

ats的硬盤(pán)寫(xiě)入是一個(gè)RRD模式，及循環(huán)覆蓋。我們基本不關(guān)心覆蓋了啥，所以系統(tǒng)也沒(méi)啥好法子查寫(xiě)入覆蓋的東西。如果要查詳細(xì)數(shù)據(jù)，可以分析一下日志，因?yàn)槲覀冎饕獡?dān)心的是回源不受控制，所以分析回源的紀(jì)錄里看看是否有寫(xiě)內(nèi)容一直沒(méi)法cache住而我們希望他們能cache住的。

FYI

aaaaaa

回復(fù) 287# yangyangqq2


cluster是一個(gè)類似于NFS的RPC遠(yuǎn)程調(diào)用機(jī)制，整個(gè)cache系統(tǒng)使用cluster的機(jī)制把storage擴(kuò)展到集群的所有機(jī)器傷，通過(guò)對(duì)請(qǐng)求URL進(jìn)行hash分散后，形成存儲(chǔ)擴(kuò)展的效果。我通常給大家解釋TS的cluster跟haproxy+squid的最大區(qū)別是，TS的cluster是在文件系統(tǒng)層面的，而haproxy的7層hash是在http層面的，我認(rèn)為這是最形象的解釋。


參考官方文檔：
http://trafficserver.apache.org/ ... howto/index.en.html

FYI

   

brianchen829

我現(xiàn)在用的是ATS 3.2
內(nèi)存是2G
ramcache是200M
最近經(jīng)常出現(xiàn)錯(cuò)誤自動(dòng)重啟。
FATAL: ats_memalign: couldn't allocate 67108864 bytes at alignment 8192 - insufficient memory
/usr/bin/traffic_server - STACK TRACE:
/lib/libtsutil.so.3(ink_fatal+0x24)[0x4002e334]
/lib/libtsutil.so.3(ats_memalign+0x87)[0x400308c7]
/lib/libtsutil.so.3(ink_freelist_new+0xf7)[0x40031287]
/usr/bin/traffic_server(_ZN9MIOBuffer9add_blockEv+0x38[0x828d8c8]
/usr/bin/traffic_server(_ZN9MIOBuffer5writeEPKvx+0x14c)[0x82b800c]
/usr/bin/traffic_server(_ZN14ChunkedHandler14transfer_bytesEv+0x3cc)[0x81a746c]
/usr/bin/traffic_server(_ZN14ChunkedHandler10read_chunkEv+0x12)[0x81a7772]
/usr/bin/traffic_server(_ZN14ChunkedHandler23process_chunked_contentEv+0xdc)[0x81a7adc]
/usr/bin/traffic_server(_ZN10HttpTunnel24producer_handler_chunkedEiP18HttpTunnelProducer+0x47)[0x81a7b77]
/usr/bin/traffic_server(_ZN10HttpTunnel16producer_handlerEiP18HttpTunnelProducer+0x149)[0x81a86d9]
/usr/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0x82)[0x81a8cd2]
/usr/bin/traffic_server[0x829b972]
/usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x25[0x8293788]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xa2)[0x82b9c72]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x473)[0x82ba593]
/usr/bin/traffic_server(main+0xe30)[0x810f7c0]
/lib/libc.so.6(__libc_start_main+0xd9)[0x40322fb9]
/usr/bin/traffic_server[0x80d1ef1]
但當(dāng)時(shí)內(nèi)存是足夠的剩余內(nèi)存還有700多M。老大能指點(diǎn)一下，這個(gè)異常說(shuō)明的是一個(gè)什么類型問(wèn)題嗎？