亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

  免費注冊 查看新帖 |

Chinaunix

  平臺 論壇 博客 文庫
最近訪問板塊 發(fā)新帖
樓主: aaaaaa
打印 上一主題 下一主題

[proxy] Apache Traffic Server 3.2.0 正式版,附srpm包 [復制鏈接]

論壇徽章:
0
281 [報告]
發(fā)表于 2012-12-24 15:03 |只看該作者
回復 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

論壇徽章:
0
282 [報告]
發(fā)表于 2012-12-24 15:17 |只看該作者
回復 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

論壇徽章:
0
283 [報告]
發(fā)表于 2013-01-08 10:50 |只看該作者
回復 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ù),請問配置**問題么?

論壇徽章:
0
284 [報告]
發(fā)表于 2013-01-08 18:07 |只看該作者
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"
?

論壇徽章:
0
285 [報告]
發(fā)表于 2013-01-16 11:11 |只看該作者
回復 260# aaaaaa


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


   

論壇徽章:
0
286 [報告]
發(fā)表于 2013-01-18 14:14 |只看該作者
回復 230# aaaaaa
能簡單說下這種cluster處理流程或者是架構,以及配置方法嗎??




   

論壇徽章:
0
287 [報告]
發(fā)表于 2013-01-29 10:40 |只看該作者
本帖最后由 brianchen829 于 2013-01-29 10:41 編輯

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)存問題,頭大啊。

論壇徽章:
0
288 [報告]
發(fā)表于 2013-02-01 01:51 |只看該作者
任何內(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

論壇徽章:
0
289 [報告]
發(fā)表于 2013-02-01 01:54 |只看該作者
本帖最后由 aaaaaa 于 2013-02-01 01:55 編輯

回復 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

   

論壇徽章:
0
290 [報告]
發(fā)表于 2013-02-01 12:48 |只看該作者
我現(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。老大能指點一下,這個異常說明的是一個什么類型問題嗎?
您需要登錄后才可以回帖 登錄 | 注冊

本版積分規(guī)則 發(fā)表回復

  

北京盛拓優(yōu)訊信息技術有限公司. 版權所有 京ICP備16024965號-6 北京市公安局海淀分局網(wǎng)監(jiān)中心備案編號:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年舉報專區(qū)
中國互聯(lián)網(wǎng)協(xié)會會員  聯(lián)系我們:huangweiwei@itpub.net
感謝所有關心和支持過ChinaUnix的朋友們 轉載本站內(nèi)容請注明原作者名及出處

清除 Cookies - ChinaUnix - Archiver - WAP - TOP