並び順

ブックマーク数

期間指定

  • から
  • まで

441 - 480 件 / 4031件

新着順 人気順

redisの検索結果441 - 480 件 / 4031件

  • SSL のパフォーマンスでお嘆きの貴兄に - What I’ve found has never been enough@Hatena

    SSL アクセラレータの価格に胃を痛めている貴兄、それが買えず SSL のためだけにサーバの台数をニョキニョキ増やしている貴兄、そうでなくとも SSL のパフォーマンスでお嘆きの貴兄のために、いろいろまとめてみましたよ。 SSLセッションキャッシュのタイムアウト設定を長くしよう SSL の負荷のほとんどはセッションの生成によるものなので、当然のようにサーバ側の SSL セッションキャッシュを有効にしておられると思いますが、そのタイムアウトの設定がデフォルトのままという方が多いのではないでしょうか。 たとえばApacheでしたら、設定サンプルのまま SSLSessionCache shm:/usr/local/apache/logs/ssl_gcache_data(512000) SSLSessionCacheTimeout 300 としている方が多いのではないでしょうか。 各サーバのデフォ

      SSL のパフォーマンスでお嘆きの貴兄に - What I’ve found has never been enough@Hatena
    • mixi Engineers’ Blog » memcachedの最新動向

      先週アメリカに行ってMySQLカンファレンスやmemcached hackathonに参加してきました。そこで今回はmemcachedコミュニティやhackathonで行われた多くの議論に関してご報告させていただきたいと思います。 前書き ご存知の通りmemcachedはFacebookやWikipediaをはじめとする巨大ウェブサイトのコアテクノロジーの一つとして世界中で使われるまでに到達したソフトウェアです。mixiを支えるテクノロジーの一つでもあります。 hackathonをご存知ない方のために簡単に説明すると、オープンソースプロジェクトのハッカーたちが実際に集まってプロジェクトの開発をしたり仕様の議論や提案などをするイベントの事です(とても楽しいです)。 今回で4回目になるmemcachedのhackathon(議事録)ですが、東京でもやったら面白いんじゃね?的な話を結構まえにした

        mixi Engineers’ Blog » memcachedの最新動向
      • Pairy : チャットデータを Redis から Amazon DynamoDB に全移行した話(1) - Tech Blog

        CTOの椎名アマドです。 今回は、Pairyのチャットデータを全てRedisからAmazon DynamoDBに移行した話をしたいと思います。 我々が 2012年6月に カップル専用アプリ Pairy をリリースした時には、 データベースは MySQL と Redis の両方を利用するところで始めました。 Redis の役割は: 1. MySQLレスポンスのキャッシュ 2. プッシュ通知等のキュー 3. チャットのデータを全保管 サービスローンチ直後はまだ Appサーバー(EC2)1台と、MySQL & Redisを両方走らせてる DBサーバー(EC2)1台で十分だという判断で、しばらくはそんな構成でやってました。(S3などは省略) しかし、いざサービスが成長してくるともちろん MySQL & Redis を1台でまかなうのはキツくなり、MySQL と Redis を別々のEC2インスタン

          Pairy : チャットデータを Redis から Amazon DynamoDB に全移行した話(1) - Tech Blog
        • Redis Streamsを活用したイベントドリブンアーキテクチャの構築事例 - DMM inside

          Dagger Go SDK vs Shell in GitHub Actions ~ モノレポのCIの実装をGoで実装するまでの道のり ~

            Redis Streamsを活用したイベントドリブンアーキテクチャの構築事例 - DMM inside
          • GitHub製Resqueを使用したRubyでのバックグラウンド処理(バッチ処理) - Masatomo Nakano Blog - Web開発を極める

            そこそこの規模のWebシステムになってくるとバックグランド処理(batch処理)は欠かせないものになってくる。メールの送信、データの日次、月次、年次処理、削除(フラグ)データのpurgeやバックアップ、等々いろいろな物が出てくる。 現在はBackgrounDRbを使っているが、いろいろといまいちなので今回Resqueを評価してみた。ちょっと触った段階での第一印象をメモ。 まず、バッチ処理系で評価のポイントになってくる部分はなんだろうかと考えてみると、なんと言っても見通しのよさと異常系の処理だと思う。画面系と違い、バッチ処理は「見えにくい」ところで実行されるので、その二つが特に大事になってくる。「知らないうちに止まっていました」では困るのがバッチ処理。 たとえば、 異常時の処理無視?管理者に通知?リトライ? 復旧処理タスクの削除(問題を修復後)リトライ 状態の監視いくつのJobが残っているか

            • Ruby on Railsのパフォーマンス向上に関する10のtips:

              という記事があった、色々と面白かったので訳してみる。良いとこも悪いとこもあると思うけど参考までにメモとして 元記事:Top 10 Ruby on Rails performance tips Rubyの基本的なコードを見直してみる自分で作ったクラスよりもできるだけ組み込みのクラスライブラリを使うできるだけ正規表現を使用する、文字列処理にコストの高いループは避けるREXMLは遅いのでLibxmlライブラリを使用する (Cで書かれたXMLパーサらしい、環境に依存するのは嫌かもしれない)if文の多用は避ける、例えば||=を使う ( z||="none" で unless(z){ z = "none" })Hashはコストが高いので他のデータ構造を検討してみる (でも使いたいときあるよね?)キャッシュを有効活用する acts_as_cached でModelをキャッシュ化してみる(PDF資料

              • MogileFSに関して日本語で読める情報 - kinneko@転職先募集中の日記

                読みは「モジャイル」かな? まずは、このへんから。 Learning MogileFS http://www.art-code.org/files/shibuya_pm_tt07_mogilefs_with_catalyst.pdf 分散ファイルシステム MogileFS について http://www.sixapart.jp/techtalk/2006/10/dev_mogilefs.html MogileFS のインストールと初期設定 http://www.sixapart.jp/techtalk/2006/10/dev_mogilefs_install.html MogileFS::Client と MogileFS 内部でのファイルノード管理 http://www.sixapart.jp/techtalk/2006/10/mogilefsclient_mogilefs.html N

                  MogileFSに関して日本語で読める情報 - kinneko@転職先募集中の日記
                • 京都収納棚:DBMの率直な壱実装 - mixi engineer blog

                  飲み屋に行くとかなりの確率で荷物を忘れて帰るmikioです。さて、今回はここ2ヶ月ほどで急ピッチで開発した軽量データベースライブラリ「Kyoto Cabinet」について紹介します。 開発の動機 以前から軽量データベースライブラリとしてご好評いただいているTokyo Cabinetですが、DBMとして必要十分な機能と性能を備えていてなかなか良いものだと自負しております。ただ、開発を進める中でいくつか不満な点があったのも事実です。端的に言えば、全てC言語で記述して、標準ライブラリ(とzlib/bzip2)以外の機能は全て自作しているので、最適化がしやすい反面、メンテナンスの難易度が高くなってしまっているというのが不満です。 そこで、多少性能が悪くなってもいいから、私自身としてお気楽に開発およびメンテナンスができて、移植性も高いような実装を作ってみようと思い立ったのが昨年10月頃。様々な検討を

                    京都収納棚:DBMの率直な壱実装 - mixi engineer blog
                  • Erlang で memcached を作ってみました。 : DSAS開発者の部屋

                    先日、こちらの Erlang の世界ではmemcachedとか要らない を興味深く読ませて頂きました。 たしかにクライアント側も Erlang で書かれている場合、例えばキャッシュサー バーにアクセスを行う WEB アプリケーションも Erlang で書かれていれば Erlang のプロセス間通信を使用することで簡単にキャッシュサーバを実装する ことが出来そうです。しかし、WEB アプリケーションなど、全てのシステムを Erlang で書くにはまだ私にとって勇気が要る事なので TCP/IP で memcache プ ロトコルを喋る Erlang 版 memcached を作ってみました。 その名も ememcached です。 % ememcached.erl -module(ememcached). -export([start/0, ememcached/1, process_comm

                      Erlang で memcached を作ってみました。 : DSAS開発者の部屋
                    • CoolCoding.com is for sale | HugeDomains

                      Make 24 monthly payments Pay 0% interest Start using the domain today. See details

                        CoolCoding.com is for sale | HugeDomains
                      • node.jsでtrayという画像アップローダを作った - はこべにっき ♨

                        昨日のKyoto.js #2 で、trayというお手軽な画像アップローダについて発表してきました。ドラッグアンドドロップで画像がアップロードされます。画像は12枚のパネル上に表示され、誰かがアップロードするとリアルタイムで画面が切り替わったりします。 http://tray.douzemille.net:8080 http://imagetray.herokuapp.com/ でお試しできますので、お手元の適当な画像をドラッグアンドドロップして遊んでみてください! 何アップロードされているかはよくわからないので、ご注意ください。たまに勝手に適当な写真に切り替わるようにしてあります。*1 ドラッグアンドドロップでのアップロードが手軽で便利なだけではなく、12枚のパネルにきれいな画像をはめこむおもしろさもあります。 割と簡単に設置できておもしろいのでぜひおためしください。GIFアニメを投稿しま

                          node.jsでtrayという画像アップローダを作った - はこべにっき ♨
                        • ngx_mrubyで最初のHTTPSアクセス時に自動で証明書を設定可能にするFastCertificateの提案とPoC - 人間とウェブの未来

                          Let’s EncryptやACMEプロトコルによるDV証明書取得の自動化に伴い、証明書の取得と設定が簡単になってきました。 一方で、ACMEをツール化したものが増えるに従って、ACMEってそもそもどういう動きになっているのか、とか、自分たちの用途でどういう使い方がありえるのかとかが余計にわかりにくくなってきており、どこまで自動化できるかもよくわからない場合が多いのではないでしょうか。 そこで、 ドメインとAレコードの紐付けさえしていれば、最初のアクセス時に自動で証明書をとってきて、HTTPS通信にできないか というような、いわゆる FastCertificate 的な動きを実現したいと考え、ACMEの通信の中で各種処理を別のスクリプトでhookできるdehydratedとngx_mrubyを応用して実現可否も含めてPoCを実装してみました。 ※ FastContainerという考え方につ

                            ngx_mrubyで最初のHTTPSアクセス時に自動で証明書を設定可能にするFastCertificateの提案とPoC - 人間とウェブの未来
                          • Rails:Service層を運用して良かったところ、悪かったところ - Qiita

                            1年前くらいにRailsの設計にDDD(ドメイン駆動設計)のService層を導入し、Modelの肥大化対策をしました。 この記事では、まずどのようなルールでService層が組み込まれているかと、1年間運用してみて良かったところ、悪かったところの感想を書きます。 [2018/05追記] 最近ではサービス層の導入は賛否両論あるようなので、導入する際は自分のプロジェクトに合っているかどうかを十分にご検討ください! Service層を導入するきっかけになった問題点 Modelの肥大化 Model間の複雑な依存関係 多数のミドルウェアの導入による複雑さの倍増 これらにより.. メンテナンスやテストがしにくい コードが整理されていないのでとにかく読みづらい Model複雑化の例 <ユーザがECサイトの商品をお気に入り(like)にするメソッドを書く場合> 処理に関連するテーブル my_itemsテ

                              Rails:Service層を運用して良かったところ、悪かったところ - Qiita
                            • 次期Visual Studio 2010と.NET Framework 4.0の新機能

                              次期Visual Studio 2010と.NET Framework 4.0の新機能:特集 マイクロソフトの開発ツール戦略(1/3 ページ) 2010年前半ごろのリリースが予想される次期Visual Studio 2010と.NET 4。それらに搭載予定の主な新機能や機能強化を紹介する。 連載目次 本稿では、次期Visual Studio 2010(以降、VS 2010)および.NET Framework 4.0(以降、.NET 4)の新機能を概観する。C# 4.0、Visual Basic 10については、本稿では紹介しない。 なお、本稿はPDC(Professional Developers Conference) 2008の内容をベースにしており、製品版が必ずしもこのとおりになるとは限らないことは注意してほしい。本稿で紹介した機能が、実際の製品では搭載されないことはあり得る。 それ

                                次期Visual Studio 2010と.NET Framework 4.0の新機能
                              • Redisの監視/分析系ツールまとめ « Rest Term

                                Redis関連の監視/データ分析系ツールについてメモしておきます。 随時追記予定。実務で有用なツールが他にありましたら教えていただけると嬉しいです。 環境 CentOS 5.9, Ubuntu 12.04 (x86_64) Redis 2.6.10 (※ CentOSの6.x系への移行は足踏み状態。相当大変ですよね。。) 以下の順に紹介していきます。 Redisコマンド Redis Sentinel Redis Live Redis Faina Redis Sampler redis-top Nagiosプラグイン Zabbixテンプレート Muninプラグイン Cactiプラグイン 最後のCactiプラグイン以外は実際に導入して試してみました。以降、見出しに各プロダクトへのリンクを貼っておきます。 Redisコマンド ツール紹介の前にまずは基本から。Redisには監視やデータ解析用途で使

                                  Redisの監視/分析系ツールまとめ « Rest Term
                                • IBM SPSS Modeler - ODBC Configuration Best Practices and Troubleshooting

                                  IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

                                    IBM SPSS Modeler - ODBC Configuration Best Practices and Troubleshooting
                                  • fluentdによる大規模キュー設計

                                    「Fluentd Meetup 2015 夏」で発表した内容です。

                                      fluentdによる大規模キュー設計
                                    • memcached互換のNoSQLデータベース「Membase」がオープンソースで登場

                                      memcachedの開発者らが中心となって今年の3月に立ち上げた企業NorthScaleが、memcached互換のNoSQLデータベース「Membase」のオープンソースプロジェクト「membase.org」を6月23日に発表しました。 MembaseはWebアプリケーションのバックエンドに使われることを想定したキーバリュー型データストア。高速かつ高いスケーラビリティを目指したもの。 主な機能として、将来にわたってmemcachedとプロトコルの互換性を保証しつつ、ディスクへの永続性機能(データのディスクへの書き込み)、階層型データストア管理、データレプリケーション、稼働状態での設定変更とノード間のリバランシング機能なども備えると説明されています。 Membaseの特徴はmemcached互換とスケーラビリティ MembaseのWebサイトの情報を基に、特徴を紹介しましょう。 動的なノー

                                        memcached互換のNoSQLデータベース「Membase」がオープンソースで登場
                                      • Jepsen: PostgreSQL, Redis, MongDB および Riak の分割耐性をテストする

                                        Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

                                          Jepsen: PostgreSQL, Redis, MongDB および Riak の分割耐性をテストする
                                        • Redis 4.0の目玉機能解説 - Qiita

                                          redis 4.0 GA release ついに昨日(2017/07/15)に、redis 4.0のstableがリリースされました。 今までのredisと何が変わったのか?というのを、軽くまとめたいと思います。 間違いなどありましたら、指摘いただけると幸いです。 前回のqiita記事 プロダクションで2年間RedisClusterを運用してみて release notes 一部抜粋すると Note that 4.0 is probably one of the most extreme releases of Redis ever made in terms of changes inside the internals: all the aggregated data types no longer use Redis Objects structures but directly S

                                            Redis 4.0の目玉機能解説 - Qiita
                                          • 第1回 バーストトラフィックの発見と対処 | gihyo.jp

                                            はじめに 初めまして、(⁠株)ミクシィの中野和貴です。私はシステム本部運用部インフラグループネットワークチームという部署で働いており、ほかのメンバーと共にmixiのネットワーク部分全般に関して設計・保守・運用を行っています。ここでは『WEB+DB Press』Vol.50~55にて連載されていた「大規模Webサービスの裏側」で紹介しきれなかったエピソードや、その後のインフラ事情を紹介していきます。 日々大量のトラフィックが流れるmixiのネットワークですが、大きくなってくるとやはりいろいろな問題も出てきます。今回はそれらの問題の中で普段運用しているとなかなか気付きにくいバーストトラフィックに起因する問題事例を紹介します。 ミクシィのネットワーク構成と問題の発覚 mixiでは主要なネットワーク機材にはお金をかけていますが、サービス規模からどうしてもラック数が多くなってしまうため、エッジスイッ

                                              第1回 バーストトラフィックの発見と対処 | gihyo.jp
                                            • Redisで1000万件のデータを圧縮しつつ定期的に洗い替えする - スペクトラム

                                              概要 お仕事でRedisを触ってたので知見をまとめる。 Redisは高速はKVSだが、今回1000万件を超えるような大量のデータを扱った。 大量のデータをバッチで定期的に書き込んで、参照側では高速に返すシステムを考える。 バッチはユーザーの行動を『現在から1日以内にログインしたユーザー』のように時間区切りで条件検索している。そのため、検索する時間が変われば結果も変わるので、定期的に実行してデータを洗い替えている。 検索結果は1000万件あっても対応したい。 ユーザーがアクセスしてきたときにはこの検索結果の対象かどうか判断して結果を返したい。このユーザーからのアクセスは大量にあるため即座にレスポンスを返さなければならない。 洗い替えることによって使わなくなったデータは容量を空けるために削除したい。 クエリ結果はユーザーのidなので19475934や59103940のような法則性の薄い数字の列

                                                Redisで1000万件のデータを圧縮しつつ定期的に洗い替えする - スペクトラム
                                              • Redis布教活動報告 ISUCON 編 - unknownplace.org

                                                最近 Test::RedisServer とかもろもろつくっててばれてるかもしれませんが、だいぶ Redis 期にありまして、最近の趣味は?っていう問いにはだいたいRedisのソースを読むことですってなくらいなのですが、 memcached とかシンプルな KVS と比べるとだいぶ機能が豊富なので使い方を迷ったりとかそういう事例もあり、周りにもう少し使える人を増やさなければ僕の書いたコードが属人化しててつらい感じになるなーっていうわけで、 布教活動をおこなっておりまして、その一環として ISUCON2 に参加してきましたのでその報告です。 livedoor Techブログ : #isucon2 リアルタイムフォトレポート 更新終了 前回の優勝チームに混ぜてもらった感じでだいぶついてる感じもしますが、見事連覇を果たせ、懇親会でも redis redis と連呼してきたのでだいぶ興味持った方も

                                                • RedisをKeepalivedでフェイルオーバーする構成案 - 酒日記 はてな支店

                                                  master slave 構成を取っている Redis で、master が落ちた場合に slave を昇格させてフェイルオーバーしたいという要件がありまして、Keepalived と組み合わせて構成してみました。Redis の運用経験がないのでご意見などいただければありがたいです。 Scientific Linux 6.2 keepalived-1.2.2-3 redis-2.4.10 前提 Redis のレプリケーションではマルチマスター構成を取ることができない Redis の slave は起動時に master に接続し、全データを取得してコピーを取る その後は順次 master で更新されたデータをコピーする redis-cli で slaveof コマンドを実行することで、動的に master, slave を切り替えることが可能 このような作りになっているため、2ホスト間で

                                                    RedisをKeepalivedでフェイルオーバーする構成案 - 酒日記 はてな支店
                                                  • クラシル、不屈のキャッシュ戦略 - dely Tech Blog

                                                    こんにちは! プロダクトマネージャーをしている奥原 (@okutaku0507) です。前までサーバーサイドのリードエンジニアをしていました。 delyの開発ブログが長らく更新されておらず、不甲斐ないです。これからは活発にdelyが取り入れている最新技術や実際にあった事例、取り入れているアーキテクチャなどを中心に発信していきたいと思っています。 久しぶりの今回は、delyが運営/開発しているレシピ動画サービスであるkurashiruの涙あり、笑いありのキャッシュ戦略について歴史と実際の事例を元に書いていきたいと考えています。最後には、僕が作成したクラシルに用いられているキャッシュ戦略をgemにしたライブラリを紹介いたします。 はじめに サーバーサイドチームはクラシルの開発から1年半程度まで、主に僕一人しかいませんでした。TVCMによる急激なユーザー数増加や新機能開発、社員100人を支える管

                                                      クラシル、不屈のキャッシュ戦略 - dely Tech Blog
                                                    • Rails4.2のコネクションプールの実装を理解する - Akatsuki Hackers Lab | 株式会社アカツキ(Akatsuki Inc.)

                                                      tl;dr Railsではコネクションプール数を設定していても、1スレッド辺り1コネクションしか持ちません。 発端 アカツキではRails + Unicorn + Nginx + MySQLの構成をAWSで運用しており、c3.4xlargeのインスタンス上で1台辺り64のUnicornワーカープロセスが実行される設定になっています。 ソーシャルゲームでは時にたくさんのアプリケーションサーバを並列稼働される必要がでてきます。特に年末年始の時期は平時の2-3倍のトラフィックが予想され、アプリケーションサーバを最大100台で稼働させる必要がありました。 Railsのdatabase.ymlのpool設定は5だったので、単純に考えると最大 100台 * 64プロセス * 5接続 = 32,000個の接続が常時貼られるのでは?MySQLのmax_connectionsの設定は大丈夫か?という議論があ

                                                        Rails4.2のコネクションプールの実装を理解する - Akatsuki Hackers Lab | 株式会社アカツキ(Akatsuki Inc.)
                                                      • YAPC::Asia 2008の資料公開します - mixi engineer blog

                                                        開発部・システム運用グループの長野です。5月15日・16日に東工大大岡山キャンパスで開催されたPerlのカンファレンス、YAPC::Asia 2008に参加してきました。2日目にはセッションの時間を2つ頂いて、発表をしてきたのでその資料を公開します。 ■memcached in mixi [pdf] memcachedはmixiのシステムでも重要なアプリケーションの1つになります。発表ではmemcachedの基本から、弊社でのmemcachedの事例、そして分散方法の改善、TokyoTyrantの活用事例について説明させて頂きました。発表の最後時間が足りなくなり説明できなかったスライドも含まれていますのでご覧下さい。 memcachedについては、研究開発グループのtmaesakaによる記事が、またTokyoTyrantの活用事例については、こちらの記事にもありますので参考にして頂けたら幸

                                                          YAPC::Asia 2008の資料公開します - mixi engineer blog
                                                        • Key Value Storeについて

                                                          主な3つの機能について実装状況を示してみました。 「データ永続化」とは、ストレージサーバを再起動してもデータが失われないようにデータをメモリではなくHDD等に格納できる機能です。例えば、memcachedはメモリにデータを置くため、ストレージサーバを再起動するとデータが失われます。 「データ冗長化」とは、格納したデータがストレージサーバ側で自動的に複数のストレージサーバにコピーが作られる機能です。1台(または数台)のストレージサーバがダウンしてもデータが失われることはありません。 「データ分散」とは、キーのハッシュ値等を元にデータの格納先のサーバを振り分ける機能で、負荷分散を図ることができる機能です。なお、memcached、Tokyo Tyrantにはサーバ側での分散機能はありませんが、クライアント側のライブラリによって格納先サーバを分散させることも可能です。 memcachedプロトコ

                                                            Key Value Storeについて
                                                          • GWにGo言語で作ったMeetAppというサービスの開発記録 - きょこみのーと

                                                            GWに2〜3日くらい本気だして、MeetAppというサービスをリリースしました。 フロントエンド&企画をやっていただいた@tejitakさんのブログに大体の概要が書いてありますので、こちらを併せてご覧いただければと。 GWハッカソンでMeetAppという趣味アプリ開発者のためのサービス作りました - TEJI TECH BLOG 自分の方は、Goの構成や使っているライブラリや開発中のTipsなどをまとめようかと思います。 Goの構成 使ったライブラリ guregu/kami : Webフレームワーク(先輩) unrolled/render : jsonやhtmlのレンダリング kyokomi/goroku : 今回作った(heroku用) gotsunami/go-cloudinary : CloudinaryのAPI gopkg.in/airbrake/gobrake.v1 : airb

                                                              GWにGo言語で作ったMeetAppというサービスの開発記録 - きょこみのーと
                                                            • #isucon2 で優勝してきました - 酒日記 はてな支店

                                                              なんでもありのいい感じにスピードアップコンテスト ISUCON が 2 になって帰ってきたので、参加して優勝を勝ち取ってきました。 まとめ的なものはこちらから livedoor Techブログ : ISUCON チームメンバーのblogも併せてご覧ください。 おそらくはそれさえも平凡な日々: #isucon2 で連覇させてもらってきました Redis布教活動報告 ISUCON 編 - unknownplace.org 今回は前回の ISUCON 優勝メンバーのひとり @sugyan が転職して出題側に回ってしまったので、@typester を招聘してチーム編成。@songmu と共に3人でチーム「fujiwara組」として再参戦です。 以下、作業用IRCのログからふりかえりますと…… 11:39:29 <typester> とりあえずrecent_soldはキャッシュってのはまずやることか

                                                                #isucon2 で優勝してきました - 酒日記 はてな支店
                                                              • AWS Release Notes

                                                                Amazon is an Equal Opportunity Employer: Minority / Women / Disability / Veteran / Gender Identity / Sexual Orientation / Age.

                                                                  AWS Release Notes
                                                                • ElastiCache for Redisの新機能をためしてみた - クックパッド開発者ブログ

                                                                  インフラストラクチャー部 星野(@con_mame)です。 クックパッドでは、AWSを活用してサービスを行っています。 現在クックパッドでは、各種キャッシュにMemcachedやRedisを使用しています。 しかし、用途の多様化やアクセス数の増加などでこれらのサーバのインスタンス数が増加し管理コストが増加してきています。 特にRedisサーバのインスタンス数が増加しており、AWSのサービスの中でもキャッシュのサービスを提供しているElastiCache for Redisへの置換えを検討しています。 ElastiCache for Redisは、一部管理系のコマンドがrenameされており使用出来ませんが、通常のRedisと同じ物で、現在Version 2.6.13と2.8.6が使用出来ます。 SlaveにあたるものはReplication Groupという形で指定でき、Replicati

                                                                    ElastiCache for Redisの新機能をためしてみた - クックパッド開発者ブログ
                                                                  • プラグインで独自ストレージを作ろう - mixi engineer blog

                                                                    OpenSocialとかC++0xとか世の中の流れが早すぎて、いろいろと勉強しなきゃなと焦りつつも、ついついピクミン2にはまってしまうmikioです。今回はTokyo Tyrant(TT)を使ってユーザ独自のストレージシステムを簡単に構築する方法について説明します。 プラグインとは オブジェクト指向プログラミングに慣れた人にとっては、インターフェイスと実装を分離することによってプログラムの拡張性や保守性を向上させる技法(データ抽象)は常識ですよね。その考えをさらに進めると、インターフェイスのみをプログラムに記述しておいて、具体的な実装は実行時に割り当てるという、いわゆるプラグイン(plug-in)という技法に至ります。プラグインでカスタマイズできる能力をプラガブル(pluggable)などと言ったりもします。 例えばTokyo Cabinet(TC)では、レコードの挿入、削除、参照といった

                                                                      プラグインで独自ストレージを作ろう - mixi engineer blog
                                                                    • DBMSの世界はもうとっくに変革の嵐 | 独り言v6

                                                                      DBの世界に起こる変革 を見てびっくりするほどがっかりした。DBMSの世界はこれから変革が起こるどころが、もうすでに変革ががんがんに起こっていて、One Size Does Not Fit Allの時代だと言われて久しい。Oracle RDBMSだけの世界とかを見ていると、その変化が見えなくなってしまうことが多いだろう。しかしちょっとRDBMSを離れたら、現在はDBMS戦国時代であり、Oracle社もその有力なプレイヤーの一人である。 とりあえず現状を知りたいと思ったら、以下が非常に参考になる。 NoSQLの現状 50以上のソフトウェアがひしめく市場、これを戦国時代と言わずしてなんだろうか。MongoDBあり、Hadoopあり、KVSあり、NewSQLあり・・・これが21世紀のDBMSの現状だ。 ちなみに先のサイトで話にあった「ジャーナルを書かないRDBMS」というのはつまりLog Str

                                                                      • memcached を悪用したDDoS攻撃についてまとめてみた - piyolog

                                                                        2018年2月下旬にPort 11211に対するアクセス増加がみられるとしてJPCERT/CCが注意喚起を行いました。11211/udpポートはmemcachedでデフォルトで利用されているもので、JPCERT/CCは先の注意喚起で「memcached を踏み台として悪用したとみられる DDoS 攻撃の報告を受け取っています。」と攻撃への悪用についても報告しています。ここでは関連情報をまとめます。 タイムライン 日時 出来事 2018年2月21日頃 JPCERT/CCが11211/udpへのアクセス増加を確認。 同日頃から memcachedを用いたとみられるDoS攻撃が観測。 2018年2月28日 JPCERT/CCが11211/udpのアクセス制御に対する注意喚起を発表。 2018年3月1日 2時21分頃 Githubを対象にしたピーク時 1.35Tbps規模のDDoS攻撃が発生。(1

                                                                          memcached を悪用したDDoS攻撃についてまとめてみた - piyolog
                                                                        • Raft + Redis な内製Redisサーバの紹介 - Mirrativ Tech Blog

                                                                          こんにちは ハタ です。 Mirrativのインフラ内で実際に開発・運用している内製のRedisサーバについてお話したいなと思っています。 前回の記事 は、今回紹介する内製Redisサーバで起きたメモリリーク対策に関するお話しとなっておりますので、もし未読であればあわせて読んでいただければと思います。 今回はなぜ Redis サーバを内製することにしたのかの経緯や実装についての簡単な紹介が出来たらなと思っています Redis 導入の経緯 課題感: 揮発しないでほしい 課題感: 生存時間が短いデータを保持したい 課題感: 日次データをなんとかしたい 候補 Redis Cluster のヨシアシ: slot 管理 Dynomite のヨシアシ: sharding/replication radisha = Raft + Redis + HA Raft クラスタ コマンドとデータストア レプリケ

                                                                            Raft + Redis な内製Redisサーバの紹介 - Mirrativ Tech Blog
                                                                          • mod_libmemcached_cacheでApacheのcacheをmemcachedに保存する : blog.nomadscafe.jp

                                                                            mod_libmemcached_cacheでApacheのcacheをmemcachedに保存する Apacheのmod_cacheのキャッシュ保存先にmemcachedが使えればいいのにと長年思ってきましたが、mod_libmemcached_cacheがそれを実現してくれました。 しかも、libmemcachedを利用しているので、性能も高く、またConsitent Hashingも使えますし、バイナリプロトコルもばっちりです。 図にするとこんな感じ。revserse proxyのcacheがmemcachedになるので、cache効率が上がり、またApplicationサーバからも同じmemcachedが参照できるのでcacheを変更したりできるかもしれません。 導入 mod_libmemcached_cacheはgithubから入手できます http://github.com/a

                                                                            • Node におけるスケールアーキテクチャ考察(Scale 編) - Block Rockin’ Codes

                                                                              [追記] 途中までは Node での複数プロセス起動、プロセス間通信等について書かれていますが、後半は自分が前回の記事 を書くにあたって自分が考えてたことを少し強引に広げて書いた個人的な妄想が多く含まれ、Node におけると言っときながら、後半は Node 関係ない感じになってしまいました。 正直まだ分かっていないことが多いです。変なところをどんどん指摘していただけるとむしろ嬉しいです。 Node におけるスケールアーキテクチャ考察(SSP 編) - Block Rockin’ Codes の続きです。 もともと何となく結論があって書き始めたんですが、書きながら色々調べているうちによくわからなくなりました。 まだまだ調べたらないことがわかったので、とりあえず今わかっているところまで書きます。 結局何がいいたいのかよくわからない感じかもしれないけど、ゴールは SSP のバックエンドの Nod

                                                                                Node におけるスケールアーキテクチャ考察(Scale 編) - Block Rockin’ Codes
                                                                              • The Benchmark with Go REST API Server - stanaka's blog

                                                                                I gave a presentation about lightweight REST API Server by Go, and performance comparison with Go, Perl and Ruby at GoCon 2013 autumn. The slide about benchmarking result is as follows. This shows milliseconds per request with 10,000 sequential requests at various conditions, which are go/perl/ruby, messagepack/json, and mysql SQL query/innodb memcached plugin. "direct memcached (innodb)" is direc

                                                                                  The Benchmark with Go REST API Server - stanaka's blog
                                                                                • 噂のTokyoCabinet/TokyoTyrantを使ってみた - (゚∀゚)o彡 sasata299's blog

                                                                                  2009年10月04日20:18 KVS Ruby 噂のTokyoCabinet/TokyoTyrantを使ってみた key-value ストアに興味がある ささたつ です。key-value ストアとして有名なものといえば memcached かと思いますが、他にも TokyoCabinet や TokyoTyrant というものも注目されています(不思議な名前ですね!)。key-value ストアでありながら高速、かつ、データをメモリで無くファイルに保存しているため、サーバが落ちてもデータが消えないとか。 実際に mixi の最終ログイン時間の保持などに使われているそうです。 memcached をセッションの保持などに使っている場合、memcached のサーバがダウンしてしまったら、データは全て消えてしまいます。その結果 RDBMS にアクセスが集中し、パフォーマンスが大幅に悪化し