55％が嫌いなのに...
そして、私は他を選びました。 愛してるから しかし、私が他の人よりも便利だと思うものではなく、...
年に一度、すべてのDIYブースでよく知られているアメリカの企業sparkfun.comは、（ほぼ）宝くじを使います。 前回、または落下傘兵が言うように、彼らがこれを最後に行ったのは今年の1月10日でした。 要点は簡単です-あなたはサイトに行き、しばらくの間非常に嫌われている捕虜を解きます。 特定のデバイスは、解決されたキャプチャの1つをランダムに選択し、作成者に100ドルの証明書を発行します。このお金で、スパークファンで何かを注文でき、配達のみが支払われます。 それは絶対に正直なことです。
そして今、コロラド州の時間によると、午前9時に、世界中の多くの人々が座り込みを推測します。 サイトはすぐにドロップします。 スタブがその場所に掛けられており、ストアにアクセスできないことを謝罪し、別のキャプチャ解決ページが表示されます。 実際、コロラド州では、人々は占い師に座って笑っていませんが、このhabraeffectを克服するために苦労しています。
私は勝ちました-レカプチャで30分運転した後：
すでに読書をやめて私のカルマを台無しにしている人が何人いるか想像できます。 今最も永続的なためにおいしい。 sparkfanウェブサイトから翻訳を報告：
フリーデイレポート
2012年1月12日
再び1月と別の無料の日。 勝ち負けにかかわらず、みんなが楽しんでくれることを願っています。 ああ、私たちはそれをアレンジしてたくさんの喜びを得ました-それは確かです！
番号：
いくつかの数字を次に示します。
- 6,437,592正しいrecaptchaソリューション 。 これには、recaptchaが誤って解決された試行や、応答フィールドに入力せずにGOボタンが押されたときに登録された試行は含まれません。
- 平均的な人がキャプチャに4秒を費やすと仮定すると、 7 188時間がすべてに関するすべてに費やされました。 約10ヶ月の時間！
- 各キャプチャは、sparkfanサーバーによって処理されました。 355分の1秒あたり300キャプチャ-お金を配っていたとき
- 32,137サイトへのユニークビジター （分析レポートに基づく）。 多少の誤差はありますが、これはプレイヤーの数です。
- 平均して、 208個のキャプチャをそれぞれ埋めました 。 キャプチャとは何か-dofiga！
- 日中のサイトでの704,617ページビュー
- 2000個のプロモーションコードが配布され、そのうち473個が同じ日にブランド化されました 。 最初の注文は10:45に配達されました。 イベント後2時間以内
- 約5.6分に1回プロモーションコードを発行しました
- この日に7776個のアカウントが登録されました
主題のそれらのためのより多くの数
- MySQLは最大で毎秒13,380クエリを処理しました
- ネットワークの最大スループットは1,214.35Mb / sでした
- プロバイダーへの最大チャネル幅は76M.b / sをわずかに超えました
- 最大で、 アクティブなTCP接続は84,220でした 。
- 32個のボットを禁止しました。
- あまりにも多くのトラフィックをリダイレクトする外部サイトを配置しました（ごめんなさい、 Pachube ！）
使用された実際のインストール
これをやったように-再び、オタクのために。 最初の2つのプロモーションに参加した場合は、今年のプロモーションがはるかに良くなったことにお気づきかもしれません。 サイトが最初の数分で窒息したという事実を除外すると、参加者の最大の流入が起こったときに、サイトは非常によく応答しましたが、実際には膨大なトラフィックを処理しました。 前年と比較して何が変わったのですか？
私たちはいくつかのソフトウェアをサーバーに引っ張りました。 16個のコアと32個のギガバイトのRAMを備えた、いくつかの太い小さなWebサーバーがあり、ハードロードバランサーがあります。
さらに、ハードウェアで動作するように独自のコードを最適化し、一部のオープンソースソフトウェアを変更しました。 また、ApacheからNginxに切り替えて、PHP-FPMがすべての処理を処理しました。 このすべての前に、ワニスは、判明したすべてのものをキャッシュすることをまだ続けています-これは、アクションを保持するために非常に有用であることが判明しました。
また、過去数年で、遅延のほとんどがMySQLブレーキによって引き起こされていることに気づいたため、MongoDBであちこちでそれをバックアップしました。 一部の（特に階層データ）場合、これは理にかなっています。 これにより、ページを非常に高速に表示することができました。 残念ながら、PHP Mongoドライバーの小さなバグにより、アクションの最初の数分で行き詰まりました。
以前は、すべてのコンテンツをサーバーから直接提供していました。 ロードが正常であれば、問題ありません-ページは正常にロードされ、小さなチャネルを使用します。 当然、休日の間に、すべてが変わります。 今年、すべての静的コンテンツをAmazon Cloudfrontに掛けました。 Cloudfrontは、よく知られているS3ウォッチドッグの上に置かれ、コンテンツをエッジサーバーから世界中のユーザーにロードするグローバルCDNです。 もちろん、この場合、負担は私たちではなく、彼らにあります。 しかし、これではあまり節約できません。 サーバーを通過した76Mb / sは、基本的にgzipで圧縮されたテキストでした。
ガイガーカウンター？
まあ、何。 コンピュータサイエンスに精通している人なら、コンピュータが生成する乱数は実際には擬似乱数であると言うでしょう。 それらは予測することができます-たとえ成功する可能性が100万分の1あるとしても、これはまだチャンスです。 それでは、完全にランダムなシステムをどのように構築しますか？
バックグラウンド放射を測定するために、ガイガーカウンターを選択しました 。 カウンターは、荷電粒子を見るたびにコントローラーの足を下ろします-これは絶対にランダムに発生します。 Ethernet Proをインストールしてこれらの中断を監視し、Webサーバーの1つにあるデーモンにバイトを送信して、次の復号化キャプチャに勝利を通知します。
dunyaのコードは次のとおりです。
#include <Ethernet.h> #include <SFEbarGraph.h> #include <SPI.h> // Default 'ino MAC address byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED }; byte ip[] = { 192, 168, 0, 2 }; int up = 8; int down = 7; int upstate = 0; int downstate = 0; // replace with your server byte server[] = { 192, 168, 0, 1 }; EthernetClient client; SFEbarGraph BG; volatile int counter = 0; int oldcount = 0; int target = 8; int multiplier = 2; void setup() { BG.begin(1, 9); // Interrupt from the Geiger tube attachInterrupt(0, detect, RISING); Serial.begin(9600); Ethernet.begin(mac, ip); // set up buttons pinMode(up, INPUT); digitalWrite(up, HIGH); pinMode(down, INPUT); digitalWrite(down, HIGH); delay(1000); } void loop() { // read up button if(LOW == digitalRead(up)) { if(0 == upstate) { target++; redraw(); upstate = 1; } } else { upstate = 0; } // read down button if(LOW == digitalRead(down)) { if(0 == downstate) { target--; redraw(); downstate = 1; } } else { downstate = 0; } if(counter == oldcount) { delay(1); return; } oldcount = counter; // handle wins if(counter >= target) { win(); counter = 0; oldcount = 0; return; } redraw(); } // for the interrupt void detect() { counter++; } void redraw() { // boundaries if(target > (30 / multiplier)) target = (30 / multiplier); if(target < 1) target = 1; BG.clear(); BG.send(); BG.barGraph(counter * multiplier, target * multiplier); } void win() { Serial.println("WINNER"); for(int i = target * multiplier; i >= 0; i--) { BG.barGraph(i, target * multiplier); delay(35); } if ( ! client.connected()) { Serial.println("connecting..."); if (client.connect(server, 5555)) { Serial.println("connected"); } else { Serial.println("connection failed"); } } // Print a 1 to the Ethernet server for every win client.print("1"); }
トピックを閉じるために、Benが1秒あたり数百のリクエストを処理するために書いたビットサーバーコードを次に示します 。 彼は、毎秒最大60万件の要求の負荷でテストしました。
まあ、そして誰が英語を知っている- この投稿のコメントを読んでビデオを見る喜びを否定しないでください。 そこでは、人々がキャプチャを愛しているかどうかがわかります。
翻訳者と投稿の著者から：翻訳は非常に無料です-私を責めないでください。 気分はそのようであるか、または何もない。