Mais conteúdo relacionado
Semelhante a Ad tech 20121030 (20)
Ad tech 20121030
- 4. 広告リクエスト
媒体側
広告
Browser
サーバ
(SSP)
- 5. Bid リクエスト
媒体側
広告
Browser
サーバ 広告主側
(SSP) 広告サーバ
(DSP)
- 6. Bid
10
媒体側
広告 20
Browser
サーバ 広告主側
(SSP) 30
広告サーバ
(DSP)
15
- 7. オークション
10
媒体側
広告 20
Browser
サーバ 広告主側
(SSP) 30
広告サーバ
(DSP)
15
※generally “second price auction”
second highest bid price will be the contract price
- 8. 勝者の広告を表示
10
媒体側
広告 20
Browser
サーバ 広告主側
(SSP) 30
広告サーバ
(DSP)
15
- 12. SSP
• 100億RTB imp x DSP10社 → 1000億bid
• 外部ネットワークアクセス
• ラック内ではない
• 同じL2にぶら下がるわけでもない
• 普通のadサーバならやりたくない
- 18. タイムアウト
• CURLOPT_TIMEOUT_MS
• cURL 関数の実行にかけられる最大のミ
リ秒数。 システムの標準の名前解決を
使うように libcurl をビルドしている場合
は、 接続のタイムアウトは秒単位の精
度となり、最小のタイムアウトは 1 秒と
なります。
- 20. タイムアウト処理
• 個別の接続
• socket APIはコネクションと転送のタイムアウ
トが別…
• 処理全体
• 処理全体でのタイムアウトを記述するのはよ
くある言語だと結構ツラい
• リクエスト毎に監視用のスレッドを立て
る?
• signalを飛ばす?
- 21. 選択肢
• libev や libeio などを使ってCで書く
• node.js (内部でlibev libeio を使用)
• 軽量プロセスを持つ言語(Erlangなど)
- 25. node.jsを使う
• cons
• コールバック地獄
• シングルスレッド
• タイムアウトは結局地獄
• 枯れていない
• 頻繁なバージョンアップ
- 39. 要件(再掲)
• 堅牢であること→OK
• 高速であること→OK
• ネットワークIOでブロックしないこと
→OK(軽量プロセスで解決)
• 適切なタイムアウト処理(超重要)
→OK(軽量プロセスで解決)
- 40. ロバートと私はともによくLispを知っていて、私達の直観を覆すようないかなる 理由も見当た
らなかった。他の誰もがC++やPerlを使っていることは知っていた。 でもそれは私達には何の
意味もないことだった。もし、他の誰もが使っているからと いう理由で技術を選ぶなら、
Windowsを走らせておけばいいのさ。 技術を選択する時は、他の人がどうやっているかなんて
無視して、 何が最適かを見極めることだけを考えるべきだ。
特にベンチャー企業ではそうだ。大企業では、他の大企業がやっているのと 同じようなこと
をしていても良い。ベンチャーは他のベンチャーと同じことを やっていてはいけない。このこ
とに、ベンチャー企業の中に居てさえ 気付いていない人が多いんじゃないかと思う。
平均的な大企業は年に10%成長する。だから、あなたが大企業を経営していて、 他の大企業が
やっているのと全く同じようにやっていれば、 やはり年に10%くらいの成長が期待できるだろ
う。
もちろん、同じ論理はベンチャー企業にも成り立つ。 もしあなたが平均的なベンチャー企業
と同じことをやっていれば、 平均的な成長率が期待できる。問題は、だ。ベンチャー企業の
平均的な成長とは、 すなわち、潰れてしまうということだ。ベンチャー企業の生存率は50%よ
りはるかに 小さい。したがって、ベンチャーをやるなら何か変わったことをしなければなら
ない。 そうでなければ、困ったことになる。
Notas do Editor
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n