habro-peopleのリクエストに応じて、短い技術レポートを投稿しています。
Eventrは、RSSフィードを簡単に読んだり、2回クリックするだけで交換したり、興味深い投稿を他の人と共有したり、ブログを管理したりできるWebサービスです。
7月11日日曜日の午後に開始し、 1時間後にhabraeffectの下に横たわりました 。 実際に、私たちの魔法の呪文と数字はカットの下にあります。
何が言われます：
- いくつかの技術的な問題
- RSS / Atomリーダー、数字
- Habraeffect、数字
- すくい
- Mongodb、nodejs、redis
水曜日の時間-開始から3日
3,050ユーザー
1秒あたり平均5件のレコードを読む200人のオンラインユーザー
22,340スレッド（うち18,546は外部rss / atomフィード）
バックグラウンドサーバーによって更新される毎秒25フィード
811,614件のニュースアイテム（ユーザー生成を含む）
合計47.032フィードの727のインポート（繰り返しを除く）
207件のユーザーフィードバックの処理
打ち上げ
別の記事で前述した主な技術的側面。 それ以降、何かが変更され、「動物園」にredisとcapistranoが追加されました。
主な問題は、空のデータベースです。 無制限の数のフィードで無制限の数のOPMLインポートに耐える必要があり、最も重要なことは、限られた期間でした。 負荷を予測するのは非現実的なタスクだったので、歯を食いしばって、 LAがどのように成長し、サーバー上のキューのサイズを見るかを見てみました。
現時点で、システムにとって最も難しいのは、18,000以上の外部ソースを最新の状態に維持することです。 また、各ユーザーの読み取りレコードの個別のレコードを保持します。 それ以外は人生のささいなことです。
Habraeffect、数字
登録のスケジュール/ OPMLのインポート/合計フィード
このグラフには、インポートの数が10分単位で表示されます。 ユーザーの増加とシステム内のフィードの総数の横。 私たちは最初の日にそれのほとんどを引き出しました。
後続のインポートでは既存のフィードが使用されました。
その他の番号
モンゴッド：
総資産：1,028,554
合計サイズ：3.17 GB（うちフィードからの2.76 GBコンテンツ）
インデックスサイズ：465 MB
CPUが食い尽くす：〜2％
RAMを食べる：3.2 GB
中間ページの複雑な出力のモンゴ時間（キャッシュなし）：0.3秒
ロックはほとんど感じられません。
Nodejs：
メモリを食べる：〜20 MB
CPUはまったく食べません。
すくい
弱いサーバー。 最初は、2台の物理サーバーと12台のopenvz仮想マシンから始めました。 アイデアは単純です。負荷が増大しています-新しいハードウェアを購入し、既製の画像を移行しています-非常に便利です。
最初のエラーは、より弱いサーバー上のWebインスタンス（nginx、php-fpm）です。 ほぼ即座に-LA 40、その後、彼はsshへの応答を停止しました。 それをより強力なサーバーに転送するのに30分かかりました。
負荷下でのMongodbレプリケーション。 弱いサーバーに配置されたそのmongoスレーブには、oplogを読み込む時間がなく（同期のため）、静的バージョン（その時点でmongoに保存されていた）が失われました。 後に、一部のユーザーは、スタイルや写真のない非常に美しいイベントを見ました。 静的バージョンをredisに移動しました。
1つのサーバー上のシステムキューとユーザーキュー。 システム内のフィードが多いほど、（関連性を維持するために）永続的に更新する必要があるリソースが増えます。 サービスの30分後、キューは完全にバックグラウンドで更新され、インポートまたは外部フィードの個別の追加という形でユーザーリクエストに取って代わりました。 その時点で、キューには平均5〜15,000のタスクがありました。
最も暑い時期に、新しいサーバーで輸送されている間に、ラップトップをキューに接続しました-それが助けました:)一方、インポートを持つユーザーはinしていました。
現時点では、4つのバックグラウンドサーバーがあります。 それらのうち3つはバックグラウンド更新用で、1つはユーザーキュー用です。 現在、18,000を超えるフィードを処理しても、インターフェースの速度やインポートなどのユーザーアクションには影響しません。
新しいサーバーがインストールされた後、蓄積されたキューをすばやくクリアするために、非常に深刻な負担をかける必要がありました。 その時点で、速度は100スレッド/秒に達しました。 現在、ベース全体を維持するには1秒あたり25で十分です。
Zend_Date 彼の呼び出しは、テンプレートのレンダリングにかかる合計時間の70％を占めていました。 ショックを受けた。 また、Zend_Viewパーシャルおよびプレースホルダー-これらは一般に放棄されました。
楽しいひととき
モンゴッド
彼はとてもいい数字を見せてくれました。 インデックスは時計仕掛けのように機能します。 便利な管理、スケーリング、そして最も重要なこと-移行。
nodejs
とてもシャープ。 便利で迅速な開発。 完全なガベージコレクションとフォールトトレランス。 背景全体が機能することを考慮して（ 前の記事で詳しく読みます ）、nodejsを開発中ずっと見てきた中で最も楽しいものと呼ぶことができます。 唯一のものは、mongodbを操作するためのあまり便利ではないインターフェイスです。 redisを使用すると便利です。
redis
その上：キャッシュ、キュー、ロック。 超高速で非常に快適です。 また、サーバー間の通信には、そのPubSubが使用されます。 リアルタイムのアイテムに最適です。 PHPでは、 大根を使用します。サポートについては、 Shumkovに特に感謝します。
カピストラーノ
みんなにお勧めします。 日常の手作りから10インスタンスをデプロイすることは、マルチカラーコンソールの快適な熟考に変わります。
zabbix
nagiosと比較して、それは私にとってより便利であることが判明しました。 特定のトリガーを追加して、それらから美しいリアルタイムグラフィックを取得するのは非常に簡単です。
一般的に
私たち自身にとって、決定的な行動はエラーにつながる可能性があることを改めて認識しましたが、結論を引き出すことができるのはまさにエラーです。 そして、過去だけでなく多くの新しい潜在的な間違いを避けるために、結論を引き出しました。つまり、前進し、発展することを意味します。 そもそも、サービスが人々にとって本当に有用で必要になるのを支援できるのは、分析アドバイザーではなくユーザーであることに気付きました。
フィードバックをお送りいただいたすべての方々と、最初のベータeventr.comのすべてのユーザーに感謝します。
サービスの信頼性と利便性の向上に引き続き取り組んでいます。
ありがとう