Apache Traffic Server 3.2.0 正式版，附srpm包

aaaaaa

回復 273# win_hi


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

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

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

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

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


FYI

aaaaaa

回復 278# Jacksonqi


   

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

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

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


FYI

suran007

回復 283# aaaaaa


    豪哥，問一下關于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"

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

aaaaaa

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

這個是拼寫錯誤嗎？
應該用
url_regex=http://.*.abc.com scheme=http parent="1.1.1.1:80; 1.1.1.2:80"
?

yangyangqq2

回復 260# aaaaaa


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


   

yangyangqq2

回復 230# aaaaaa
能簡單說下這種cluster處理流程或者是架構，以及配置方法嗎??




   

brianchen829

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

aaaaaa

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

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

FYI

aaaaaa

回復 287# yangyangqq2


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


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

FYI

   

brianchen829

我現(xiàn)在用的是ATS 3.2
內(nèi)存是2G
ramcache是200M
最近經(jīng)常出現(xiàn)錯誤自動重啟。
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]
但當時內(nèi)存是足夠的剩余內(nèi)存還有700多M。老大能指點一下，這個異常說明的是一個什么類型問題嗎？