月間500万PV＆転送量80TBのサイトをたった4万円で維持する方法
月間ページビュー(PV)が500万PVあり、データ転送量も80TBあるという人気ウェブサイトを400ドル(約4万6000円)以下で維持する方法を、3Dのアセットライブラリを一般公開しているPoly Havenがまとめています。 How we handle 80TB and 5M page views a month for under $400 – Poly Haven Blog https://blog.polyhaven.com/how-we-handle-80tb-and-5m-page-views-a-month-for-under-400/ ウェブサイト運営のポイントの1つは「資金リソースをどう管理するか」です。資金があればAmazon S3のようなクラウドプラットフォームを利用するのが簡単ですが、データ転送量が月間80TBもあるPoly HavenのようなウェブサイトでAmaz
Linuxサーバの反応が遅い(重い)場合の原因の調査手順
概要 Linuxサーバの反応が遅い場合の調査手順のメモ。 実行する場合は自己責任でお願いします。 原因として考慮すべき事項 サーバが遅い場合には様々な原因がありますが、以下を考慮します。 CPU負荷 メモリ不足 ディスクI/O負荷 ネットワークI/O負荷 まず、どれが原因か調査する必要があります。 top コマンド 最初は「top」コマンドを利用します。 top - xx:xx:xx up 0 min, 1 user, load average: 1.44, 0.51, 0.18 Tasks: 87 total, 1 running, 86 sleeping, 0 stopped, 0 zombie Cpu(s): 0.7%us, 0.3%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 2057692k total, 291
Linuxでロードバランサやキャッシュサーバをマルチコアスケールさせるためのカーネルチューニング - ゆううきブログ
本記事の公開後の2016年7月にはてなにおけるチューニング事例を紹介した。 はてなにおけるLinuxネットワークスタックパフォーマンス改善 / Linux network performance improvement at hatena - Speaker Deck HAProxy や nginx などのソフトウェアロードバランサやリバースプロキシ、memcached などの KVS のような高パケットレートになりやすいネットワークアプリケーションにおいて、単一の CPU コアに負荷が偏り、マルチコアスケールしないことがあります。 今回は、このようなネットワークアプリケーションにおいて CPU 負荷がマルチコアスケールしない理由と、マルチコアスケールさせるための Linux カーネルのネットワークスタックのチューニング手法として RFS (Receive Flow Steering) を
複数の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モジュールを使う
Tumblrの省メモリーな無限スクロール - 記録
無限スクロールまたはauto pagingと呼ばれるUIには、読み終えたコンテンツがどんどん画面の上のほうに溜まっていってメモリーを食い潰すという問題がある。 なかでもTumblrは画像などのコンテンツが多いため、ダッシュボードダイバーたちは無限Tumblrユーザースクリプトなどのユーザースクリプトをインストールして、読み終えたコンテンツを定期的にページ上から自動削除するといった対策を講じていた。 ところが最近のTumblrのダッシュボードでは、ポストが画面外に出るとその中の要素が一時的にページから削除され、画面内に表示されると要素が再度復元されるようになっている。どうやらこれによって無限スクロールによるメモリーの圧迫が抑えられているらしい。 関連するコードはhttps://secure.assets.tumblr.com/assets/scripts/dashboard.jsの/*! s
Mackerel - 新しいアプリケーションパフォーマンスマネジメント
Features Why choose Mackerel? Mackerel is a server monitoring service provided by Hatena Co., Ltd.that offers all the functions necessary for cloud monitoring and service operation. Overwhelmingly Simple Installation Simply install the monitoring agent on your server and you're ready to start monitoring. See details Full-fledged Monitoring The ability to integrate various communication tools promo
Googleから学ぶ ヌルヌルサクサクなスライドメニュー - Qiita
スマフォwebページのスライドメニュー アプリでは当たり前のように実装されているスライドメニューですが、webページではなかなか使い心地のよいスライドメニューが実装されているのは見かけません。 スマートフォンのブラウザではjavascriptでのアニメーションはどうしてもガタガタになってしまうし、ちらつきやスクロール制御のめんどくささからもうwebページでネイティブアプリ並のスライドメニューを実装するなんて無理と思っていました。 Facebookのwebページですらボタンの反応は悪いしアニメーションも動かないし最悪です。 一方Google先生はパーフェクトなスライドメニューを実装していた さすがGoogle先生！ 俺達に出来ないことを( Googleのスライドメニューは以下の点でパーフェクトです。 1. スライドのアニメーションがとても滑らか・ちらつかない 2. ボタンの反応にストレスを感
16の言語と57のフレームワークを比較したベンチマークが凄い
いつの時代もより高速に動作するフレームワークや言語に対する関心は高いものですが、そんな疑問に答えるWeb Framework Benchmarksの最新版が公開されています。こちらのベンチマークはテスト用のコードや環境がオープンソースになっており16の言語(C C# Clojure D Erlang Go Groovy Haskell Java JavaScript Lua Perl PHP Python Ruby Scala)と57のフレームワークについて最適な実装が集められてテストされているという点で一般性があります。また実行環境もEC2と実マシンの2種類をそれぞれ実行している点も興味深いです。 気になるテスト結果のうち特に複雑度の高いデータベースから複数件のデータを取得してHTMLページとして出力した場合の結果は下記のとおりです。 堂々のトップに輝いているのはServletで最大で1
サイトの速度 - MOL
Stopwatch | By wwarby Flickr! こんにちわ、あなたの@t32k、ごきげんいかがでしょう。みなさんはスマホWebアプリ作っていて、自分の作ったものは速いのか遅いのか気になりませんかね？僕は木に泣くりまくりすてぃです。 そうゆうわけなもんで、表示速度とか計測してみようって話になるじゃないですかー、まさかストップウォッチで計測しないとは思うんですけどー、一応どのようにスピードを計測、そのアプリの性能を評価すればよいのか一緒に考えてみましょう。 僕が昔、ゴメス・コンサルティング（現：コンピュウェア モーニングスター） のセミナーに行ってきた時の話ですが、ここの会社はサイトパフォーマンスの計測サービスを提供していて、計測で重要なのは『定期的かつ継続的かつ同手法にてパフォーマンス測定』と言っておられました。 サービスリリース時はスモールスタートなのでアプリもコンパクトですか
「全自動パラメータチューニングさん」は何であって何でないのか - 昼メシ物語
発表資料: 全自動パラメータチューニングさん // Speaker Deck ソースコード: https://github.com/mirakui/tuningsan これは何なのか ハッカソンイベント「Open Hack Day Japan」にて、24時間の制限の中で開発し、90秒でプレゼンテーションした作品です 2013/2/16〜2/18 にかけてヤフー株式会社で開催された、「Open Hack Day Japan」という大規模ハッカッソンイベントで開発しました。 上記のプレゼンテーションは発表で使用したものです。 Open Hack Day Japan - Yahoo! JAPAN 本作品は、全参加作品の中で唯一のコマンドラインツールであり非常に地味でしたが、ありがたいことに KLab賞をいただくことができました。どうもありがとうございます。 指定した1パラメータの自動調整によって
Facebookアプリを、HTML5でどうしてサクサクにできたのか。Sencha Touch開発チームが用いた3つのテクニック
Sencha Touchの開発チームがHTML5で高速に動作するFacebookアプリを開発したことを紹介した1つ前の記事 「Facebookのモバイルアプリが失敗した理由はHTML5のせいじゃない。HTML5でサクサク動くFacebookアプリを作って見せたSencha Touch開発チーム」は、非常に多くの読者に注目されました。 この記事で紹介したSencha Touch開発チームのブログ「The Making of Fastbook: An HTML5 Love Story」の後半では、どのようなテクニックを用いて高速なHTML5アプリケーションを実現したのかも紹介されています。 この記事では、その3つのテクニックについてポイントを紹介したいと思います。タイムラインやニュースフィードのようなユーザーインターフェイスを備えたモバイルアプリケーションは、これから広く開発されていくことにな
CA App Synthetic Monitor website monitoring service - Check host - IPv6 now supported, give it a shot!
CA App Synthetic Monitor monitors your web sites and servers CA App Synthetic Monitor offers you: Up to date information about the reachability of your website. Alerts are sent by e-mail, SMS (text message), or RSS. A continuous quality check of the accessibility of your web server, 24 hours per day, 7 days a week. Periodic reports are sent by email. Sign up for a free trial now and CA App Synthet
インストールするだけ! お手軽サイト高速化ツールGoogle mod_pagespeedはスゴかった | 初代編集長ブログ―安田英久
どれぐらいスゴいかというと、「サーバーにインストールするだけで、あとは設定ファイルをちょちょっといじれば、かなり高速化できちゃう」というぐらいスゴいのです。しかも、どんなサイトでも、どんなCMSを使っていても「インストールするだけ」。 Webサイトを高速化すると、ユーザーに優しいし、場合によっては検索結果での順位にも良い影響が出るかもしれない……それはわかっていても、なかなか本格的にサイトを高速化するのは難しいものです。 サーバー側の高速化に加えて、HTMLのつくりや画像のファイルサイズ最適化、さらにはCSSを調整しての画像スプライト化やCSS/JSファイルの結合・最適化によるブラウザとサーバーの通信本数削減などなど、実はやらなきゃいけないことがたくさん。 グーグルの提供するmod_pagespeedは、そうしたことの、かなりの部分を自動的に行うものです。 mod_pagespeedはこん
Webアプリケーションを高速化する50のトリック
MicrosoftのInternet Explorer PMであるJatinder Mann氏は、BUILD 2012でHTML5アプリとサイトを高速化する50のパフォーマンストリックというセッションで、Webアプリケーションを高速化する多くのチップスを提供した。 Mann氏が提供したアドバイスは、以下の6つの原則を中心に構成されていた。 1. ネットワークリクエストに迅速に応答する リダイレクトを避ける。上位1,000のWebサイトのうち63%は、リダイレクトを使用している。これらはリダイレクトをやめることによって10%のパフォーマンスを改善することができる。 メタリフレッシュを避ける。世界のURLのうち14%は、メタリフレッシュを使っている。 可能な限りユーザーの近くにあるCDNを使用してサーバーの応答時間を最小化する。 異なるドメインからのリソースをダウンロードすることによって、同時
ApacheとNginxの性能比較でevent_mpmの本気を見た
はい、これは僕がいつも良く見るApacheとNginxの性能差に見えます。大体、ApacheはNginxの75%程度の性能に落ち着きます。数十バイトの静的コンテンツに対するリクエスト処理はNginxの得意分野だと思っていたので、大体こんなものです。 そこで、真面目にevent_mpmのチューニングを行ってみました。で、幾度となくベンチを試した結果導き出した、静的コンテンツに対する同時接続数100程度に対して最高のパフォーマンスを示すevent_mpmの設定は以下のようになりました。 [program lang=’apache’ escaped=’true’] StartServers 4 MinSpareThreads 4 MaxSpareThreads 4 ThreadsPerChild 2 MaxRequestWorkers 2 MaxConnectionsPerChild 0 [/p
CentOS 6.2 で RPS/RFS を使ってネットワークの割り込み処理を複数コアに分散してみた - blog.nomadscafe.jp
以前(2010年)に「アプリケーションがマルチスレッドでもマルチコアCPUを活かせない件」というエントリにてCPUのコアが増えても割り込み処理が分散されないのでスケールされないと書いたけど、その後Linux KernelにRPS/RFSなる機能が追加され、割り込み処理が分散できるようになり、CentOS 6.2 でも使えるらしいので試してみました。 RPS/RFSについての紹介は VIOPS06で「RPS・RFS等最新Linux Kernel事例」と題してお話してきました http://d.hatena.ne.jp/syuu1228/20110722/1311322653 Linux内核 RPS/RFS功能详细测试分析 http://www.igigo.net/archives/204 が詳しい。2番目のはほぼ読めないけど、性能比較のグラフが分かりやすい。 今回試したサーバは、 OS: C
JavaScriptのパフォーマンスを上げる13のテクニック(Google I/O 2012) - ITコンサルタント成長録
JavaScriptのパフォーマンスを上げる13のテクニック 一部意訳あり。(特に関数についての11と13)。深く理解したい方はスライドや動画を観ることをオススメ。 (元記事） http://www.jonefox.com/blog/2012/07/10/13-javascript-performance-tips/ - 先日、Googleのダニエル・クリフォードは"Google I/O 2012"にて「V8で打ち破るJavaScriptのスピードリミット」と題した素晴らしい講演を行った。その中で彼は、JavaScriptコードで実践できる13のシンプルな最適化手法を紹介している。それらはChromeのV8 JavaScriptエンジンのコンパイルや実行速度を上げ、コードを速くするものだ。彼はそれらについての多くの説明を行なっているが、もしただシンプルTips一覧が欲しいというなら、以下を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する
Effective web performance tuning for smartphone
Real-Time Web App Performance Monitoring : New Relic
