User-space Network Processing
This document discusses optimizations for TCP/IP networking performance on multicore systems. It describes several inefficiencies in the Linux kernel TCP/IP stack related to shared resources between cores, broken data locality, and per-packet processing overhead. It then introduces mTCP, a user-level TCP/IP stack that addresses these issues through a thread model with pairwise threading, batch pac
Redis作者自身によるRedisとMemcachedの比較 | Yakst
Redisの作者antirez氏自らによる、memcachedとRedisの長所短所の比較。特に、Redisを単なるキャッシュ用アプリケーションとしてmemcachedと比較することの間違いと、それぞれの向いている使用方法についての私見。 あなたが私と面識があるなら、私が競合製品があることが悪いと考える人間でないことはご存知でしょう。ユーザーに選択肢があることは本当にいいことだと思っていますし、だからこそ他の技術とRedisを比較するようなことはほとんどしませんでした。 しかし、最適なソリューションを選ぶためには、ユーザーは正しく情報を持たねばならないのも確かです。 この記事を書くのは、有名なライブラリであるSidekiqの作者として知られるMike Perhamが、Redisのバックエンドストレージとしての使い方を書いた記事を読んだのがきっかけです。従って、私はMikeがRedisに「反
Nginx Wordpress + WP-FFPC Plugin + ngx_pagespeed - CentminMod.com LEMP Nginx web stack for CentOS, AlmaLinux, Rocky Linux
Nginx WordPress + WP-FFPC Plugin Setup + ngx_pagespeed Discuss Wordpress and Centmin Mod Nginx on the forums here. The Centmin Mod outlined WordPress fastcgi caching guide might not be everyone's cup of tea. So I'll out line an alternative WordPress caching method via WordPress plugin called, WP-FFPC (Fast Full Page Cache) which utilises Memcached server (via PHP memcache or PHP memcached) or via
複数のWebサーバでSSLセッションキャッシュを共有してSSL処理を高速化(Apache + mod_ssl + mod_socache_memcache) - 元RX-7乗りの適当な日々
HTTPS(SSL利用)サイトがSEO的に優遇されるトレンドで、世間的にもHTTPS接続でサイト運用するサービスが増えてきています。 これが、ハイトラフィックサイトになってくると、このフロントエンドでSSL処理させることが負荷的にもなかなか辛いのです。 で、Apache 2.3以降では、Shared Object Cache Providerとして、memcachedが選択できるようになっています。 この仕組みを利用して、Apacheとmemcachedを並べることで、各サーバでユーザのSSL Session Cacheを共有しながらHTTPSリクエストを負荷分散できる構成を作ってみました。 WebサーバでSSLオフロード 常時SSLを利用したWebサイトを運用するために、SSLアクセラレータといったアプライアンス製品だとか、ソフトウェアだとApacheやNginxのSSLモジュールを使う
ElastiCacheとELBとtwemproxy - まめ畑
redis / memcachedをスケールする方法として、アプリケーションで分散アルゴリズムを実装する方法や、ライブラリを使う方法などありますが、 Twitterが作っているtwemproxy(https://github.com/twitter/twemproxy)というものがあります。 これは、redis / memachedの前段に置くことでキャッシュクラスタを構成することが出来ます。様々な分散アルゴリズムや、故障ノードの切り離しなどの機能もあり、 キャッシュノードが不具合で接続できなくなったとしても自動でサービスアウトしてくれます。 開発も盛んに進んでいて、今、ノード追加時にプロセスの再起動が必要ですが、gracefulの実装も見えて来ました。 詳しくは以前書いたこちらの記事を参照して下さい。http://d.conma.me/entry/20121227/1356596553
Introducing mcrouter: A memcached protocol router for scaling memcached deployments
Introducing mcrouter: A memcached protocol router for scaling memcached deployments Most web-based services begin as a collection of front-end application servers paired with databases used to manage data storage. As they grow, the databases are augmented with caches to store frequently-read pieces of data and improve site performance. Often, the ability to quickly access data moves from being an
キー一覧を見るためにmemcached入門 - tumblr
memcachedを使う場合、多くはアプリケーションの言語ごとにあるクライアントを使ってgetとかsetをすると思う。telnetで直接memcachedプロトコル使うのはキーの一覧が見たいとかデバッグ時くらいだと思う。そのデバッグ時も言語ごとのrepl使うほうが早かったりするけど。 まぁそんなわけでmemcachedをtelnetから叩くことは殆どないのではないかと思う。自分が単純に経験不足なのも在るだろうけど。で、この間直接覗きたい機会があったのでどういうkeyが入ってるのか調べるためにキー一覧を見ようとしてみたのだけど見方が全くわからない。『memcached key 一覧』でググって一番最初に出てきたこのページを参考にしてstats itemsコマンドを打ってみたけど何が何だか... > set hoge 0 0 4 > hage STORED > stats items STAT
AWSでマルチAZなセッション管理DBを構築する5つのプラクティス | DevelopersIO
はじめに セッション管理が必要なWebアプリケーションサーバをロードバランシングやクラスタリングなどで負荷分散構成とした場合、セッション情報をデータベースに保持し共有化する方法が一般的です。しかしAWSのインフラストラクチャ障害などでAZが丸ごとダウンするようなケースを考慮した場合、Webアプリケーションサーバと共に、セッション管理DBも複数のAZに分散配置するのが望ましいでしょう。 ではAWSでセッション管理DBを複数のAZに分散配置する場合、どのような手段が考えられるのでしょうか。というのが今回のスタート地点です。 1.AZ分散配置しない いきなり前提を覆すような話をしますが、そもそもAZ分散配置が必要なケースは、AZが丸ごとダウンしセッション管理DBが使えなくなることがサービス停止に直結する場合です。 つまりアプリケーションが「セッション管理DBに接続出来ない場合はローカルのDBやフ
たけまる / Kai - Amazon's Dynamo communicating with memcache protocol
_ Kai - Amazon's Dynamo communicating with memcache protocol [kai][dynamo][erlang] だいぶ前 [2008-02-25-1] に，Perl (POE) で Amazon Dynamo っぽいもの を作りかけて放置していました． Erlang で書き直して，それなりに動くことを確認したので公開します．名 前は Kai といいます．今回は，memcache プロトコルでデータをやり取り できるようにしました． Dynamo とは，Amazon で使われているスケーラブルなハッシュテーブルで す．詳しくは [2008-01-31-1] に書きましたが，次のような特徴を持って おり，Amazon の巨大なサービスを支えています． - 簡単にスケールアウトできる - 障害に強い (マシン障害どころかラック障害にも耐える)
第2回 memcachedのメモリストレージを理解する | gihyo.jp
株式会社ミクシィ 研究開発グループの前坂です。前回の記事でmemcachedは分散に長けた高速なキャッシュサーバであることが紹介されました。今回はmemcachedの内部構造がどう実装されているのか、そしてメモリがどう管理されているのかをご紹介します。また、memcachedの内部構造の事情による弱点も紹介します。 メモリを整理して再利用するSlab Allocationメカニズム 昨今のmemcachedはデフォルトでSlab Allocatorというメカニズムを使ってメモリの確保・管理を行っています。このメカニズムが登場する以前のメモリ確保の戦略は、単純にすべてのレコードに対してmallocとfreeを行うといったものでした。しがしながら、このアプローチではメモリにフラグメンテーション（断片化）を発生させてしまい、OSのメモリマネージャに負荷をかけ、最悪の場合だとmemcachedのプ
Repcached
repcachedについて repcachedとは、memcachedにデータのレプリケーション機能を追加実装したものです。 memcachedは、以下のようなところによく使われると思います。 一時的なデータの保存場所として キャッシュを保存する場所として RDBMSのデータのキャッシュ 生成したページデータのキャッシュ いずれの場合も消えていいデータなので、万が一memcachedがダウンしても問題はないはずです。 しかし、影響が全くないわけではありません。 例えば、MySQLのデータをmemcachedでキャッシュしている場合、memcachedがダウンしている間は直接MySQLにアクセスがいくことになりDBサーバの負荷が上がります。また、memcachedを再起動してキャッシュが失われた場合は、再びキャッシュが溜まるまではDBサーバに負荷がかかることになってしまいます。 このように
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Webアプリケーションは難しい
Google Code Archive - Long-term storage for Google Code Project Hosting.
GitHub - cubicdaiya/neoagent: A Yet Another Memcached Protocol Proxy Server
Twemproxy - MemCachedとRedis用のプロキシ
GitHub - twitter/twemproxy: A fast, light-weight proxy for memcached and redis