どうもキャッシュバスターズ、 id:Soudai です。 Cache（以下、キャッシュ）は特定の場面に置いて劇的な効果を発揮し、様々な問題を解決する反面、新たなコンポートやミドルウェアが追加され、複雑性が上がり、運用のレベルが上がるため、扱いに注意する必要があります。 キャッシュを活用することで、パフォーマンスの改善や負荷軽減が行われ、コンピュータリソースの最適化によるサーバコストの削減や、レスポンスの改善によるユーザエクスペリエンスの改善がされます。 反面、その劇的な効果に毒され安易に多用すると、サービスが強くキャッシュに依存してしまい、非常に壊れやすくなり、運用が難しくなってしまいます。これをWeb界隈では「キャッシュは麻薬」と比喩されて、戒められてきました。 そのためキャッシュを使わずにサービスが運用できるのであれば使わないに越したことはないのですが、ある一定以上の規模になった際にコ
PHPerKaigi 2024の登壇資料です。 https://phperkaigi.jp/2024/ - https://speakerdeck.com/moznion/pattern-and-strategy-of-web-application-caching - https://soudai.hatenablog.com/entry/cache-strategy
自分が開発しているLaunchableのWebアプリがローンチされて1年半ほどになる。このWebアプリにはReduxのような状態管理ライブラリを入れないまま開発してきたのだが、今のところ困らずに開発できている。そういえば昔自分は状態管理について何か考えていたような…とブログを掘り起こしてみた。 ninjinkun.hatenablog.com このエントリは2016年にネイティブアプリを対象にして書かれているが、この後自分は2018年ごろにWebフロントエンドに軸足を移し、ネイティブアプリ開発から離れた。なのでこのエントリはWebフロントエンドエンジニアが2022年に再考した話になる。 結論としては、当時自分が管理したかった状態のほとんどは現在ApolloClientのキャッシュによって解決されている。 繰り返しになるが、自分が開発しているLaunchableのWebフロントエンドには状態
LAPRAS株式会社でSREをしていますyktakaha4と申します 🐧 私は 2021 年の 1 月に LAPRAS に入社 したのですが、 入社以来ほそぼそとやってきた、ドキュメンテーションに関する取り組みについて一年ほど運用し一区切りがついたので、その話をしたいと思います✍ ことのおこり 現在弊社には正社員・業務委託あわせて 18 名程度のエンジニアが在籍 していますが、 私が入社した頃はエンジニアが7名程度、かつ全体の人数に対して在任歴の長い人が多かったこともあり、 開発者が参照するドキュメント管理について、比較的牧歌的な運用がなされていました 🐑 具体的には、開発環境の構築方法が古い手順のまま放置されていたり、オンボーディングに使うドキュメントが口伝されていたりと、 ドキュメント自体は存在するものの、それらが 古くなっていたり一覧化が不十分であることが検知できず、時間経過に伴
本書は、未来のプログラマ、コンピュータ設計者のために書かれた、Raspberry Piを題材にコンピュータの「仕組み」、コンピュータサイエンスの基本を学ぶ書籍です。Raspberry Pi開発者たちが、プロセッサ、メモリ、ストレージ、ネットワーク、オペレーティングシステム、プログラミング、3Dグラフィックス、オーディオ、そして入出力制御などについて、それらの歴史的な背景なども合わせて詳細に解説を行います。また、解説内容の一部は、実際にRaspberry Piで動かしながら学ぶことも可能です。 はじめに ケンブリッジ ここからが本題 成長曲線の伸び悩むところ 将来に向けて 監訳者まえがき 1章 驚くべきコンピュータの姿 おいしくて果汁あふれるラズベリーの成長 SoC わくわくするクレジットカードサイズのコンピュータ Raspberry Piに何ができるか？ Raspberry Piボードの紹
Windows11のバージョンはこんな感じ。 キャッシュ・メモリのレイテンシ まずはレイテンシから。最初はキャッシュの構造の見やすい少し規則性のあるアクセスパターンから。 5950Xは一つのコアから見えるL3キャッシュは32MBなので、Windows10ではそのぐらいまでレイテンシが低い状態が続き、まあこれが想定される状態なのだけど、Windows11では2MB(2048KB)ぐらいから急激にレイテンシが上昇し、メモリアクセスと変わらない感じになってしまっている。 完全ランダムアクセスの場合も同様で、Windows11では2MB(2048KB)以降でキャッシュが見えなくなっているみたい。 キャッシュ・メモリ帯域 今度はシングルスレッドの帯域。 Windows10では32MBまでL3キャッシュによると思われる高い帯域が持続するが、Windows11では2MB(2048KB)以降メモリアクセス
キャッシュ入門 - Qiita
概要 モダンなウェブアプリケーションを開発していくにあたり、サービスのパフォーマンスを向上したいと思うケースってよくありますよね。 きっとその際に、インメモリデータストアとキャッシュ技術を利用し高速なパフォーマンスを実現することも解決策の１つになると思います。 Memcached や Redis、AWSを利用していればそれらソフトウェアの互換性のあるフルマネージドサービス Amazon ElastiCacheなどを利用しているんじゃないでしょうか。 今回は、そんなキャッシュ技術について、そもそもキャッシュってなんだっけを改めて振り返る記事となっております。 ※本記事は Umer Mansoor さんが執筆されたBrief Overview of Caching and Cache Invalidationの内容を基に翻訳し、加筆、独自解釈したものです。 ※ Umer Mansoor さんか
ZennではフロントエンドにNext.jsを使っています。もともとはVercelで動かしていたのですが、2021年3月にGoogle Cloudに移行しました。今回は移行を決めた理由や、具体的な構成、移行作業などについて書きたいと思います。 なぜ移行したのか Next.jsのデプロイ先としてVercelは圧倒的に優れています。ISRやImage OptimizationといったNext.jsの強力な機能をサーバー側の追加設定なしで使用できますし、CDNでの静的ファイルのキャッシュなども特に意識しなくてもいい感じにやってくれます。 Vercel以外にデプロイするとなると、Next.jsの一部の機能がうまく動かなかったり、パフォーマンス・チューニングを自分で頑張る必要があったりと自分で面倒を見なければならない部分が多くなります。 しかし、Zennのケースでは以下のような理由からVercelから
あなたのプロダクトに Apollo Client は必要ないかもしれない - 一休.com Developers Blog
Apollo Client は複雑 Apollo Client が向いているケース 一休.com に Apollo Client は必要ないかもしれない では何を使えばいいの？ 複雑なアプリケーションには Apollo を使えばいい？ もう一つのリッチなクライアント、Relay の話 結局、何を使えばいいのか この記事は一休 × 出前館 Frontend Meetup でお話した内容をブログにまとめたものです。 user-first.ikyu.co.jp speakerdeck.com GraphQL クライアントと聞いて一番に思い浮かぶライブラリは何でしょうか？ 多くの方にとっては Apollo Client ではないかと思います。npm trends を見ても Apollo Client のダウンロード数は urql や relay などほかのクライアントと比べ圧倒的です。 実際、一休
一休レストランで Next.js App Router から Remix に乗り換えた話 - 一休.com Developers Blog
このエントリーは一休.com Advent Calendar 2023の15日目の記事になります。 CTO 室の恩田です。 現在は一休レストランのフロントエンドのリアーキテクトを手がけています。 今日はその中で Next.js App Router から Remix に乗り換えた話をご紹介したいと思います*1。 背景 6日目の記事で香西から紹介させていただきましたが、2023年10月に一休レストランのスマートフォン用レストラン詳細ページをリニューアルしました。 一休レストランの Rust バックエンドが正式リリースされました。https://t.co/7N4VGv5ej9 このページのスマートフォンビューはバックエンドが Rust で書かれた GraphQL になってます— naoya (@naoya_ito) 2023年10月4日 ちなみにフロントエンドも、旧バージョンは Nuxt v2
「お参りという風習を日本の文化として残していきたい」 480年の歴史を誇る万松寺の境内に設置された小型自販機は、ツイッターユーザー「でまえ－T（＠d_itchou）」さんによって2023年3月26日、冒頭のような文で紹介された。 販売されているのは、本尊の十一面観世音菩薩が描かれたオリジナルコイン「Banshoji Coin」だ。自販機はキャッシュレス決済に対応しており、コインは1枚500円から、10枚入りまでのパッケージが展開されている。説明書きは日本語、英語、中国語の3か国語で記載されている。お土産になるだけでなく、賽銭や施設内通貨としても使用できるという。 投稿は注目され、「投げ入れてよし、お土産にしてよし」「いろんな問題を１つで解決しているのが素晴らしい」「伝統も失っていない」「考えた人は凄いね」といった声が寄せられている。小銭が無くともお参りでき、運営にとっては小銭の盗難防止にな
いわくら君が書いてくれた通り 、トラベルブックではFastlyを導入しました。Fastlyについて初めて分かったことがたくさんありました。列挙してみたら30個もあったので、一個ずつ紹介してみることにします。 そもそもFastlyとは そもそもFastlyとはCDNのサービスです。現在では後述するCompute@Edgeを主力としたサーバーレス環境を推していますが、とにかくCDNです。今回は www.travelbook.co.jp ドメイン全てに対して適応し、全てのHTMLページをFastly経由にしました。 もともとVarnishでページをキャッシュしていた部分をFastlyに置き換えることで冗長化・安定化、また、パフォーマンスアップを図ります。 加えて、これまでキャッシュの対象外だったページも、この際TTL付きでキャッシュする、というのが今回やったことです。 詳しくはいわくら君の書いた
GitHub ActionsでDocker Buildするときのキャッシュテクニック - cockscomblog?
GitHub Actionsでdocker buildすることが多い。このときのキャッシュをどうするかという話題。 基本 GitHub Actionsでdocker buildしてAmazon ECRにdocker pushする、典型的な.github/workflow/docker-push-to-ecr.ymlはこういう感じ。 name: Push to Amazon ECR on: push: branches: [ 'main' ] jobs: docker: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: docker/setup-buildx-action@v1 - name: Configure AWS credentials uses: aws-actions/configure-aws-c
Dockerに関するキャッシュたち
はじめに Dockerを用いた開発では、適切にキャッシュを用いることで高速にビルド・開発できます。そのための知見は様々な記事で共有されており、ありがたい限りです。 しかし、「Dockerのキャッシュ」と言っても開発時とCI・CDでは行うことが違います。 この記事ではDockerを用いた開発における、各段階のキャッシュ機能を確認したいと思います。 主に「Dockerのキャッシュ」というと以下の4つに分類できると思いますので、それぞれについて解説していきます。 Dockerのレイヤーキャッシュを活かす a. COPY・ADDの順番 b. dockerignoreの設定 c. マルチステージビルド buildkitによるキャッシュ a. --mount=type=cache CI・CDにおいてのキャッシュ a. 前回のビルドキャッシュを持ち越して使う リモートキャッシュ a. 開発者が初めてビル
キャッシュレス決済がこんなに便利だって想像できた？
このごろのキャッシュレス このごろいくつかキャッシュレスの話題をネットで見かけた。 飲食店などが、キャッシュレス決済の手数料の高さに困っている、という話である。おれはそういう商売に携わったことがないのでわからないが、なるほど高そうだ。 とはいえ、この問題で小売店に同情する声というのはあまりない。ほとんどないといってもいいかもしれない。 「だったら現金オンリーにすればいいのでは？」という声が多い。「なじみの店、応援したい店では現金払いにしたい」という声もあるが、あまり多いとは言えない。 むしろ、オダギリジョーのCM（オダギリジョーの店に大口のお客さんがきそうになるが、キャッシュレス決済ができないことによって機会損失する……テレビをまったく見ない人向けの解説）のように、「じゃあいいですー」ってなるよ、という人が多い。現金まったく持ち歩かないよ、という人もいる。 おれは、どうなのか。おれはつねに
twitterでなんどもつぶやいてるので多分知られているとは思うんですが、Web配信の技術という本を書きました。 せっかくなんで、なんでまたこんな本を書いたのかとかどういう流れだったのかみたいなのを簡単に書いてみようかなと そもそもどういう本なのか 非常にタイトルを決めるのが難しい本でした。 サブタイトルに「HTTPキャッシュ・リバースプロキシ・CDNを活用する」とあるようにいわゆるHTTPキャッシュの本なわけですが、コンテンツ配信の技術といえばCDNの印象が強く出ますし（本書はCDNの使いかたというわけではないです）、Web配信といえば動画ストリーム配信（VTuberの配信とか）を思い浮かべる人も多いと思います。 今考えればWebコンテンツ配信の技術とすればよかったかもと思いつつ、今度は長くなりすぎるのでなかなか難しいです。 ということでHTTPキャッシュを使ってWebサイトを高速化した
これは はてなエンジニア Advent Calendar 2023 の 18 日目の記事です。昨日は id:gurrium による private-isuで70万点取るためにやったこと - ぜのぜ でした。私は 50 万点ぐらいで満足してしまっていたので、しっかり詰めていて凄いなと思う。 developer.hatenastaff.com Web アプリケーション開発において、「キャッシュは麻薬」という言葉がインターネット上をよく飛び交っています。YAPC::Kansai OSAKA 2017 の id:moznion のトークでよく知られるようになったワードじゃないかな。 初出はちゃんとは分からないんですが、少なくとも 2011 年には言われていますね。 「キャッシュは麻薬」とはよく言ったものだ。— TOYAMA Nao (@nanto_vi) November 5, 2011 キャッシ
アプリケーションなどOSより上に作られる高水準のプログラムではハードウェアの速度と容量を考慮しない数学的キャッシュアルゴリズムが使われ主にこれを本稿の対象とする。キー探索用マップと明示的キャッシュサイズ(対となる値が保持されているキーのサイズ)は計算量に含まれない。 LRU 最も単純かつ高性能な基礎的キャッシュアルゴリズム。そのため性能比較のベースラインとして常に使用される。逆に言えば実用最低水準の性能である。スキャン耐性皆無でスキャン一発でキャッシュとヒット率がリセットされゼロからやり直しになるため非常に脆く不確実な性能となりベンチマークにおける性能が表面上さほど悪くなく見えても実際の性能はこのような外乱により大きく低下しやすい。このためLRUより高度な主要アルゴリズムはすべて大なり小なりスキャン耐性を備えている。ちなみにプログラミング言語最大のパッケージマネージャであるJavaScri
Aurora MySQL でレコードが存在するのに SELECT すると Empty set が返ってくる事象を調査した話
こんにちは。 KINTO テクノロジーズの DBRE チーム所属のp2skです。 DBRE（Database Reliability Engineering）チームでは、横断組織としてデータベースに関する課題解決や、組織のアジリティとガバナンスのバランスを取るためのプラットフォーム開発などを行なっております。DBRE は比較的新しい概念で、DBRE という組織がある会社も少なく、あったとしても取り組んでいる内容や考え方が異なるような、発展途上の非常に面白い領域です。 弊社における DBRE の取り組み例としては、あわっち（@_awache）による DBRE ガードレール構想の実現に向けた取り組みについてというテックブログや、今年の AWS Summit の登壇内容を是非ご覧ください。 今回の記事は、データベースに関する課題解決の事例として「Aurora MySQL でレコードが存在するのに
いまさらキャッシュレス決済とか時代遅れ
これから投資するならレジレス決済だからね 現金とかQRとかクレカとかNFCとか、全部レジの仕組みを改修したり読み取り端末が必要になる。 そこで現在すき家やスターバックス、マクドナルド、KFCなどで導入の進むモバイルオーダーが代替する。 ビックカメラ.comやヨドバシのネット購入店頭受取と同じ仕組みが広く飲食店に普及するだろう。 ネット上の決済システムならハードに比べ機能追加は比較的容易、安価であり、サイゼリヤはこの方面を目指すのではないか。
こちらの記事は翻訳記事となります。 原著者の許諾を得て翻訳・公開しております。 英語記事: How to Write Fast Code in Ruby on Rails原文公開日: 2019/10/08著者: Gannon McGibbonURL: https://engineering.shopify.com/blogs/engineering/write-fast-code-ruby-rails はじめにShopifyでは、ほとんどのプロジェクトの開発フレームワークにRuby on Railsを使用しています。 RailsとRubyはともにパフォーマンスに対するスティグマ（偏見）が存在します。 多くの個人や企業が、Rails以外での解決方法を探しています。 しかし一方で、私たちShopifyではRuby on Railsを採用して、毎分何百万ものリクエスト（requests per
![[翻訳]ShopifyにおけるRuby on Railsで速いコードを書く方法](https://cdn-ak-scissors.b.st-hatena.com/image/square/f308745e76e38e4cdf49aa10fa16d47302907139/height=288;version=1;width=512/https%3A%2F%2Fmiro.medium.com%2Fv2%2Fresize%3Afit%3A1200%2F0%2Ao26-6XGJfoafCjrd)
今更聞けないDBMSのメモリ管理について
DBMSのメモリ管理について データベース管理システム（DBMS）の設計では、大量のデータと複雑なクエリを処理するために、ハードウェアの特性を最大限引き出すことが求められます。 この記事では、DBMSがどのようにメモリを使ってデータアクセスの速度を向上させ、同時にデータの安全性を確保しているのかを解説します。 DBMSと記憶装置の関係について DBMSが使う記憶装置は次の2つです。 HDD HDDは磁気ディスクを使用してデータを記録・読み取りする記憶装置です。その主な特徴は大容量であり、コスト効率が良いことです。DBMSでは、データの永続的な保存にHDDが用いられます。これにより、システムがシャットダウンされた後もデータが保持され、必要に応じて再びアクセス可能となります。 しかし、HDDのデータアクセス速度はメモリに比べて遅いため、リアルタイム処理や高速なトランザクションが求められるアプリ
第16回 StringBeginners での発表資料
＜デジタルマネーでの支払い方法が全盛の今、リアルな現金を使う若者がアメリカで急増中＞ 今や、デジタルマネーの隆盛期。使う、ためる、投資する......お金のやりとり全てで、デジタルがもてはやされる時代だ。ところが最近、Z世代の若者たちが好んで現金を使うようになっている。 世論調査機関のハリス・ポールが昨年行った調査によれば、アメリカのZ世代（1990年代後半から2010年代初頭生まれ）で現金を前年より頻繁に使った人は69％に達した。買い物の半数以上に現金を使った人も23％に上っている。 この調査結果は、多額の現金を金融機関に預けず自宅で保管しようという風潮と合致する。TikTok（ティックトック）では、クレジットカードやオンライン取引より現金を使うことがブームになっており、無数のアカウントが「キャッシュ・スタッフィング」という現金をベースにした節約術を解説している。 キャッシュ・スタッフィ
ウォレットアプリ「Kyash」と同期するKyash Cardが、本人認証サービス（3Dセキュア）に対応いたしました。Kyash Cardを発行しているお客さまであれば特別な設定をすることなく、本日より本人認証サービス（3Dセキュア）による決済ができるようになります。 これにより、より安心で安全なオンラインショッピングが可能となります。 ※Kyash Card LiteとKyash Card Virtualは3Dセキュア未対応 本人認証サービス（3Dセキュア）とはオンラインショッピングの際に、カード情報（カード番号・有効期限など）に加え、ユーザー自身が設定した「本人認証パスワード」を入力することにより、カード情報の盗用による「なりすまし」などの不正使用を未然に防止するサービスです。 本人認証サービス（3Dセキュア）の利用方法事前の設定やパスワードの暗記などが不要で、決済の際に以下の流れでご利
Googleが検索結果から、キャッシュされたページへのリンクを削除しました。 検索結果からキャッシュへのリンクがなくなっている 数日前から削除されていると指摘 Google検索ではこれまで、検索結果にキャッシュへのリンクが添えられていました。キャッシュされたページは、当該ページが見られない場合や、当該ページの古いバージョンを見たい場合に利用されていました。 数日前から、検索結果からキャッシュへのリンクがなくなっていると一部で指摘されていました。Googleは公式X（Twitter）アカウントで、ユーザーから「検索結果からキャッシュのリンクはなくなったのか」との問い合わせに、「削除されました」と回答。 「悲しいことです。Googleの最古の機能の1つでした。しかし、キャッシュのリンクはページを表示できないことが多かったときに、ページにアクセスするのを助けるためのものでした。今では大幅に改善さ
繰り返しますが、正確な図はプロセッサモデルによって異なります。ここでは見積もりのため、以下の目安で考えます。メインメモリのアクセスに60ns（ナノ秒）かかり、L1キャッシュへのアクセス速度はその約50倍高速だとします。 さて、プロセッサの世界には「参照の局所性（locality of reference）」と呼ばれる重要な概念があります。プロセッサがメモリ上の特定の場所にアクセスするとき、以下のように予測を立てます。 近い将来、メモリ上の同じ場所にアクセスする可能性が非常に高い これは「時間的局所性（temporal locality）の法則」です 近い将来、メモリ上のその場所からごく近い場所にアクセスする可能性が非常に高い これは「空間的局所性（spatial locality）の法則」です CPUにキャッシュが存在する理由のひとつが、この時間的局所性です。では空間的局所性を高めるにはど
難波 拓斗 | Nagomi-ke @nagomi_ke ‘00 | YouTube "Nagomi-ke" | -------- アナログ・デジタルを問わず、スタイルのあるモノやコトが好きです。 https://t.co/ETvj2wLao1
ただ、サーチリストがこうなっているのは利便性のためだけではなく、もっと切実な理由があります。 サーチリストとndots DNSの一般的な名前解決のルールとして、こんな風に覚えている方もいるかもしれません。 名前にピリオドが含まれていたら、FQDNとみなしてサーチリストを参照せずに名前解決を行う 名前にピリオドが含まれていなければ、サーチリストのドメインを末尾に連結して名前解決する 例えば、こんな具合です。 $ ping myhost # ピリオドが含まれていないため、myhost.example.comが名前解決される PING myhost.example.com (192.168.0.1) 56(84) バイトのデータ 64 バイト応答 送信元 myhost.example.com (192.168.0.1): icmp_seq=1 ttl=57 時間=12.4ミリ秒 $ ping w
npm install と npm ci って結局どう使うの？2023年版 - Mitsuyuki.Shiiba
うりうりさんの↓のコメントを見て、そういえばnpm ciって見たことあるけどチェックしてないなぁ。というかnpm installも雰囲気で使ってるなぁ。と思ったので、うりうりさんに教えてもらったことを手がかりに、npm installとnpm ciについて調べた。 これ、node_modulesキャッシュしてたり npm install使ってるけど npmのグローバルキャッシュ(~/.npm)をキャッシュした上で npm ciで早くなったりしないんだろうか GitHub Actions上でテストを約3倍早くした話https://t.co/MpmFktGBxU— wreulicke (@wreulicke) March 14, 2023 ちょこっと検索して見てみたところ、新旧情報があって自分が混乱したのと、公式ドキュメントには概要は書かれているものの詳しい内容は書かれていないので（僕が見つけ
一般ユーザー向けの大規模なWebサイトや、モダンWeb上で動作するWebアプリケーションを運営する場合、CDNなどのキャッシングサービスによって静的コンテンツをキャッシュすることが極めて重要です。 しかしこうしたサービスは、非常に複雑で分かりにくいものです。 幸い、IETF（Internet Engineering Task Force）のHTTPワーキンググループがこの状況を改善すべく、HTTPの新標準策定に取り組んでいます。 最近、同ワーキンググループでは、キャッシングのデバッグとキャッシュ設定の管理を容易にすることを目的とした、HTTPヘッダに関する2つの新標準案の発表に向けて活発な動きがありました。 このことが何を意味し、どのように機能するのか、そしてWeb制作に携わる開発者全てがなぜ注目すべきなのかについて見ていきます。 新標準 この記事で取り上げる標準案は以下の2つです。 Ca
その13 キャッシュメモリの効果
キャッシュメモリがメモリアクセスにおいてどれだけの効果を持つか、実験によって確かめます。 00:00 前置き 00:37 キャッシュメモリとは 04:20 実験方法 07:07 結果 09:08 まとめ テキスト https://speakerdeck.com/sat/kiyatusiyumemorifalsexiao-guo
2018年の初めくらいから、仕事でGraphQL APIを何度も作っている。サーバーサイドもクライアントサイドも実装している。 最近クライアント側にRelayを使ってみている。 GraphQLのクライアントとしてはApolloを使う場合が多いと思うが、Facebook製のRelayもかなりよくできている。以前はTypeScriptに対応していなかったが、今はTypeScriptも使える。最近のバージョンではhooksのAPIがexperimentalではなくなり、ReactのSuspense API（Suspense for Data Fetchingは使わずに）と合わせて使える。 RelayはGraphQLのスキーマに制約を設けることで、クライアント側のAPIがデータの再取得やページネーションなどを抽象化している。換言すると、Relayからデータの再取得やページネーションに必要なスキーマ
改心したはずのトーバルズ氏がまたもや感情的な暴言
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます Linux開発の中心人物であるLinus Torvalds氏は、自身の「自覚が高まり、強引な態度を控えるようになった」と考えている。Torvalds氏は、開発者コミュニティのメーリングリストであるLinux Kernel Mailing List（LKML）での暴言が原因で、2018年末にLinuxカーネル開発の現場を1カ月ほど離れていた。その後、復帰してからの自己評価が冒頭の発言である。 しかし、同氏が「必ずしも社交性が増したわけではない」と述べているように、メンテナーとのやり取りすべてが穏便に運んでいるようではなさそうだ。 Torvalds氏に早速かんしゃくの矛先を向けられたのは、オーストラリア人プログラマーのDave Chinne
キャッシングの課題と戦略
Amazon で長年にわたってサービスを構築してきた中で、新しいサービスを構築するけれども、このサービスはそのリクエストを満たすためにいくつかのネットワーク呼び出しを行う必要があるというシナリオのさまざまなバージョンを経験してきました。おそらく、この呼び出しは、リレーショナルデータベース、Amazon DynamoDB などの AWS のサービス、または別の内部サービスに対するものです。単純なテストまたは低リクエストレートでは、サービスはうまく機能しますが、問題もあることにも気付きました。問題は、この他のサービスへの呼び出しが遅いこと、または呼び出し量が増えるとデータベースのスケールアウトに費用がかかることです。また、多くのリクエストが同じダウンストリームリソースまたは同じクエリ結果を使用していることに気づいたため、このデータをキャッシュすることが問題の解決策になると考えています。キャッシ
ディレクティブは、,(カンマ)で区切って、複数指定が可能です。 例えば、max-age=3600とmust-revalidateの2つのディレクティブを指定するときは、以下のように書きます。(ディレクティブの個々の意味は、後ほど説明するので、まだ解らなくて大丈夫です。) ただし、複数指定する場合は、矛盾しないように指定する必要があります。(矛盾する組み合わせの動作は未定義なので) そして、互換性のため、ブラウザやプロキシが未対応のディレクティブは、無視する決まりがあります。この動作のおかげで、古いブラウザは新しいディレクティブを無視できるので、ブラウザがおかしくなることは防げます。 RFCやMDNにも、この説明の例として、互換性のため、類似効果のディレクティブを並記する例が書かれていたりします。 ですが、この方法で、古いシステムとの互換性を考え出すとどんどん複雑になります。 現実的に考えて
先日とらのあなラボ様の勉強会に参加していたところ「強いキャッシュ」「弱いキャッシュ」とキーワードが出てきました。 初めて聞く表現だったので質問したところやはり知らない定義だったため、少し調べてまとめてみたものです。 なお、強いキャッシュ・弱いキャッシュという説明を否定するものではなく、補完したいと考えています。 強いキャッシュ・弱いキャッシュの定義 ネット上を調べると日本語・中国語・英語で説明が出てきますが、調べた限りでは強いキャッシュ・弱いキャッシュの初出はWebフロントエンド ハイパフォーマンスで、定義は以下の通りです。 ExpiresヘッダーとCache-Controlヘッダーでは強いキャッシュを設定できます。 ETagヘッダーとLast-Modifiedヘッダーでは弱いキャッシュを設定できます。 Webフロントエンド ハイパフォーマンス p124 こちらの文書の前後に詳しい定義があ
サイバーエージェントグループ横断でGoに関する知見を共有し合う社内勉強会「CA.go」。今回はその社外版として、「FIFA ワールドカップ カタール 2022」を全64試合無料生中継をした新しい未来のテレビ「ABEMA（アベマ）」のチームがGo活用事例を紹介しました。ここで登壇したのは、江頭宏亮氏。「ABEMA」のレコメンドに対する大規模アクセスを支えるGo製サーバー開発について発表しました。全2回。後半は、「Yatagarasu」に対するリクエストの具体例の説明と視聴者からの質問に答えました。前回はこちら。 Yatagarasuに対するリクエストの具体例を説明 江頭宏亮氏（以下、江頭）：次に、オリジンのYatagarasuへのリクエストを具体的にどのようにやっているのか、説明したいと思います。 先ほど見せたスクリーンショットだと、右側にモジュールが3つ並んでいたと思いますが、実際は縦スク
x86上のLinuxとFreeBSDにおいて、メモリキャッシュを無効にするカーネルモジュールを書いた話 - alphakai’s tech blog
どうも、前回の記事が思っていたよりも反響があり、Blogを書くモチベーションが高まり、また記事を書くことにします。 ↑とか書いたんですが、このへんまで書いて50日くらい記事を書くのを放置していたので、ちゃっちゃと書き上げることにします。 今回はx86なCPUに存在するControl Registerのうち、CR0に存在するCache Disableフラグを操作するカーネルモジュールをLinux、FreeBSDのそれぞれ向けに作ったのでそれについて記述します。 それでは、続きからどうぞ。 はじめに、作成したカーネルモジュールのリポジトリへのリンクを掲載します。 Linux版のカーネルモジュール(procfsとして実装) cr0cd FreeBSD版のカーネルモジュール(キャラクタデバイスとして実装)cr0cd_fbsd そもそもこれはなに 一言で言うと、メモリのキャッシュ(L1, L2, L
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
キャッシュを活用するために必要な知識と勘所 - そーだいなるらくがき帳
キャッシュと向き合う、キャッシュと共に生きる / cache pattern
再考: アプリ開発と状態遷移の管理 - ninjinkun's diary
HTTPキャッシュに学ぶ、無理のないドキュメント更新運用
Raspberry Piで学ぶコンピュータアーキテクチャ
【悲報】 AMD RyzenのL3 Cacheの大半を見失った件 【Windows11】
Next.jsアプリをVercelからGoogle Cloudに移行した話
「賽銭用コイン」キャッシュレスで販売 お寺のアイデアに反響...「批判は覚悟」住職明かす実施背景
Fastlyについて知らないかもしれない30のこと – TravelBook Tech Blog
Web配信の技術という本を書きました – cat /dev/random > /dev/null &
「キャッシュは麻薬」という標語からの脱却 - id:onk のはてなブログ
キャッシュアルゴリズムの比較 - falsandtruのメモ帳
[翻訳]ShopifyにおけるRuby on Railsで速いコードを書く方法
Binary search with modern processors
キャッシュレス先進国アメリカで、「現金」が若者のトレンドに...大人たちからは「電子マネーを使え」の声
本人認証サービス（3Dセキュア）に対応しました - Kyash お知らせ
Google、検索結果からキャッシュへのリンクを削除 「cache:」も近い将来廃止へ
CPUキャッシュがGoのコードに与える影響（翻訳）｜TechRacho by BPS株式会社
すかいらーくグループで店員さんを呼ばずに済むテーブル決済が増えていて便利「キャッシュレス決済の正しい使い方」
Kubernetesのキャッシュネームサーバとリゾルバ | IIJ Engineers Blog
モダンWebにおけるキャッシングのための新HTTP標準 | POSTD
Relayに学ぶGraphQLのスキーマ設計 - cockscomblog?
アニメ制作の現場でNASのSSDキャッシュが活躍、実際の効果をライデンフィルムに聞いてみた QNAP＋Samsung SSDで遅延を最小に、最大200名のスタッフを支えるプロの制作環境とは text by 日沼諭史
続・HTTPキャッシュを使いこなして、Webアプリを快適に(1) | IIJ Engineers Blog
強いキャッシュ 弱いキャッシュとはなにか – cat /dev/random > /dev/null &
「多層キャッシュサーバー」を2人×2日で爆速開発 インフラリソースを10分の1にした、Go製サーバー開発の裏側