永慢～北馬櫻花，賽後心情 - 跑者留言版

作者

分享文章

主題搜尋

文章選項

家成

manager

註冊日期: 2002-06-23
位置: 中華民國台灣
線上狀態: 離線
文章數: 2373

文章選項

發表回應

引述家成

檢舉文章

引述

回覆

主題: 永慢～北馬櫻花，賽後心情
發表於： 2013-03-15 at 8:03am

各位跑友，

謝謝你們熱情的參與今年的櫻花馬，

人家說，潮水退囉就知道誰沒穿褲子...

7000人的馬拉松大賽，馬上把永慢招牌打亂囉，狀況百出，

在最不該發生錯誤的水站，竟然斷水，讓千名的跑友受影響

對於各位好朋友造成困擾，

任何道歉都無法形容我們籌備會幹部的心情

本會郭會長即將召開檢討會，各位好朋友提出的大小事項，我們都會記錄下來，

有你們不吝的指正及提醒，永慢才能改進及改善。

感謝大家

家成敬上

編輯者家成 - 2013-03-15 at 8:10am

algebra0001 由上至下檢視

Senior Member

註冊日期: 2011-05-20
線上狀態: 離線
文章數: 1052

文章選項

發表回應

引述 algebra0001

檢舉文章

引述

回覆

發表於： 2013-03-15 at 8:16am

潮水退囉就知道誰沒穿褲子...

哈哈哈

下次我去游泳時，就來好好欣賞囉

肉莉

Senior Member

註冊日期: 2007-11-12
位置: 水星
線上狀態: 離線
文章數: 3661

文章選項

發表回應

引述肉莉

檢舉文章

引述

回覆

發表於： 2013-03-15 at 9:10am

親愛的北馬會友,

很多的不捨,很多的情緒,要遮掩不是,要公開很難,就快憋成病來。

同屬於慢跑志工命運共同體的一份子,小雞想上來說幾句話,當木已成舟?能做的就是著眼規劃下次大浪的來臨。

北馬永遠都是金字招牌,擦不掉也抹不去,如今招牌或許因為風大歪吹了?或許因為朝聖者眾多踏亂了,但是小雞對您們有信心,整頓好門面又是活龍一尾。

跑者人口如雨後春筍般成長,一則喜一則憂,可喜的是更多人追求健康,那憂了什麼呢? 我們煩惱不夠先進的電腦報名程序,煩惱不成比例的義工人數,煩惱小鳥長大的速度永遠趕不上大夥振翅齊飛的速度。

小雞沒參加2013櫻花馬,但是憑藉著幾位網友的敘述,其實就能夠勾勒出當天的突發狀況,大概也可以知道問題所在,針對此我另外寫了一封萬言建言書給貴會郭會長。

檢討會蓄勢待發,但是請兼顧外部顧客及(內部顧客)的感受? 何謂內部顧客? 就是在說辛苦規劃賽事的各位先進囉！

言不及義,多多擔待!

小雞美媚

家成

manager

註冊日期: 2002-06-23
位置: 中華民國台灣
線上狀態: 離線
文章數: 2373

文章選項

發表回應

引述家成

檢舉文章

引述

回覆

發表於： 2013-03-15 at 9:48am

小雞美妹

就是你沒來督軍..我們就亂囉.

我們知道大家都不忍苛責手下留很多情

還是非常謝謝你的鼓勵

編輯者家成 - 2013-03-15 at 9:51am

sengtui

Groupie

註冊日期: 2010-01-06
位置: 台北土城
線上狀態: 離線
文章數: 98

文章選項

發表回應

引述 sengtui

檢舉文章

引述

回覆

發表於： 2013-03-15 at 1:51pm

文章發表人小紅馬

我想，不能要求這些報名系統可以像Google一樣、像Yahoo一樣擁有強大的主機，可以同時容納這麼多人進來存取。
國內的火車訂票，手機預購系統，你說他們的主機會不強大嗎？一樣是塞爆！
第一分鐘有5000筆進來，但主機一定能夠負荷嗎？如果是只能容納5000筆，但第一分鐘進來的是10000筆，怎麼辨？
我能體會這些報名系統設計有一定的容量，只為了一年這一兩次超量，他們也會有成本考量的。

熱門賽事，比較可能的處理方式，或許是用抽簽，這樣才不會有這些爭議。

資料庫可以有好多種設計方法，一場萬人以下等級的馬拉松報名如果設計得當照說只要兩三台單核心等級的電腦就可以應付.

在應付瞬間流量上面，用 Multi-tier ＋ token 的方法應該就可以很簡單的處理好，資料庫主機事先開好硬體能力可承受的 instance，只允許 broker 進來存取，使用者要在 broker server 拿到 token 才有辦法填資料， broker 只有在填完資料核對沒問題後才會跟後端db主機做一次交易。我記得以前 pentium 時代 mySQL server 每秒就可以做上百個交易了，一萬個交易在幾分鐘內完成應該是一片小餅乾的事情。

這樣子 db 就不會因為 instance 開太多把資源耗盡而變成 IO bound

沒拿到 token 的 user 也會被要求等待，而不會佔用到填表單所需要的網路頻寬造成網路塞車。

這種系統應該早期寫過資料庫程式的人都多少了解，不過這幾年因為硬體進步神速，現在的工程師反而喜歡全部寫在一起，用強悍的硬體和超大的頻寬直接打通關。碰到瞬間流量往往造成處理速度瞬間癱瘓。

我只懂皮毛，上面講的都是以前學校學的，僅供參考用。不過前面那個 sengsong 以前曾經是 oracle 專家，聽他的是有道理滴！

響應跑者廣場正名運動。
我叫做黃成對，後段班俱樂部成員，大家好呀！！！

sengsong

Senior Member