Apple Edge CacheFast. Faster. Fastest.Apple Edge Cache (AEC) is equipment supplied and managed by Apple for deployment within ISP partner networks to deliver Apple content directly to customers.
ben-manes/caffeine · GitHub - A high performance caching library for Java 8
Caffeine provides flexible construction to create a cache with a combination of the following optional features: automatic loading of entries into the cache, optionally asynchronously size-based eviction when a maximum is exceeded based on frequency and recency time-based expiration of entries, measured since last access or last write asynchronously refresh when the first stale request for an entr
Cache-Controlヘッダのstale-while-revalidateとは - ASnoKaze blog
20170215追記「Nginxがstale-while-revalidateに対応した」 http://d.hatena.ne.jp/ASnoKaze/20170211/1486820792 Chromeの「chrome://flags/」に「stale-while-revalidate キャッシュ指令を有効にする」と言うフラグがあったので、簡単に調べた。 「RFC5861 HTTP Cache-Control Extensions for Stale Content」で定義されており、HTTPにおけるキャッシュ制御の拡張として「stale-while-revalidate」と「stale-if-error」が定義されている。 stale-while-revalidate stale-while-revalidateはCache-Controlヘッダに付加される。Cache-Contro
Redis作者自身によるRedisとMemcachedの比較 | Yakst
Redisの作者antirez氏自らによる、memcachedとRedisの長所短所の比較。特に、Redisを単なるキャッシュ用アプリケーションとしてmemcachedと比較することの間違いと、それぞれの向いている使用方法についての私見。 あなたが私と面識があるなら、私が競合製品があることが悪いと考える人間でないことはご存知でしょう。ユーザーに選択肢があることは本当にいいことだと思っていますし、だからこそ他の技術とRedisを比較するようなことはほとんどしませんでした。 しかし、最適なソリューションを選ぶためには、ユーザーは正しく情報を持たねばならないのも確かです。 この記事を書くのは、有名なライブラリであるSidekiqの作者として知られるMike Perhamが、Redisのバックエンドストレージとしての使い方を書いた記事を読んだのがきっかけです。従って、私はMikeがRedisに「反
bfcache について覚えて帰ってもらいます。（転載） - oogatta のブログ
動作サンプル消しちゃったの直しました。 以下の内容は、『 mixi Engineers' JavaScript Advent Calendar 2012 』の12月19日分として投稿したものの転載です。内容に差異はありません。 bfcache について覚えて帰ってもらいます。 こんばんは。日々、一体お兄ちゃんだけど愛さえあれば関係ないのかどうなのか、そこのところについて確認作業を怠らないものです。 今日、偶然にもこれを閲覧してしまったみなさまには、近代ブラウザの誇る謎機能、 bfcache について覚えて帰っていただきます。どうぞよろしくお願いいたします。 bfcache （正式名称なのか、別名なのか定かではありませんが Back-Forwad Cache とも呼ばれます）をおもむろに Google さんに検索いただくと、権限のありそうな回答は Using Firefox 1.5 cach
Implementing the Service Worker Cache API in Gecko
For the last few months I’ve been heads down, implementing the Service Worker Cache API in gecko. All the work to this point has been done on a project branch, but the code is finally reaching a point where it can land in mozilla-central. Before this can happen, of course, it needs to be peer reviewed. Unfortunately this patch is going to be large and complex. To ease the pain for the reviewer I t
Spring 3.1 の Cache Abstraction（キャッシュの抽象化） - 都元ダイスケ IT-PRESS
しばらくコード付きのエントリ書いてないなぁ、と思ったので。Springの新機能についてひとつ。 Spring3.1は、まだリリース版は出ていないのだけど、RC1が出ている。（参考 Spring 3.1 RC1リリース） その新機能にCache Abstraction（キャッシュの抽象化）ってのがあって、色々調べてみた。例えばWebAPIなんかを叩いて情報を取ってくるようなメソッドは、情報があまり変化しないものであればキャッシュしちゃえばいいよね。例えば Amazon API で、ASINから商品名やら何やかんやを取ってくるメソッドとか。 下準備 package jp.xet.sample; public interface EntityRepository { String get(int id); void put(int id, String value); } 例えばこんな（↑）イン
Java でオンメモリキャッシュを実装するときにスレッドについて気をつけるべきこと - Qiita
Java では常にスレッドについて意識する必要がある｡ Map にキャッシュデータを入れたい場合､HashMap を使ってはいけない｡HashMap はスレッドセーフではないからだ｡ synchronized で保護してもいいが､いちいちするのも面倒だし､問題が起きがちなんで､ のように､Collections.synchronizedMap() でよしなにする方法がある｡この方法でラップすると､メソッドアクセスの際に synchronized がかかるので安全になる｡ ConcurrentHashMap と HashMap HashMap をマルチスレッドからアクセスする場合､get メソッドを使った場合でも synchronized をかけざるをえず､パフォーマンスが出ない｡ ConcurrentHashMap ならば､取得時にはロックがかからないので､キャッシュには Concurre
そんなリザルトキャッシュで大丈夫か? #jjug
This document discusses Yarn and its advantages over npm. It notes that Yarn uses yarn.lock files instead of npm-shrinkwrap.json files to lock down dependency versions. Yarn is also described as being faster, able to work offline by caching dependencies, and potentially more secure than npm with features like flat mode and module folders. The document suggests Yarn may handle dependencies and devD
negative dentry と tmpfs で negative dentry がキャッシュされない理由について調べた - hibomaの日記
kazeburo さんの 一時ファイルとdentry cacheとメモリ を読んでからしばらくファイルシステム周りを調べていたのでした。 先のエントリで /tmp のファイル作成/削除を繰り返して dentry キャッシュ がもりもり溜まっていくのは negative dentry であることが理解できました。 negative dentry とは negative dentry とは 存在しない inode に対応する dentry です。 dentry キャッシュの役割は RAM より低速な HDD や SSD などの二次記憶装置からのディレクトリエントリの読み取りをメモリにキャッシュしておき高速化するためですが、negative dentry をキャッシュすることで存在しないディレクトリエントリの読み取りもキャッシュされます。 「存在しないのにキャッシュ？」がしばらくイミフだったので
Stack Overflowのアーキテクチャ - ワザノバ | wazanova
http://www.youtube.com/watch?v=OGi8FT2j8hE1 comment | 0 pointsドイツのハンブルグで開催されたDeveloper Conference 2013で、Stack Overflowのアーキテクチャが紹介されてます。 Stack Overflowのネットワークは、110 Q&Aサイト、430万ユーザ、質問760万件、回答1360万件、月間5億6千万ページビュー サーバ25台: ウェブサーバ11台（内9台でほぼトラフィックさばく）、ロードバランサ1台 (+ 予備1台)、DBノード4台、アプリサーバ3台、検索サーバ3台（Elasticsearch）、Redisサーバ２台（キャッシュ、メッセージング） 毎秒質問が投稿されているので、トップページには都度最新の質問を掲載するように更新はできないが、ユーザの回答パターン、質問閲覧パターン、好みのタ
モバイル対応Webアプリケーションのキャッシュ戦略
近年、モバイルブラウザ上でアプリケーションを作るにあたり、JavaScriptでも不安定な回線上で動作する設計が求められるようになってきました。 ここでは、「オフラインファースト」をはじめとする、モバイルなどの回線が不安定な状況を想定したWebアプリケーション設計に関して、キャッシュ方法やよく使われるAPIなどを紹介したいと思います。 「オフラインファースト」とは2012年ごろから提唱されていた、「回線がオフラインになることを前提にアプリケーションの設計を行う思想」のことで、オフライン前提に設計することにより回線状況によらないサービス提供や、効率的な通信をベースにした高速な動作を目指すものです。 それではここからはキャッシュ方法とそれぞれ向いているコンテンツの紹介を行います。 読み込みデータのキャッシュ ApplicationCacheやlocalStorage、オンメモリキャッシュなどを
Webアプリにおけるキャッシュ。オレオレ事例 - ゆーすけべー日記
Webアプリにおいて、アクセスやデータ量が多く/大きくなってくると、 バックエンドのパフォーマンスが低下しがちです。 MySQLなどのRDBMSにデータを置いている場合は適切に クエリーを改善する、インデックスを張る、といった策で解決する場合もありますが、 キャッシュを効果的に利用することでより高負荷に対応できる可能性があります。 また、外部APIへの問い合わせなど、どうしてもネットワークや他のリソースのレスポンスタイムに 引きずられる部分に関しては情報を手元にキャッシュしておくと何かとよいでしょう。 今回はWebアプリケーションのレイヤーで最近僕がどのようにキャッシュを使っているのか？ の事例を紹介しつつまとめてみたいと思います。 キャッシュについてとその基本 そもそもキャッシュとは、簡単にふわっと表現するならば、 「一時的に情報を手元の近い場所に置いておいて利用する手法、もしくはその一
Linuxのメモリ上のキャッシュを解放する - 元RX-7乗りの適当な日々
いつも思いだすのに時間がかかるというか、ググるのでメモ。 例えば、ベンチマークとかをとっていて、残ったキャッシュを奇麗さっぱりに消したい時とかに使う。 Linuxのメモリで保持しているキャッシュをクリアするには、以下を実行する。 # sync # echo 3 > /proc/sys/vm/drop_caches 値の意味としては、、、 1： ページキャッシュを解放 2： dentry、inode を解放 3： ページキャッシュ、dentry、inode を解放 以下を参考に。 /proc/sys/vm/drop_caches (Linux 2.6.16 以降) このファイルに書き込みを行うことで、クリーンなキャッシュ、dentry、 inode をメモリ上から外し、そのメモリを解放する。 ページキャッシュを解放するには、 echo 1 > /proc/sys/vm/drop_caches
Infinispan
In-Memory Distributed Database What is Infinispan? Infinispan is an open-source in-memory database that can hold nearly any type of data, from plain-text to structured objects. Retrieve your data with lightning-fast speeds with Infinispan's powerful full-text and vector search capabilities. Guarantee reliability and integrity by distributing your data across elastically scalable Infinispan cluster
OSCacheのキャッシングでWebアプリケーションのパフォーマンスを向上する
はじめに 多数のクライアントからのリクエストを処理しなければならないWEBシステムでは、パフォーマンスの問題が出てくることが珍しくありません。 パフォーマンスの問題を解決する技術の一つとして「キャッシング」技術があります。これは動的コンテンツの生成結果をメモリにキャッシュ（一定期間保存）し、その間に受けたリクエストに対してはキャッシュの値を返すことにより、生成の処理数を減らすことができるというものです。また静的コンテンツでも、PDFや画像ファイルなど比較的大きいファイルをHDDではなくメモリにキャッシュすることにより、ファイルロードを高速化することができます。 他のパフォーマンスの問題解決方法と比べて大きなメリットは、ビジネスロジックの修正を最小限に抑えることができ、デグレーションを防ぐことができるところです。ただし、キャッシュされている間は古い情報がレスポンスとして渡されることになり、常
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google Code Archive - Long-term storage for Google Code Project Hosting.
IBM Developer
InfoQ: Infinispanインタビュー
http://www.opensymphony.com/oscache/