Redis作者自身によるRedisとMemcachedの比較 | Yakst
Redisの作者antirez氏自らによる、memcachedとRedisの長所短所の比較。特に、Redisを単なるキャッシュ用アプリケーションとしてmemcachedと比較することの間違いと、それぞれの向いている使用方法についての私見。 あなたが私と面識があるなら、私が競合製品があることが悪いと考える人間でないことはご存知でしょう。ユーザーに選択肢があることは本当にいいことだと思っていますし、だからこそ他の技術とRedisを比較するようなことはほとんどしませんでした。 しかし、最適なソリューションを選ぶためには、ユーザーは正しく情報を持たねばならないのも確かです。 この記事を書くのは、有名なライブラリであるSidekiqの作者として知られるMike Perhamが、Redisのバックエンドストレージとしての使い方を書いた記事を読んだのがきっかけです。従って、私はMikeがRedisに「反
O'Reilly Media - Technology and Business Training
More than 5,000 companies count on our digital courses and more to guide their teams through the tools and technologies that drive business outcomes. We can help yours too. New AI policy for O’Reilly authors and talent O’Reilly president Laura Baldwin shares the company’s ethical approach to leveraging GenAI tools and ensuring O’Reilly experts are compensated for their work. See it now It’s time t
[Rails 4.0] 巨大なテーブルやserializeを使うときのActiveRecordオーバーヘッドを測定してみた｜TechRacho by BPS株式会社
2013.08.12 [Rails 4.0] 巨大なテーブルやserializeを使うときのActiveRecordオーバーヘッドを測定してみた Railsは遅い！とよく言われますが、高速化ポイントのうち最有力候補の1つがDB/モデル周りです。 N+1問題を修正するだけでも、体感できるレベルの高速化が期待できます。 しかし、RubyKaigiでCookPadの方も言っていたように、RDBMSがSQLを実行する時間だけでなく、ActiveRecordオブジェクトの処理は非常に重いです。 モデル周りの最適化と聞いて、一生懸命SQLをEXPLAINするのも大事ですが、ログに出力される「Prefecture Load (0.5ms)」のような数値にはActiveRecordオブジェクト部分のオーバーヘッドが含まれていないため、全体でどの部分が遅いのかを理解しないと徒労に終わってしまう可能性がありま
![[Rails 4.0] 巨大なテーブルやserializeを使うときのActiveRecordオーバーヘッドを測定してみた｜TechRacho by BPS株式会社](https://cdn-ak-scissors.b.st-hatena.com/image/square/bd987619385f6a5a8cb7a352c74a583c1605d218/height=288;version=1;width=512/https%3A%2F%2Ftechracho.bpsinc.jp%2Fwp-content%2Fuploads%2F2013%2F04%2Frails.png)
Webサイト高速化対策の現状
はじめに はじめまして、こんにちは。クラスメソッド株式会社でWebを担当している野中です。 この度、「これから身につけるWebサイト高速化テクニック」と題して記事を連載させていただくこととなりました。 本連載ではWeb担当者やWebデザイナー、コーダーの方々に向けて高速化に関する手法や技術について調べ、身につけたテクニックを細かな解説を加えて紹介していきます。中には少し難しいテクニックも含まれますが、できる限り分かりやすく、すぐに実践できるよう紹介していきたいと思います。とても長い連載ですが、よろしくお願いいたします。 なお、本連載はクラスメソッド開発ブログで連載されている「身につけておきたいWebサイト高速化テクニック」の増補改訂版です。 本連載の流れ 本連載はできるだけ多くの方に興味を持っていただけるように、最初に高速化対策の全体像と必要な知識を紹介します。その後、具体的な高速化対策と
なぜあなたがウェブサイトをHTTPS化するとサイトが遅くなってユーザーが逃げていくのか - 射撃しつつ前転 改
完全に釣りタイトルですけど中身は真面目に書くよ。 近年、ウェブサイトのHTTPS化が流行のようになっている。私の知る限り、Googleの各種サービスやTwitter、Facebookなどが完全にHTTPSで通信を行うようになっている。HTTPS、つまりSSLによる通信の暗号化によって、ユーザにこれまでよりも安全なウェブサイトを提供できる。 しかし、あなたが作っているサイトをふと思いつきでHTTPS化してしまうと、たぶん、これまでよりもサイトが遅くなる。ここでは、HTTPSで通信する場合の問題を解説する。 なぜ遅くなるのか HTTPで通信する場合、クライアントがサーバへと接続するためにはTCP/IPの3ウェイハンドシェイクという手順が必要になる。めんどくさいのでここでは詳しくは説明しないが、要するにクライアントがリクエストを投げる前にパケットを１往復させないといけないのである。パケットの往復
WordPress の負荷テストと環境改善 - Cybozu Inside Out | サイボウズエンジニアのブログ
「サイボウズ・アドベントカレンダー2012」も、残すは今日と明日のみです（これまでの記事一覧）。 こんにちは、社内インフラ担当の稲生です。今回はWordPressサーバの簡単な改善方法と負荷テストによる比較のお話です。 一般の商用サイトでも利用可能な「WordPress」。サイボウズのWebサイトでも CMS で使ったり、有料 Blog サービスから移行したりと、その恩恵に与っています。そんな WordPress 環境ですが、最近サーバへの負荷が高い？ という連絡を受け、調査がてら負荷テストと環境改善に取り組んだ時のことを紹介します。 ※ 因みにサーバ高負荷の原因は WordPress と全然関係ありませんでした。詳細は本稿の主旨と異なるため省きますが、怪我の功名ということで。WordPress は良い子ですよ。 テスト環境を用意する テスト用に以下の仮想環境を用意しました。 CPU Xe
ウェブオペレーションエンジニアはリリース前のソースコードのココを見ているッ！ - blog.nomadscafe.jp
「ウェブオペレーションエンジニアはリリース前のソースコードのココを見る！」みたいな記事があればいいね — masahiro nagano (@kazeburo) November 20, 2012 ちょいと前にツイートしたこの件のまとめ。新規サービスのリリースや既存サービスに新しい機能が追加される際に、しばしばそのソースコードを確認しているのですが、僕がどんなところを見ているのかまとめてみました。 そのサービスへの導線とランディングページの確認 まず、そのサービスへの導線やランディングページを確認します。そしてその一番アクセスがあろうページ、一つか二つに確認対象を絞ります — masahiro nagano (@kazeburo) November 20, 2012 どんな素敵なサービスも、機能も適切な誘導がなければ使われる事はありません。また誘導次第では大量のアクセスが一度にサーバに対し
プロのサーバ管理者がApacheのStartServers, (Min|Max)SpareServers, MaxClientsを同じにする理由 - blog.nomadscafe.jp
kazuhoさんが「プロのサーバ管理者の間では存在価値が疑問視されて久しい (Min|Max)SpareServers だと思う」と書いたり、hirose31さんが去年のYAPC::Asiaで{Start,{Min,Max}Spare}Servers,MaxClientsは同じにしているよと発表したり、実際前職のサーバはそのように設定されていたのですが、自分でうまく説明ができてなかったので、調べながら書いてみた。 本当はイントラブログ用に書いていたものですが、がんばったので転載。 前提として、CPUの使用率におけるsystemとfork Re: クラウドがネットワークゲーム開発者にもたらしてくれたもの - blog.nomadscafe.jpでも書いている通りforkってのはサーバにとって重い部類の処理になります。つまり負荷の高いときにforkを大量に行うのはしてはならないことの１つです。
ウノウラボ Unoh Labs: Apache MPM の基礎をしっかりと理解しよう！
naoya です。最近、とうとう花粉症の季節に入ったので、生まれて初めて空気清浄機を購入しました。 さて、今日は Apache HTTP サーバの MPM (Multi Processing Module) について解説したいと思います。普段、ウェブサーバを構築するとき、Apache HTTP サーバを使うことが多いと思いますが、Apache HTTP サーバを使う上で MPM について理解しておくことは大事です。 この MPM ですが、Apache HTTP サーバではリクエストを処理する部分のことをさします。MPM は、Apache HTTP サーバ 2.0 系から採用されています。Apache HTTP サーバの MPM には、次の種類があります。 prefork worker perchild winnt それぞれの MPM について解説します。まずは、一番代表的な prefork
パフォーマンス比較 Cassandra、Mongodb、SQLite、H2、MySQL、Postgres - cypher256's blog
下記のようなシステムでパフォーマンスが良さげな SQLite を使用予定ですが、もっと速いものが無いか確認のため他のデータベースのパフォーマンスを計測してみました。SQL 利用前提ですが、NoSQL が圧倒的な性能を出す場合は検討する必要があるので KVS も確認しました。 データ件数は 1 億件程度、JDBC SQL 利用可能 INSERT、UPDATE はバッチ SELECT は主キーアクセス性能を重視 将来スケールアウトのための分散はありえるが、スタンドアロンで遅いのはだめ データベースのパフォーマンス比較 計測したデータベース データベース名 タイプ 形態 評判 計測についての備考 SQLite RDB 組み込み ※2 おもちゃ、Android標準 JDBC操作 ※1 H2 RDB 組み込み ※2 組み込み最速 JDBC操作 ※1 Derby RDB 組み込み ※2 Java標準で
Webパフォーマンス ベストプラクティス - Make the Web Faster
Webパフォーマンス ベストプラクティス Last updated: 02 October 2012 翻訳：@t32k WebページをPage Speedで調べるとルールに準拠していないものが提示される。このルールというのは、一般的にあなたが開発段階において取り入れるべきフロントエンドのベストプラクティスだ。あなたがPage Speedを使用しようとしまいと、私たちはこの各ルールについてのドキュメントを提供する（たぶんちょうど新しいサイトを開発中でテストする準備が整ってないだろう）。もちろん、これらのページはいつでも参照することができる。私たちはあなたの開発プロセスに取り入れてもらうために、このベストプラクティスを実装するための明確なティップスと提案を提供する。 パフォーマンス ベストプラクティスについて Page Speedはクライアント側からの観点でパフォーマンスを評価し、一般的にペー
ウェブサイト高速化勉強会に参加してきた #tnmk0929 - Diary of absj31
ウェブサイト高速化勉強会 : ATND 2012/09/29 ウェブサイト高速化勉強会 #tnmk0929 - Togetter さくらのVPSにてサーバ＆ドメイン取得を行った流れもあり、個人用鯖にも何らかのWebコンテンツを配備・公開して行く事になるだろう(てかそういう風にして行きたい)と言うのもあり、ちょうど目にしたこちらの勉強会に目が留まり、参加して来ました。 なので現状のWebサイトを高速化させるために、ってのではなくて今後のために、という意味合いが強いですね。 会場は横浜タネマキ。最近は個人的にはYokohama.groovy等で2週間に一遍は使ってる感じですね。 タネマキ 【コワーキング ＆ シェアオフィススペース】 開始間際、ディスプレイ接続で調整が上手く行かず10分程押した後スタート。 Web Site Optimization for Beginners こもり まさあき
「バックエンドの経験はなかった」Instagram創業者は、どうやってシステムをスケールさせてきたか
昨日のPinterestの記事「Pinterestの急成長を支えてきたアーキテクチャとは？ Pythonで開発しAmazonクラウドで運用」に続いて、やはり写真を中心としたサービスで急成長してきたInstagramのスケーラビリティについて、まとめてみました。 InstagramもPinterestと同様に、基本はAmazonクラウド上でPythonとフレームワークのDjangoを使ったシステムを構築しています。興味深いのは、創業者の二人ともバックエンドの経験がないなかで試行錯誤をしてシステムをスケールさせてきた点です。 Instagramは先月、Facebookに買収されると発表されています。この先、Instagramのシステムはどう変わっていくのでしょうか。 Instagramのシステム構成 約半年前、昨年12月にInstagramのブログに投稿された記事「What Powers In
例えば GC を止める・Ruby ウェブアプリケーションの高速化 - 2nd life (移転しました)
最近クックパッドでは、アプリケーションサーバの大半が Rails 2.3 から Rails 3 に置き換わったのですが*1、リリース前のベンチマークの時点ではあまりパフォーマンスが出ず四苦八苦していました。具体的には Rails 2.3 の時と比べ MRI 1.8.7 だとレスポンスタムが200%ぐらい遅い結果でした。Rails 3 になって実装が Merb core を取り入れ疎結合で綺麗になった反面、より多くのオブジェクトと・メモリを利用する様になった影響かと思います。 そこで Ruby インタプリタの変更*2を行い検証をしたところ MRI 1.8.7 (Rails 2.3と比べ) 約200%遅い MRI 1.8.7 -> Ruby Enterprise Edition 1.8.7 2011.03 (tcmalloc 無効) 約180%低速 MRI 1.8.7 -> Ruby Ente
すぐに実施できる、あなたのウェブページのスピードを改善する10のチップス
ウェブページのスピードを改善することは最適なユーザエクスペリエンスを提供するだけでなく、Googleの検索結果にも影響を与える大切な要因です。 すぐに実施できる、あなたのウェブページのスピードを改善する10のチップスを紹介します。 10 Tips for Decreasing Web Page Load Times [ad#ad-2] 下記は各ポイントを意訳したものです。 1. 現在のスピードをチェック 2. 画像の最適化 3. 画像は実寸で配置 4. コンテンツを圧縮して、最適化 5. スタイルシートは上に配置 6. スクリプトは下に配置 7. スクリプトとスタイルシートは外部ファイルで 8. HTTPリクエストは最小限に 9. キャッシュの利用 10. 301リダイレクトは避ける 参考資料とツール 1. 現在のスピードをチェック まず、現在のあなたのウェブページのスピードの分析からはじ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://rubytune.com/cheat/
ソーシャルゲームスケールアウトの歴史
YAPC::Asia 2011 / 高速化のはなしとか