ユーザーが増えるとカスタムフィードが落ちることを考える
この図、ちょっとわかりにくいので、「投稿する」というアクションに絞ってこの図に追記していきます。 投稿をカスタムフィードジェネレーターに反映する 右上にBlueskyのアイコンがありますが、これが公式アプリやWeb、TOKIMEKIなどのサードパーティクライアントを意味しています。投稿すると、AppViewからPDSいわゆるきのこサーバーに投稿が保存されます。その内容は別のユーザーに伝える必要があるため、Relay(Firehose)を通じて別のサーバーに連携されます。フィードジェネレータはRelayからどのような投稿がされたかを初めて知ることができるようになっています。 この例では「投稿」という説明になっていますが、現実には 他人が投稿に対するリポストしたり引用したり解除したり いいねをつけたり消したり 本人が投稿を削除したり 誰かが誰かをフォローしたり解除したり プロフィールを更新した
sidekiq の scheduled jobの性能 - ogidowの日記
sidekiq と scheduled job ruby でよく使われるジョブキューにsidekiqというものがあります。 Rails などでは Active Job のバックエンドとして使うこともできます。 sidekiq は即時的に処理を行うだけではなく、Scheduled Jobという機能があり、例えば以下のようにすると1時間後にjobを実行することができます。 MyJob.perform_in(1.hour) # active job MyJob.set(wait: 1.hour).perform_later また、即時で実行したい場合には以下のようにします MyJob.perform_async # active job MyJob.perform_later sidekiq の queue の実装 sidekiqでは、queueにredisを使用しており、即時実行用の queu
JavaScriptはなぜシングルスレッドでも非同期処理ができるのか/Why Can JavaSctipt Invoke Asynchronous in Single Thread?
JavaScriptはシングルスレッドであることが知られています。そして、Promiseを用いた非同期処理ができることは周知の事実です。では、なぜシングルスレッドで非同期処理ができるのでしょうか？ その点について、非同期処理のための2種類のQueuesについて触れつつ、コードベースでの説明も行います。
Suicaのシステムがいかにすごいか仕組みを徹底解説 - 炎と硝煙にむせる開発現場から
Suicaの凄さ サービスを落とさないための「自立分散高速処理技術！」 ものすごい処理量をこなす緻密な速度改善 お金を扱うからこそ間違わない仕組み 当時は最先端の非接触ICカードを採用 非接触ICカードの歴史 年寄りも当たり前に使えるサービス だからSuicaは６０００万枚も普及した まとめ Suicaの凄さ ものすごい処理量（1日4000万件） 全然サービスが落ちない 年寄りも使っている Suicaがない社会なんて今や想像できないですよね？東京でSuica持ってない人はいないくらい普及していますし、レストランやコンビニでSuicaを使って買える場所も普通になってきました。普通に考えて、1日4000万件も処理して0.1秒以内に処理を完了させないといけないシステムなんて無茶苦茶難しくないですか？しかも、Suicaがリリースされたのは2001年です！ちょこっと調べてみたすごいブレークスルーの数
MySQLのInnoDBプライマリーキーのチューニング | Yakst
[MySQL]原文 Tuning InnoDB Primary Keys - Percona Database Performance Blog (English) 原文著者 Yves Trudeau 原文公開日 2018-07-26 翻訳依頼者 翻訳者 kakuka4430 翻訳レビュアー doublemarket 原著者への翻訳報告 2055日前 原文へのコメントで報告済み 編集 良いInnoDBプライマリキーを選ぶことは、パフォーマンスチューニングの方向性にとても重要です。この記事では、あなたのワークロードに応じた最適なプライマリキーを選ぶための方法を紹介したいと思います。 Percona社のプリンシパルアーキテクトとしての私の責務の一つは、顧客のデータベースをチューニングすることです。パフォーマンスチューニングに関連する側面は多く存在し、それがこの仕事を複雑、かつ大変興味深いものに
Gitのコミットハッシュ値は何を元にどうやって生成されているのか | メルカリエンジニアリング
こんにちは。サーバサイドエンジニアの @DQNEO です。 前回の「Gitのつくりかた」に続いてGitのコアな部分のお話です。 Gitのコミットハッシュ値とは何か Gitを使っていると必ずコミットハッシュ値というものが出てきます。9e47c22みたいなアレです。 これはある特定のコミットを指し示すIDとして使うことができます。 では質問です。 このコミットハッシュ値は「何を元に」「どうやって」計算されているでしょうか？ 「ある特定のコミット」とはそもそも何なのか この問題を考える前に、まず「コミットとは何か」を明らかにしておきましょう。 コミットというと「コミットする行為」すなわち「動作」のことを想像するかもしれません。 しかしGitの内部構造的観点から言うと、Gitが管理記録しているのはコミット行為の結果生成されたデータの方です。 この「コミットによって生成されたデータ」のことを「コミッ
.git/objectsについて少し調べてみた - 煙と消えるその前に
事の発端はささいな出来事。仕事でgitを使っていて、開発中のソースからビルドしたバイナリファイルもリポジトリに突っ込んで管理してる。最近やけにgit cloneした時に時間がかかるなーと思って見たら、リポジトリサイズが200Mb超えてる？！よくよく見たら.git/objects以下が肥大化してた。なんだこれ、と思って調べてみた。 こちらが大変参考になりました： Git - Gitオブジェクト Git - パックファイル gitのcommit objectの中身 - HAKOBE blog ♨ 見えないチカラ: 【翻訳】Gitをボトムアップから理解する ざっくりまとめ gitではcommit、tree、blob、3種類のオブジェクトでリポジトリを表現してる blobがファイルそのもの。ただしファイル名などのメタデータは含まない treeがディレクトリ。blobや配下treeのハッシュ値を持ち
JavaScript の仕組み：メモリ管理+ 4つの共通のメモリリーク処理方法 - Qiita
この記事は sessionstack blog に投稿されている、How JavaScript works シリーズの一記事 "How JavaScript works: memory management + how to handle 4 common memory leaks" の和訳です。投稿されたのは Alexander Zlatkov, 原文はこちらです。翻訳については許諾いただいています。 メモリ管理もしくはC言語におけるメモリ解説他、用語なども怪しい箇所は多分にありますので、間違いがありましたら修正のご指摘・編集リクエスト等ください。 日本語の参考 URL 先に日本語の参考URLを記載しておきます。 JavaScriptで起こるメモリリークのパターン - EagleLand Browser Computing Structure // Speaker Deck Unders
コンビニでわかるノンブロッキングIO - たけぞう瀕死ブログ
NginxやNetty、Node.jsなど日常的に利用されているミドルウェアでも主流になりつつあるのにいまひとつ正しく理解されているのかどうか怪しいノンブロッキングIOですが、その概念について社内の技術共有会でコンビニを題材に説明していたのが面白かったので少しアレンジして紹介してみたいと思います。 ここではスレッド、CPU、リクエストを以下のように表現することにします。 店員＝スレッド レジ＝CPU 客＝リクエスト 1. シングルスレッド×ブロッキングIO まずは最も単純なシングルスレッド×ブロッキングIOです。図にするとこんな感じです。 店員（スレッド）が１人しかいないので同時に１人のお客さんしか処理できません。また、現実にはあり得ませんが、店員はアルバイトを始めて間もないのか、お弁当の温め中も電子レンジに張り付いており、温め終わるまで次のお客さんは待たされてしまいます。 2. マルチス
Gitのコミットの裏側で起こっていること - LIVESENSE ENGINEER BLOG
はじめまして。１ヶ月でエンジニアになろうとした山浦です。 先日Gitのことを突っ込んで調べる機会があり、Gitの仕組みって面白いねということを同僚に話していたら「面白いね。ところでGitって実装できる？実装できないと分かったとは言えないよね？」となぜか煽られるということがありました。 そうか、実装できないと分かったとは言えないのか、それも一理あるかもしれない。そう思い、Gitの仕組みを実装できるレベルまで掘り下げて調べてみました。 今回は実装はしないものの（過度に記事が複雑になるので）、Gitの根幹である git add コマンドと git commit コマンドの裏側で起こっていることを紹介します。 差分かスナップショットか？ ここで早速クイズです。 コミットで保存されているのはソースコードの差分でしょうか？スナップショットでしょうか？ 今回の記事の中で解説していきますので、少し考えなが
『PiggPARTYでのリアルタイム通信の仕組み』
ピグ事業部でサーバーサイドエンジニアをしている有馬です。 先日、弊社よりスマートフォン向けネイティブアプリとして、 「PiggPARTY」がリリースされました。 ピグパーティ iOSアプリ ピグパーティ Androidアプリ PiggPARTYは、スマートフォンのアプリ上で、 顔や洋服などの様々パーツを組み合わせて、自分好みのピグ（アバター）を作成することができ、 渋谷エリアや、原宿エリアといった現実を模したエリアや、 好みの家具で模様替えした自分のお部屋でパーティ（イベント）を開催したり、 他のユーザーと、テキストチャットやスタンプなどで、 リアルタイムにコミュニケーションを楽しむことができるサービスです。 PCアメーバピグをご存じの方には、そのスマートフォン版というと伝わりやすいかもしれません。 PiggPARTYでは、同期的なリアルタイムコミュニケーションを実現するために、 新たにリ
ChatWorkのリアクティブシステム導入事例から学ぶActor設計プラクティス
Actorの設計プラクティスに関して簡単にまとめた資料です
LINE LIVE チャット機能を支えるアーキテクチャ - LINE ENGINEERING
! This post is also available in the following languages. 英語, 韓国語 LINE株式会社のOklahomerです。 本記事では、LINE LIVEという動画配信サービスのチャット機能が、どのような構成で成り立っているのか紹介します。 チャットの紹介 LINE LIVEのiOS/Android アプリでは、配信中の動画を視聴しながらリアルタイムにコメント投稿できるチャット機能を提供しています。この機能の役割は、視聴者同士が対話を楽しむだけにとどまりません。配信者が視聴者のコメントに返答するという形で配信者と視聴者の接点として機能したり、また配信者がコメント内容に従って企画を進めるなど、配信者と視聴者が一体となって配信を作り上げていく上でも重要な機能となっています。 これが有名人による配信となれば当然視聴者数も多くなりますし、その配信
Mastodon インスタンスのリモートフォローの仕組みと必要な購読更新の設定方法 - Qiita
[追記]Mastodon バージョン1.3.3がリリースされて、このページに書いている不具合は解決されて、今後は発生しなさそうです。このページも御役御免ということですね。問題にハマってる人は1.3.3にアップデートしましょう。 Mastodon のインスタンス運営をする上で、v1.3.2以下の Mastodon の設定が悪いとリモートフォローのユーザーの投稿がある日突然見えなくなることがあります。逆に相手サーバーの設定が悪いとせっかくリモートフォローしてくれたユーザーの投稿が届かなくなります。原因はいくつかあって、主に 受信側の購読の更新設定が出来ていなくて７日で期限が切れた場合 受信側サーバーのエラー時に送信側が投稿し購読が解除された場合 受信側か送信側の SSL の Mastodon への設定ミス の３つが挙げられます。 まず、なぜそもそも購読とか期限とか、ややこしいことが必要なのでし
出版-購読型モデル - Wikipedia
出版-購読型モデル（しゅっぱん-こうどくがたモデル、英: Publish/subscribe）は、非同期メッセージングパラダイムの一種である。メッセージの送信者（出版側）が、特定の受信者（購読側）に直接メッセージを発行するプログラムではなく、発行（出版）されたメッセージはクラス分けされ、どんな受信者が居るのかは知らない。受信者は興味のあるクラスを指定しておき、そのクラスに届くメッセージだけを受け取り、どんな送信者が居るのかは知らない。送信者と受信者の結合度が低いため、スケーラビリティがよく、動的なネットワーク構成に対応可能である。 出版-購読型モデルはメッセージキューパラダイムと対比され、一般に大きなメッセージ指向ミドルウェアの一部として使われる。一部のメッセージシステム（Java Message Serviceなど）は、出版-購読型とメッセージキューの両モデルをサポートしている。 出版-
Pub/Subメッセージングモデル
Pub/Subメッセージングモデルは，パブリッシュ・サブスクライブ（Publish-Subscribe）方式でメッセージを送受信するためのモデルです。 ＜この項の構成＞ (1) Pub/Subメッセージングモデルによるメッセージの送受信 (2) Pub/Subメッセージングモデルの特徴 (3) 永続化サブスクライバーの利用 Pub/Subメッセージングモデルでは，メッセージを作成して送信する送信側のクライアント（プロデューサー）をパブリッシャーといいます。また，メッセージを受信する側のクライアント（コンシューマー）をサブスクライバーといいます。 パブリッシャーから送信されたメッセージは，トピックという送信先に登録されます。トピックに登録されたメッセージは，そのトピックに対して配信を申し込んでいた一つまたは複数のサブスクライバーに配信されます。 Pub/Subメッセージングモデルでのメッセー
Nianticの求人から推測する『Pokémon GO(ポケモンGO)』のサーバ構成 - Qiita
1ワールドで済ますというチャレンジ Nianticの求人を見ていて、凄く驚いたのは、「Software Engineer - Server Infrastructure」での次の項目。 all on a single, coherent world-wide instance shared by millions of users. 対訳 全ての(アクション)は、数百万のユーザーに共有された単一の一貫した(サーバ群で行われる) つまり、ポケモンGOは１ワールドで構成されている。MMOのサーバを作ったことがある人なら5それがどんなに大変かピンとくるだろう。特に、ポケモンGOの様に一日に数百万人とかが遊ぶゲームで、1ワールドでゲーム世界を構築するのは、結構大変だ。6 MMOで1ワールドがなぜ大変か(データストレージとの戦い) MMOの様なオンラインゲームで、1ワールドがなぜ大変かを図示する。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Shopifyはいかにしてモジュラモノリスへ移行したか
ノンブロッキングI/Oと非同期I/Oの違いを理解する
Akka ActorとAMQPでLINEのメッセージングパイプラインをリプレースした話
