タグ

performanceに関するKiskeのブックマーク (18)

  • Last.fmがサーバにSSDを導入、分散ファイルシステムもSSD対応にしてスケール向上に成功!

    音楽配信サイトのLast.fmは、今年の10月からXbox Liveでも利用できるようになったことを受けてユーザー数が大幅に増加。これに対応するためサーバにSSDを採用したところ、問題なくスケールの向上に成功してしまったことをブログ「Launching Xbox, Part 2 - SSD Streaming」で明らかにしています。 SSDで同時接続数が300から7000に増加 Last.fmはこれまで7200rpmのSATAドライブをバックエンドに利用。ファイルシステムとしてオープンソースの分散ファイルシステムであるMogileFSを採用していました。 オーディオストリーミングの能力は基的にこのMogileFSの管理下にあるハードディスクのランダムI/O性能に依存しており、現在は1つのハードディスクあたり約300同時接続をサポートしていたとのこと。 しかしXbox LiveがLast.

    Last.fmがサーバにSSDを導入、分散ファイルシステムもSSD対応にしてスケール向上に成功!
  • How We Made GitHub Fast

    EngineeringHow We Made GitHub FastNow that things have settled down from the move to Rackspace, I wanted to take some time to go over the architectural changes that we've made in order to bring… Now that things have settled down from the move to Rackspace, I wanted to take some time to go over the architectural changes that we’ve made in order to bring you a speedier, more scalable GitHub. In my f

    How We Made GitHub Fast
  • Yahoo!ニュース高速化へのサイトデザイン側からのアプローチ

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、Yahoo!ニュースのデザイナーの黒田・由衛です。 Yahoo!ニュースが2009年4月27日にリニューアルしました。今回のリニューアルでは、お客様に快適にサイトを利用していただけるよう最速でページを表示させることに重点をおきました。 お客様がウェブを閲覧するのは1日の中のほんの限られた時間です。その貴重な時間を割いてYahoo!ニュースに来ていただくわけですから、1ページでも多くの記事を「読みやすく」「ストレスなく」見ていただけるようにするのが、Yahoo!ニュースがお客様にできる最高のおもてなしだと考えています。そこで、今回のリニューアルでは、サイトデザイン側からのアプローチとして以下の2点の施策を行いました。 1

    Yahoo!ニュース高速化へのサイトデザイン側からのアプローチ
  • [CSS]外部スタイルシートの指定は@importとlinkでどちらがいいか

    外部スタイルシートの指定は@importとlinkでどちらがいいかと、書籍「ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール」の@importはパフォーマンスに悪影響を与えることについてのフォローアップを紹介します。 don't use @import 内容は、IEでは@importで外部スタイルシートを指定すると、パフォーマンスに悪影響を与えるので使用しないでください、というものです。 下記は、外部スタイルシートを@importとlinkを組み合わせて、それぞれのパフォーマンスを比較したもので、キャプチャはそのサイトのものと、参考に当環境でIE7/Fx3(XP)を検証したものです。 @import @import 2つの外部スタイルシートを@importで指定。 <textarea name="code" class="html" cols="60" rows="5">

  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • はてなブックマークが重い件について、Page Detailerというツールを使って調べてみる - VTuberになったプログラマーの魂の残滓

    JavaScriptの部分は というわけでid:amachangに任せましょう。 というわけでそれ以外の部分でいったいどこが重いのか 何が重いの?ということで重たい箇所を分析していきましょう。 IBM PageDetailer 解析ツールとしてIBM PageDtailerを利用します。 alphaWorks Community 解説するよりも見てもらうほうが早いと思うのでさっそく使ってみるよ。 ちなみに上記ソフトのダウンロードにはIBMアカウント(無料)が必要なので、使いたい人は登録しよう! http://b.hatena.ne.jp/HolyGrail/ の結果 こんな感じのグラフが出てきます。 では、詳細を見てみましょう。 このグラフですが、長い部分が http://b.hatena.ne.jp/HolyGrail/ のHTMLそのもののロード時間になっています。 内訳としては 濃い

    はてなブックマークが重い件について、Page Detailerというツールを使って調べてみる - VTuberになったプログラマーの魂の残滓
  • 7 Stages of Scaling Web Applications

    The document discusses the typical 7 stages of scaling a web application as it grows in popularity and usage. Stage 1 involves a simple initial architecture. Stage 2 adds more redundant components to improve performance and availability as usage grows. Stages 3-5 involve significant pain as the application is pushed to its limits, requiring re-architecting and partitioning of databases and service

    7 Stages of Scaling Web Applications
  • Full Stack Web Application Performance Tuning

    Presentation from the symfonyCamp 2008 on Tips for improving web application performance by covering the full stack, rather than concentrating on very specific issues. Copyright Fabian Lange 2008, all rights reservedRead less

    Full Stack Web Application Performance Tuning
  • スケーラビリティとユーザービリティの話

    先日のPhotoShareのスケーラビリティのエントリーに関しては、さまざまなご意見をいただき、とても良い勉強になっている。ただし、少し分かりにくかった部分があると思うのでそこに関して補足しておく。 サーバーのスケーラビリティに関してはすでに色々なところに書かれているが、今回の私が注目しているのは、どうやってサーバーのキャパシティを増やすか、という話ではなく、サーバーのキャパシティを超えたトラフィックが来てしまった際にどんな挙動をするように設計しておくのが良いか、という話である。 限られた資源を使って数万人・数十万人の人たちにサービスを提供するかぎり、予想外の急激なトラフィック増加でサーバーに過負荷がかかったりすることはどうしてもあるわけで、そこで問題となるのは、その手の過負荷をどうさばくか。 たとえば写真に付いたコメントを表示させる場合、「最新の情報をすぐに」表示するのが良いのが当たり前

  • Linux チューニング - Ext3 のパフォーマンスを最大化させる

    じつは自宅サーバのロードアベレージが上がり続けています。分析の結果、ボトルネックは I/O 処理でした。CPU は Athlon64 X2 4400+ ですが、まだまだ当分この CPU で間に合いそうです。HDD は当時は 7200 回転で最速だった HITACHI Deskstar T7K250 SATA2 250GB を RAID1 構成にしたのですが、今思えば速度優先で RAID0 にしておけば良かったと少しだけ後悔。 I/O がボトルネックに成っている理由ですが、Drk7jp が公開しているサービスの全てがキャッシュファイルを利用した高速化手法を取っているのですが、単純にそれらファイルの write 処理が追いついていません。常に何らかのプロセスで I/O 待ち状態が発生しているような状況です。抜的な解決方法としては disk を高速なものに交換する以外ありません。 というわけで

  • masuidrive問題 - moroの日記 別名「別プロセスのキャッシュ生成君」案

    2008-09-23 23:35追記 そういえばこのエントリはボトルネックがビュー(キャッシュ)の生成で、それが遅いせいでリクエストが詰まってしまう、ということを前提に書いてます。Railsはいまのところシングルスレッドでしか動作しないので、バランサの裏にAPサーバをn立ててもnの長寿なリクエストがきた場合、CPUやメモリに余裕があってもブロックされてしまいます。これが問題なのかな、と。 中島さんの方を読むとDBのCRUD(とくにCUD)がボトルネックになってるように見えるのですが、そっちだったらすみません。見当違いです。 追記ここまで。 masuidriveさんのWebでの非同期処理を考えてみるの件で、コメントにしようと思ったんですが、長くなったので自分の日記に。 ちょっと状況がわからないので外しているかもしれませんが(とセルフエクスキューズ)、DBの更新とキャッシュの生成をアトミッ

    masuidrive問題 - moroの日記 別名「別プロセスのキャッシュ生成君」案
  • マルチスレッド・プログラミングの落とし穴、その2

    ずいぶん前に、「マルチスレッド・プログラミングの落とし穴、その1(かもしれない)」というエントリーを書いたが、今回はPhotoShareサーバーを運営していて、まさにこのあたりの深い考察が必要になって来たので、良い機会なので続編エントリー。 PhotoShareのバックエンドのようにCRUD(Create/Read/Update/Delete)のAPIをサポートするバックエンドを作る場合、Create/Update/Deleteのリクエストに対してはクライアントからのAPIコール時にすぐに(HTTP Requestに返事をする前に)データベースに変更を加え、Readの際にも(キャッシュを使う・使わないを別にして)データベースの最新の状況を反映するデータを返すように設計するのが普通である。 このアーキテクチャの問題は、ユーザーのアクティビティが増えた時に、データベースやI/Oがボトルネックと

  • あるプロセスが利用しているメモリサイズを procfs 経由で調べる - naoyaのはてなダイアリー

    お題は「あるプロセスがどの程度の物理メモリを利用したかを知りたい」です。 手っとりばやく知りたいときは top や ps などで調べると良いでしょうか。例えば手元の coLinuxtop して M キーでソートすると emacs のプロセスが最もメモリを使っているようです。 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1923 naoya 18 0 23120 19m 3096 S 0.0 2.0 0:55.40 emacsメモリサイズは VIRT と RES がありますが、VIRT は Virtual の略で仮想メモリ領域のサイズ、RES が Resident の略で、実際に使用している物理メモリ領域のサイズ。19MB ほど使っているようです。この emacs のプロセスが利用するメモリ領域はざっくり 20MB 程度と

    あるプロセスが利用しているメモリサイズを procfs 経由で調べる - naoyaのはてなダイアリー
  • Ajaxian � Yahoo! releases new performance best practices

    Enterprise Strategy Group: Go-to-market Expertise to Help You Win

    Ajaxian � Yahoo! releases new performance best practices
  • MySQLのクエリを最適化する10のTips - PHPプロ!ニュース

    平素より「PHPプロ!」をご愛顧いただき、誠にありがとうございます。 2006年より運営してまいりました「PHPプロ!」ですが、サービスの利用状況を鑑みまして、2018年9月25日(火曜日)をもちましてサービスを終了させていただくことになりました。 サービス終了に伴いまして、2018年8月28日(火曜日)を持ちまして、新規会員登録ならびにQ&A掲示板への新たな質問、回答の投稿を停止させていただきます。 なお、ご登録いただいた皆様の個人情報につきましては、サービス終了後、弊社が責任をもって消去いたします。 これまで多くの皆様にご利用をいただきまして、誠にありがとうございました。 サービス終了に伴い、皆様にはご不便をおかけいたしますこと、心よりお詫び申し上げます。 件に関するお問い合わせはこちらよりお願いいたします。

  • InnoDB vs MyISAM vs Falcon benchmarks - part 1

    All of Percona’s open-source software products, in one place, to download as much or as little as you need.

    InnoDB vs MyISAM vs Falcon benchmarks - part 1
  • Top 84 MySQL Performance Tips | Debian Admin

    MySQL is a widely used and fast SQL database server. It is a client/server implementation that consists of a server daemon (mysqld) and many different client programs/libraries. You can check the same tips from here.Here is very useful tips for all mysql DBA’s,Developers these tips are noted from MySQL Camp 2006 suggested by mysql community experts. Kaj (Most Excellent Obvious Facilitator) Index s

  • MySQL

    HeatWave Use automated and integrated generative AI and machine learning (ML) in one cloud service for transactions and lakehouse scale analytics. Get faster insights from all your data with unmatched performance and deploy apps in your choice of cloud providers. Learn More » MySQL Enterprise Edition The most comprehensive set of advanced features, management tools and technical support to achieve

  • 1