看板 Soft_Job 關於我們 聯絡資訊
看到 tnstiger 大大分享想法 我是昨天發現真的問題還蠻不小的 ※ 引述《tnstiger (000)》之銘言: : 我看不下去了 : 根據我兩個下午在電腦前搶票的經歷 : 與之前工作過的經驗 : 來說說寬宏的"誠意"在哪 首先,先釐清,這陣子新聞 寬宏在所講的 35萬人同時在線是怎麼回事,有些新聞半開玩笑的寫婉君XD -- 寬宏說,「對於35萬人同時上線的狀況是業界從未有過的 -- 我們也在這樣的狀態下不斷改進修正,我們做的不盡完善 -- 但我們會盡全力改善我們的缺失,希冀讓1/6、1/7的售票狀況更盡完善」 -- http://udn.com/news/story/8/624123 是的,你沒看錯「35萬人同時上線的狀況是業界從未有過的」 雖然我不知道究竟35萬人上線是怎麼樣的狀況 我想的確處理這些系統的工程師壓力很大 但是在 寬宏藝術的 Facebook 粉絲團上,我發現有個地方讓我更感興趣 -- http://i.imgur.com/YgM7cyI.png
-- 他所謂的 35萬人次同時上網搶票 其實你往這張圖往下看一下,會看到 Total Pageview 七十萬 而報表上的截圖上加總起來,就剛好是 七十多萬 寬宏系統講的所謂的 35萬人,事實上並非如此。 以網站分析報表,常看到的 Page View,Page view 指就是俗稱的點閱率 也就是說,這個點閱率,就跟傳統的網頁計數器一樣,逛過一次就+1次。 寬宏所使用的 onestat 公司的服務,網頁內容也寫得相當明白跟清楚 http://i.imgur.com/7cRlvu7.png
如果說,這叫做同時上線,我以前做的網頁不就誤打誤撞百萬人同時在線? http://i.imgur.com/T4oqUeE.jpg
所以,一開始就是理解錯了。 我們用 Google Analytics 的實際數據來看 這些數字基本上是,瀏覽率(點閱)最大,因為不計人頭,只計點閱 接著是使用者(不重複)跟工作階段,使用者不會大過於點閱率 所以不可能有三十多萬人在線的狀況,而這類平台報表都是如此 再來是像這樣的東西 http://i.imgur.com/e0wQHqX.png
我目前手邊沒截圖,但之前熱門話題都可以維持至少有 2000~4000 同時在線的表現 然後隨著時間的流動,這些人累積起來,就會歸納到 使用者 那裡 另外為了確定,我特別去模擬寬宏使用 onestat 這間公司的服務的做法 進行了一次的實驗,確定是否如同字面上的意思跟我所想的一樣 0. 首先,我在上面申請一組帳號,登記他要我給予一個 Domain name http://i.imgur.com/DQghJwx.png
但是,我只想測試,所以給了 example.com(保留用的網域,Demo 用 不同於 localhost,這網域有實際真實的位置 只要他們伺服器確認的到這個 domain name 存在即可 2. 建立網頁來測試點閱功能是否有作動,讓 domain name 跟他們 onestat 系統上的相符合,避免浪費時間 debug 因此,你得改本機上的 hosts,把 example.com 直接指到 127.0.0.1(本機) http://i.imgur.com/i8CTwVw.png
3. 弄個網頁 rails new demo .. rails g controller welcome index ... rails -p 80 ... 4. 打開 example.com 刷刷網頁 5. 資料就出來了,的確是一般的 Page view,沒有所謂同時在線,刷一次記一次 http://i.imgur.com/Sa0ARF1.png
在這個點閱率的問題,再提一個比較值得注意的地方 0. 經過早上測試,相信大部分的人都一開始就卡住了 但其實網頁瀏覽器早就載下來,但 Javascript /css 跟不上,所以沒畫面 onestat 本身是不同網域,所以不會卡住,他就直接計數了 http://i.imgur.com/8SHfPTr.png
所以他們提供的數據我認為還是有點失真,因為可能在某種數字下就先擠爆了 1. 寬宏的會員註冊前期,驗證系統不是有強制力 有去阻擋一些 spam email or 匿名用途的 email 你都可以隨意使用網路上的服務申請帳號(好容易) 2. 除了首頁,沒有善用網頁統計工具來分析其它頁面的統計狀況 http://i.imgur.com/CknDHN9.png
結果把 GA 的語法塞到 Adobe 軟體生出來的 AC_RunActiveContent.js 下面去了 我是覺得作法頗不妥就是了,這網頁被 Dreamweaver 摧殘很厲害,肯定是沒用樣板 直接塞 AC_RunActiveContent.js 了事 不過還好,至少網頁炸了,有一點點數據可以做參考,不過script會有點小問題 -- 接下來是所謂的頻寬問題 新聞傳說寬宏跟遠傳弄了一條 200MB 的專線 http://news.ebc.net.tw/apps/newsList.aspx?id=1420521420&cat=General 網站還是拼命 503 爛掉的 其實我發現是網站伺服器的 http request 跟 資料量大小的問題佔了頻寬很大的因素 首頁就直接吃掉 2 ~ 3MB,光圖片就高達 90 Request http://i.imgur.com/tMghCF9.png
(稍早他們把整塊 banner 比較流量的都拿掉了,但還有60幾個 request) 所以你想想,光每一個使用者點擊進來,刷個畫面 就像是 http get flood attack 拼命往負載平衡、IIS Server 等設備身上打 無形增加伺服器的負擔 http://i.imgur.com/dJ8u2s8.png
(尼看看~這麼坦的負載設備,默默孤軍奮戰QQ) 此外在連線上的控管,MIS 對一組 IP 進行連線數、request/sec or min 限制就變得複雜 因為你不知道正常的使用者,在一定的時間區間內,他們瀏覽幾個畫面 會發出的 request 究竟有多少 怎樣的值叫做合理 會不會影響其他的網友造成困擾?或者產生致命的無法使用之問題? (需要花很多時間跟心力調校,而且不見得有用) 雖然寬宏對外表示的,有 30 台主機負責處理 http://www.setn.com/News.aspx?PageGroupID=4&NewsID=55887&PageType=3 但不管怎麼樣的設計架構也不該整個網站都停止運作,丟個 503 就什麼也不管了 何不多個 domain name 弄個 Github page 幫你頂一下 最起碼倒站時基本的服務聯絡跟最新資訊要在上面 確保大家不會因為沒看到畫面,就無中生有 相信我,完全沒有畫面真的很恐怖,各種傳聞滿天飛 我是認為 1. 如果這些 Web Server 還要負責跟 DB 持續運算資料(訂位/會員系統相關) 那麼就將 Web Server 上的 影像,CSS、JS檔案獨立出來 放程式 Web Server 的部分就不要再負責吐靜態檔案的內容 另外弄一個子網域,弄台專門的 linux 架設 Nginx or Tengine 擺放重要的靜態檔案,讓 Web Server 專心做好運算、顯示畫面就好 而 Web Server 的 source code 部分連結網址都要全部換掉, 靜態的東西不要丟給 IIS 瞎忙 你設定一些設備的 rule 也會比較輕鬆一點 2. 另外,像是特定的 event 會用到的 banner、宣傳影像、說明步驟 等大圖檔案 也可以考慮使用付費 imgur(其實免費的蠻好用的單日破百GB也沒鎖) 或 專門的付費圖床 去分擔流量,國外的頻寬比台灣大很多 另外也可租台 storage server,連線 ping 值 150 內,反應都不會差到哪裡去 公司想要做更好,上 CDN 也可以 不過前提是這家 CDN 不會跟主流的電信業者線路有點小衝突 像早期 Cloudflare 配中華電信,就會連不到。 那些喜歡把 JS/CSS Library/Framework 丟 CDN 的網站,很容易卡住。 總之,錢跟資源不要往同個籃子丟 3. 靜態檔案、影像的東西該打上 Cache-Control 就打得明確 讓瀏覽器乖乖的配合你的快取策略,不要讓它成為佔機器頻寬的隱性問題 https://blog.othree.net/log/2012/12/22/cache-control-and-etag/ 4. 利用 CSS 的一種 Sprite 技巧,把多個小圖做成一張圖,減少你的圖示 Request 量 http://spritegen.website-performance.org Request 跟 伺服器,就像是 上千個檔案跟 USB 隨身碟 的關係是一致的 當你把一千個檔案拉到隨身碟,USB 隨身碟會傳很久很久 但是你把,上千個檔案打包成一個的時候,一樣大小的檔案,傳輸硬是快很多 http://i.imgur.com/cKYHjGw.png
這類技巧網路很多可以參考,不用擔心不能換圖,一張就可以做很多事 換圖純 CSS 就可以做得到,而且還可以搭配 CSS3 做點動畫效果 5. 另架設 varnish-cache 擺在 web server 的前面,把一些畫面緩存下來 不用經過 web server 再吐資料,負載能力會稍微好一點 https://www.varnish-cache.org 但前提是要確定 web server http header 會不會帶有 Cache-Control private 或 no-cache 的字眼 (注意快取有沒有命中) 通常有用到 session 做會員系統的,server reponse 都會帶入這項,確保資料獨立 varnish 為了保持資料的正確性,也是乖乖配合,不把資料進行緩存快取 避免造成張三看到李四他老婆偷情(疑 6. view cache,把畫面上的部分 html 直接先產生好,下次連線直接印在上面就好 偷懶大師必要,但舊版 asp 可能沒有這種福利工具可以使用 可以硬幹類似的東西,但我奉勸換個架構吧 LoL.. 7. 利用 memcached、redis cache 這類的 cache server 快取一些比較繁雜的運算資料 或是只算過一次,就不太需要繼續運算的資料 另外還可以做 access 行為控管,比如你可以自己設計 哪些頁面或動作,不該在 1 分鐘內做 5 次,如果做過 5 次就鎖定這個 IP 3小 時 也可以設計繼續嘗試,就一路鎖他天荒地老,直到他放棄為止後的 3小 時再解開 不過舊版 asp 可能沒有相關組件可以讓你輕鬆用,換架構吧 LoL.. 另外要留意鎖IP這件動作 如果電信業者的IP,你鎖下去,可能就那一個地方附近的人都無法存取。 twnic 可以查到台灣IP的分佈資訊,非成員也可以查「IP核發分配情形」 http://rms.twnic.net.tw/twnic/Search-non.htm 8. 充分利用瀏覽器/瀏覽器元件 Cross-domain access 限制 來讓人家寫好的訂票軟體直接失效。 你可以把訂票系統獨立出來,只有特定網域可以存取,不要目前網站網域混在一起 內嵌一個框架頁,內嵌網頁的網站,跟內嵌的那一個網頁是 A B 不同子網域或網域 假設 A 是 example.com,B 是 example.net 舉例來說目前 A 網域訂票頁,什麼都不用放,只放嵌入 B 網域的訂票頁就好 只要網域不同,像是用 C# Web Browser元件 實作的網頁自動化程式 程式元件有遵循微軟自己訂的 Policy (無法直接用 A 網域 frame 元素存取 B 網域的內容進行修改) 它就會失效,而開發者需被逼迫必須要用很底層的方式來繞過微軟的限制 完全考驗開發者對於 Windows 視窗程式的熟悉程度 IHTMLDocument 全系列 (2 3 4 5... 好像現在有8?) 加上每一個 Interface 下面的方法都不太相同,跟 Web Browser 元件比起來 有的是半殘,有的是全殘,開發者開發到一半就先崩潰了 甚至處理不好,你的一塊小 Flash 動畫,就可以讓他 Memory Leak 應用程式直接終止 (如果是瀏覽器的套件在控制,你就得翻翻該瀏覽器 Extension 的文件,想辦法治它了) 9. 有些自動化程式有種特徵,就是 Viewport 出奇的小,User-agent 跟他的大小不搭 因為這些元件無法隱藏起來,不然裡面的 Dom 或 Javascript 取值會很奇怪, 就是得放在畫面上,利用 Google Analytics 可以留意一下螢幕解析度跟裝置 或許有些不同的收穫 註:8 跟 9 是我多年以前做自動化程式攻防小經驗,順便當 bonus 隨手寫一寫 XD == 10. .... 讓 KKTIX 批票來賣(誤) 沒了,好累 說真的,打到這裡,對寬宏售票的氣也消了 我相信處理這個問題工程師也是相當頭痛 (XD) 但身為消費者實在是沒法度,想到要買一二張買不到就很火大 這個問題如果不是技術問題,就是人的問題啦~ -- 最後,感謝各位 Soft_job 版的大大耐心看完 如果是直接 End 也感謝你右鍵走進來 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.142.78.14 ※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1420586522.A.8FF.html ※ 編輯: guanting886 (220.142.78.122), 01/07/2015 07:38:17
Eureka7: 只能推了! 01/07 07:43
GoodWhisky: 給推 01/07 08:13
realmeat: 就沒進行過壓測實際上連他們都搞不懂瓶頸在那邊 01/07 09:04
KekeMonster: 專業! 推 01/07 09:21
jk47tai: 給推,記者應該好好看一下,不過根據新聞還有重複劃位的 01/07 09:36
jk47tai: 問題,足見寬x有多..... 01/07 09:36
alpe: 只能推了 01/07 10:02
onininon: 推分析 01/07 10:25
asdfghjklasd: 這是錢跟找到什麼樣子的人的問題 01/07 10:43
asdfghjklasd: 一直說台灣規模小,所以不用發展大型系統. 01/07 10:44
asdfghjklasd: 找到的都是不能真正處理的人 01/07 10:44
asdfghjklasd: 更何況他又不是第一次在賣 01/07 10:44
GoalBased: 太強拉! 01/07 10:50
followmeyo: 專業推,受教了 01/07 10:53
vn509942: 感謝分享 01/07 10:58
belion: 8,9,經驗談啊,計算那塊,有遇到條件說,只能從 db 撈資料 01/07 12:12
candycare: 推 01/07 12:12
belion: 出來,不能在撈出來的資料,直接用sum,group等func計算, 01/07 12:13
belion: 只能在網頁計算,這也頭痛過+_+ 01/07 12:13
y2468101216: 推 回家在慢慢看 前面讓我收穫良多 01/07 12:54
Curapikt: 住手啊~~生命值已經歸零了XDD 01/07 13:01
※ 編輯: guanting886 (180.217.27.177), 01/07/2015 13:35:39
a7904120: 專業給推 01/07 13:28
malol: 好文,但是寬宏只有買 200M 不是 200MB 01/07 13:43
sing10407: 好文,大大怎麼看aws呢? 01/07 14:10
jammy50605: 推 01/07 14:41
jhihruei: 好文推,寬宏根本省小錢(技術人員)花大錢(硬體) 01/07 15:43
etonline: 推佛心撰文 01/07 15:56
zeus85072: 對8.9 很有興趣阿 @@ 01/07 16:03
luckymoon: 不明覺厲 01/07 16:13
miname: Ptt主要只有一台.... 01/07 16:23
感謝私信分享。我將那段文字先暫時移除掉,避免台大人困擾。
tw0517tw: 記得ptt在資工系 不在計中 01/07 17:45
saitoh: 有6個IP不代表有6台主機啊 會有6個IP是要解決port被吃滿 01/07 18:01
saitoh: 的問題吧 01/07 18:01
guanting886: 也是 -_- 謝謝提醒 突然想起以前有台很強的工作站 01/07 18:04
※ 編輯: guanting886 (180.217.27.177), 01/07/2015 18:09:43
chatnoir: 最近看一本叫巨型網站技術架構大揭密的書也談到很多 01/07 18:22
atpx: 太強拉 01/07 22:55
yun0821: 高手 推 01/07 23:36
TINGWEI6: 經過兩天搶票推估同時在線人數頂多2-3萬 01/08 01:38
Mtcat: 01/08 02:08
akanelee: 這網頁被 Dreamweaver 摧殘很厲害<<<(狂笑中) 01/08 10:43
wens: 6個ip是因為單ip連線數量太多會被上游的ids/ips誤判 01/08 10:47
airvivi: 大老闆的想法是,能用就將就用,不會想花錢 01/08 13:59
LiloHuang: 連線消耗的不是 port,是一堆 socket file descriptors 01/08 20:16
LiloHuang: 批踢踢 server-side 開放的 port 都是固定的那幾個 01/08 20:25
TobyH4cker: 看完了,先推 01/08 22:42
TobyH4cker: 關於你說的利用Policy限制阻擋自動化程式,我覺得會 01/08 22:49
TobyH4cker: 做這種程式的應該只會用WebBrowser去操作介面上的元 01/08 22:49
TobyH4cker: 素,但是如果是我,就會直接發Get Post request來搞定 01/08 22:49
TobyH4cker: ,不過需要先會分析行為就是了XD,直接request就不會 01/08 22:49
TobyH4cker: 執行JavaScript、也不會有cross-domain問題,UserAgen 01/08 22:49
TobyH4cker: t等header由我自己造,不過目前還很少看到有其他人做 01/08 22:49
TobyH4cker: 到 01/08 22:49
TobyH4cker: 大大整篇都講得很到位,沒經驗的我學到了寶貴的一課, 01/08 22:54
TobyH4cker: 推「換架構吧 LoL..」 01/08 22:54
guanting886: 樓上,只要架構有防止CSRF或用到一些機器無法做到的 01/08 23:18
guanting886: 包括帶一些無法被Fake或是你沒有差覺到的參數 01/08 23:19
guanting886: 例如圖像、useragent特有的特徵、操作特徵 01/08 23:20
guanting886: 這個 request 要 fake 難度就會很高 01/08 23:20
guanting886: 工程師賊一點,可以直接不吐錯誤,以正常值回應 01/08 23:21
guanting886: 但不入庫、不動作,等假動作,你就會被騙到了 01/08 23:21
guanting886: 以前我有時候會這樣玩弄hacker XDD 01/08 23:22
guanting886: 另外再次感謝樓上各位大大的推文!:D 01/08 23:23
viper9709: 推~~超專業 01/08 23:34
zg0608x: 我在想會不會露天的流量單日就超越寬宏這幾天 01/09 00:51
yoco: 好 01/16 04:00
ruthertw: 你有沒有搞清楚呀?Ptt主要只有一台! 07/21 08:07