Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

タグ

cacheに関するkiririmodeのブックマーク (20)

  • https://openai.com/index/api-prompt-caching/

    kiririmode
    kiririmode 2024/10/03
    1024 トークン以上のプロンプトの接頭語となったものが自動的にキャッシュされる。5-10分程度で消える。
  • AWS AppSync が、サーバー側のデータキャッシングのキャッシュエントリ削除のサポートを開始

    AWS AppSync はマネージド GraphQL サービスです。このサービスを使用すると、1 つ以上のデータソースからのデータに安全にアクセス、操作、結合するための柔軟な API を作成でき、アプリケーション開発がシンプルになります。日、AppSync は、AppSync の組み込みサーバー側キャッシュからの特定のエントリの削除をサポートするようになりました。 AppSync のサーバー側キャッシュ機能は、デベロッパーが高速のメモリ内マネージドキャッシュからデータを保存および取得することを可能にすることにより、レイテンシーの影響を受けやすい高スループットのアプリケーションのパフォーマンスを改善するのに役立てることができます。今日まで、お客様は、キャッシュ全体をフラッシュすることでキャッシュエントリを無効にすることはできましたが、特定のエントリを無効にすることはできませんでした。今後、

    AWS AppSync が、サーバー側のデータキャッシングのキャッシュエントリ削除のサポートを開始
    kiririmode
    kiririmode 2022/06/17
    evictionはVTL経由のみっぽい
  • AWS AppSyncキャッシングとAmazon DynamoDBトランザクションのサポートによりGraphQL APIのパフォーマンスと一貫性が更に向上します | Amazon Web Services

    Amazon Web Services ブログ AWS AppSyncキャッシングとAmazon DynamoDBトランザクションのサポートによりGraphQL APIのパフォーマンスと一貫性が更に向上します AWS AppSyncはGraphQLのマネージドサービスで、単一または複数のデータソースのデータに安全にアクセスしたり、操作したり、結合するための柔軟なAPIを作成でき、アプリケーション開発をシンプルにすることができます。多くの場合、異なったデータソースは異なったユースケースに合わせて最適化され、データが配信されるスピードも異なっていることでしょう。その基になるGraphQLスキーマで定義されているデータフィールドもかなり多様です。 たとえば、eコマースアプリケーションでは、在庫量を表すデータフィールドは頻繁に更新されますが、顧客プロフィールの更新は時々です。トランザクションIDに

    AWS AppSyncキャッシングとAmazon DynamoDBトランザクションのサポートによりGraphQL APIのパフォーマンスと一貫性が更に向上します | Amazon Web Services
    kiririmode
    kiririmode 2022/06/17
    AppSyncのcacheはredisがついてくるイメージ。eviction はマッピングテンプレートからでないと操作できないかも
  • ホンネテレビの負荷対策-配信編 - Qiita

    この記事は、AbemaTV Advent Calendar 2017 の25日目の記事です。 今年、サイバーエージェントに新卒入社し、AbemaTVの配信チームに所属している @miyukki です。 このアドベントカレンダーも最終日になりました。11月末まで誰もやる気配がなかったのですが、社内で声を上げて広めた結果、多くの人が書いてくれてありがたいです。なんでも気軽に自由に発言できるのもこの職場の良いところです。 72時間ホンネテレビ さて題に戻り、AbemaTVでは11月2日-5日にかけて、稲垣・草彅・香取 3人でインターネットはじめます『72時間ホンネテレビ』(以下、ホンネテレビ)を放送しました。 言い出しづらいのですが、過去には「亀田興毅に勝ったら1000万円」AbemaTV史上最多アクセスでサーバダウンと記事になるなど、急激なアクセス増加でサービスを提供できなかった例がありまし

    ホンネテレビの負荷対策-配信編 - Qiita
  • はてなブログのキャッシュ周りをきちんと改善したら、アプリケーションサーバの台数を半分にできた話 - Hatena Developer Blog

    はてなブログでSREをやっているid:cohalzです。 2019年12月頃からid:utgwkkやid:onkとともに、はてなブログにおけるキャッシュ周りの改善を行いました。その結果、次のような成果が得られました。 ブログ記事のキャッシュヒット率が、1日平均で8%から58%に向上 アプリケーションサーバの台数を、以前の半数以下に削減 DBに届くリクエスト数が、以前の3分の2まで減少 レスポンスタイムの平均が、以前の8割まで減少 この記事では、実際にどういった改善を行ったのか、その際に気をつけたことや大変だったことを紹介します。 はてなブログがVarnishを導入した経緯と課題 開発合宿をきっかけに問題が明らかになる 進め方をまず考える ホストのメモリをできるだけたくさん利用する メモリを積んだホストでなぜかレイテンシが悪化 キャッシュが分散しないようVaryヘッダを使う デバイス情報を適

    はてなブログのキャッシュ周りをきちんと改善したら、アプリケーションサーバの台数を半分にできた話 - Hatena Developer Blog
    kiririmode
    kiririmode 2020/09/20
    nginx-varnishの構成。varyヘッダをuaに対して適用していたがそれをpc/mobileの2つに集約
  • Request.destinationでリソースの種類別にキャッシュ戦略 | フロントエンドBlog | ミツエーリンクス

    Request.destinationはRequestインターフェイスのプロパティで、リクエストしているコンテンツの種類を文字列で返します。これをService Workerのfetchイベント時に用いると、リソースの種類別にキャッシュ戦略を切り替えることができます。 Request.destinationの使い方 Request.destinationでは一体どんな文字列が返されるのでしょうか。Fetch StandardのRequest.destinationの仕様の一部を抜粋します。 A request has an associated destination, which is the empty string, "audio", "audioworklet", "document", "embed", "font", "image", "manifest", "object",

    Request.destinationでリソースの種類別にキャッシュ戦略 | フロントエンドBlog | ミツエーリンクス
  • Webアプリケーションにおける正しいキャッシュ戦略 - Sansan Tech Blog

    こんにちは。プロダクト開発部のサーバサイドエンジニアの荒川です。普段はSansanのスマホアプリのAPIの開発をしています。 今回扱うテーマは皆さん大好きキャッシュ(Cache) です。 Webアプリケーションを開発するエンジニアである以上、キャッシュの存在からは逃れられないでしょう。 例えばパフォーマンスを向上させる手段として、キャッシュを仕込むことは往々にしてあるかと思います。 キャッシュを使えばパフォーマンスが向上しそう、というイメージも強いため安易に選択する戦略になりがちですが、正しく扱うことは質的に難しいです。 しかしキャッシュを上手に使えば、ユーザ体験を圧倒的に向上させることができます。 そんな諸刃の剣キャッシュ💰について考慮するべきこと、その戦略を改めてまとめてみました。 今回の対象 今回の対象は、アプリケーションレベルでのキャッシュ戦略を取り扱います。 いわゆるキャッシ

    Webアプリケーションにおける正しいキャッシュ戦略 - Sansan Tech Blog
  • Improving HTML Time to First Byte

    The Time to First Byte (TTFB) of a site is the time from when the user starts navigating until the HTML for the page they requested starts to arrive. A slow TTFB has been the bane of my existence for more than the ten years I have been running WebPageTest. Looking at a recent test data set (~100k pages): 20% TTFB > 3s80% start render > 5s (10% > 10s)500 pages were > 15MB So much slow to fix — Patr

    Improving HTML Time to First Byte
    kiririmode
    kiririmode 2019/01/03
    http headerを使ってedgeにキャッシュやパージを指示できる仕組み。変にapiを呼び出すよりは確かに便利な面はあるけど、運用上すべてこれにするのは柔軟性に欠けるかも(そしてそれを狙ってはいないような気がする)
  • Goで多層キャッシュを実装するときに役立つtips - Gunosy Tech Blog

    こんにちは、メディア事業部所属の石塚(@ij_spitz)です。こちらはGunosy Advent Calendar 2018、4日目の記事です。なお、昨日の記事は@timakinさんのGoで多層キャッシュ実装と@aibouさんのInfrastructure as Codeの心構えでした。 何を書くか全然決めてなかったのですが、昨日@timakinさんがGoでの多層キャッシュの実装ポイントについて書いていたことに加えて、僕も最近業務で多層キャッシュについて取り組んでいたので、Goで多層キャッシュを実装するときに役立つtipsについて書きたいと思います。 ちなみに僕は多層キャッシュのことを多段キャッシュと呼んでいましたが、曖昧さを解消するために記事では多層キャッシュで統一します。 なぜ多層キャッシュを使うのか 多層キャッシュ自体については昨日のブログで既に説明されているので詳細は控えます

    Goで多層キャッシュを実装するときに役立つtips - Gunosy Tech Blog
    kiririmode
    kiririmode 2018/12/06
    goでの多段キャッシュ。singleflight良さそう
  • Spring MVC(+Spring Boot)上での静的リソースへのアクセスを理解する - Qiita

    今回は、Spring MVC上で静的リソース(HTMLJavaScriptCSS、画像など)にアクセスする方法について説明します。ここでは、「Jakarta EE(Java EE)のアプリケーションサーバーの機能を使用してアクセスする方法」と「Spring MVCの独自機能を使用してアクセスする方法」について説明します。また、最後にSpring Bootアプリでアクセスする方法についても紹介します。 動作検証バージョン Spring Framework 5.3.6 (4.2.5.RELEASE) Spring Boot 2.4.5 (1.3.3.RELEASE) Tomcat 9.0.45 Note: [2021/5/5] 投稿から5年くらいたっても一定のViewが継続してあるので、最新のSpring(Spring Boot)バージョンの内容に更新しました。今回の更新では、web.xm

    Spring MVC(+Spring Boot)上での静的リソースへのアクセスを理解する - Qiita
  • CSSファイルやJavaScriptファイルを読み込むときの末尾にあるクエリー文字列は何のためにあるか

    あちこちのウェブサイトのHTMLソースを見ると、CSSファイルやJSファイルを読み込むlink要素やscript要素のファイル名の末尾に「?xxx=123」のような、いわゆるクエリーがついているのを頻繁にみかけます。 例えばWordPressでjqueryを読み込んだときなど、 <script src="http://user-domian/wp-includes/js/jquery/jquery.js?ver=1.6.1"></script> と、jQueryのバージョン番号を示すクエリー文字列がついています。CSSファイルやJavaScriptファイルはCGIではないので、このクエリーを解釈して使っている訳ではありません。 知っている人は「な~んだ」って感じだと思いますが、この「?ver=1.6.1」の役割について紹介します。 1.キャッシュを制御する ページ読み込みと同時に読み込まれ

    CSSファイルやJavaScriptファイルを読み込むときの末尾にあるクエリー文字列は何のためにあるか
  • Best practices for using the Vary header

    As shown above, the browser sends a lot of information along with the URL. The Accept header tells you what sort of content the browser prefers, User-Agent specifies which version of what browser it is, Accept-Language contains a list of languages (and dialects) that the user has configured, and Accept-Encoding shows which compression schemes the browser supports. For practical purposes, we only c

    Best practices for using the Vary header
  • HTTP caching - HTTP | MDN

    HTTP Guides An overview of HTTP A typical HTTP session HTTP Messages MIME types (IANA media types) Compression in HTTP HTTP caching HTTP authentication Using HTTP cookies Redirections in HTTP HTTP conditional requests HTTP range requests Content negotiation Connection management in HTTP/1.x Evolution of HTTP Protocol upgrade mechanism Proxy servers and tunneling HTTP Client hints Security and priv

    HTTP caching - HTTP | MDN
  • Apache 2.2でWebサイトをパフォーマンスアップ!(2/3) - @IT

    Apache 2.2でWebサイトをパフォーマンスアップ! - 最新Apacheの機能と設定方法教えます - 鶴長 鎮一(book@tsurunaga.jp) 2006/3/14 強化されたドキュメントキャッシュ機能を使う ドキュメントキャッシュ機能を導入すると、Apacheの応答性を向上させることができます。 従来のApache 2.0でも、mod_file_cacheモジュールを使用することで通常コンテンツのレスポンスを向上させることができました。ただし、mod_file_cacheの仕組みはApacheの起動時にファイルをメモリに読み込ませるというもので、コンテンツに変更があった場合は再起動が必要になるなど、動的なキャッシングには対応していませんでした。 Apache 2.2では、RFC 2616に準拠したHTTPコンテンツキャッシュが可能になりました。Cache-Controlヘッ

  • Facebookが大規模スケーラビリティへの挑戦で学んだこと(前編)~800億枚の写真データとPHPのスケーラビリティ問題

    Facebookが大規模スケーラビリティへの挑戦で学んだこと(前編)~800億枚の写真データとPHPのスケーラビリティ問題 全世界で3億人を超える会員を抱え、世界最大のSNSとなったFacebook。同社の巨大なシステムは、3つのデータセンターにある約3万台のサーバと、PHPC++、Memcache、MySQLなどのソフトウェア群によって支えられています(同社のデータセンターの巨大さは、記事「3億のユーザーを抱えるFacebookのデータセンター。移動は自転車、希望は100Gbイーサネット 」を参照)。 同社の技術担当バイスプレジデント Jeff Rothschild氏は、Facebookが実現している大規模なスケーラビリティを、いかにしてこれらのソフトウェアで実現しているのか、10月8日に米カリフォルニア大学サンディエゴ校で行ったセミナー「High Performance at Mas

    Facebookが大規模スケーラビリティへの挑戦で学んだこと(前編)~800億枚の写真データとPHPのスケーラビリティ問題
  • HTML5のapplication cacheがつかえない件 - (ひ)メモ

    ちょっと思い違いをしていたのでメモっておきます。 HTML5にはオフラインでも参照できるapplication cacheという機構があります。 HTML5 Rocks - A Beginner's Guide to Using the Application Cache 6.6 Offline Web applications ― HTML Standard 「ローカルキャッシュなんで速いし!サーバーの負荷も減るし!!」と思ってちょっと試してみたんですが、これ、動的なページが基Webサービスには役に立ちません。 application cacheは、HTMLに <!DOCTYPE html> <html manifest="/cache.manifest"> <head> ...という風にキャッシュの指示ファイル cache.manifest を指定して、そこでキャッシュするとかしな

    HTML5のapplication cacheがつかえない件 - (ひ)メモ
  • mincore(2)でファイルがページキャッシュに乗っているか調べる - syuu1228's blog

    シェルから調べたい人 Google Code Archive - Long-term storage for Google Code Project Hosting.をインストールして、 fincore ファイル名 って打つ。 自分のプログラムから調べたい人 要するにさっきのfincoreコマンドから必要な所を抜き出してくれば良い。 以下はtest.datのキャッシュ中サイズを表示するプログラム。 #include <stdio.h> #include <stdlib.h> #include <fcntl.h> #include <sys/types.h> #include <sys/stat.h> #include <unistd.h> #include <sys/mman.h> #include <errno.h> long fincore(int fd, size_t length)

    mincore(2)でファイルがページキャッシュに乗っているか調べる - syuu1228's blog
  • memcachedにおけるキャッシュシステムの Thundering Herd 問題への対策案 - blog.nomadscafe.jp

    キャッシュシステムの Thundering Herd 問題とは、 通常、キャッシュに格納されるデータは、それぞれ単一の生存時間をもっています。問題は、頻繁にアクセスされるキャッシュデータがエクスパイアした際に発生します。データがエクスパイヤした瞬間から、並行に走る複数のアプリケーションロジックがミスヒットを検知し、いずれかのプロセスがキャッシュデータを格納するまでの間、同一のリクエストが多数、バックエンドに飛んでしまうのです。 という問題。クエリが重かったりするとそれだけでシステムに致命的な負荷を与えてしまい、キャッシュがあるにも関わらずキャッシュが切れたタイミング全体が停止することも考えられます。memcachedでこの問題に対応するため、次のような手段を考えてみました。 まず、保存時に通常のキャッシュと、それよりも指定した秒数Expiresが短いキャッシュを2つmemcachedに対し

  • Cache::LRU が速い理由 - Articles Advent Calendar 2010 Hacker

    先日、オンメモリなキャッシュモジュール Cache::LRU を書きました。Kazuho's Weblog: Cache::LRU (a handy and fast in-memory cache module in pure-perl) を見ていただければ、Cache::LRU が他のモジュールより速いことは明らかだと思います。速度差の原因としては機能や実装上の差異もあるのですが、設計上の工夫も Cache::LRU が速い理由のひとつです。 LRU (Least Recently Used) アルゴリズムを備えたキャッシュを実装しようと思うと、 エントリルックアップのためのハッシュ アクセス順を表現するためのリスト の2種類を組み合わせる必要があります。リストを表現する手法としては配列を利用するものとリンクリストを利用するものがありますが、Perl だと前者のほうが速い、ということは

    Cache::LRU が速い理由 - Articles Advent Calendar 2010 Hacker
  • Polipo ― a caching web proxy

    Polipo is no longer maintained When it was first written, Polipo was probably the best HTTP proxy available. Since then, the web has changed, and HTTP proxies are no longer useful: most traffic is encrypted, and a web proxy merely acts as a dumb intermediary for encrypted traffic. Polipo will no longer be maintained. Here are some alternatives: if you need your HTTP traffic to originate from a rem

  • 1