Pick up the 9th-gen iPad with two years of AppleCare+ for only $298
なぜDMMがweb3に参入したのか。Seamoon Protocolが目指す新たなエンタメ体験の未来とは
このシリーズはHTTPリクエストの理解を通じてWebパフォーマンスの重要性について考える5章構成になっている。 【序章】HTTPリクエストは甘え 【CSS Sprite編】スプライト地獄からの解放 【WebFont編】ドラッグ&ドロップしてコマンド叩いてウェーイ 【DataURI編】遅延ロードでレンダリングブロックを回避 【終章】我々には1000msの猶予しか残されていない 最終日は、我々フロントエンドデベロッパーに課せられた理想と現実のはざまについて冷静と情熱のあいだらへんで考えていく。まずは下記のブログを読んでもらいたい。 Google ウェブマスター向け公式ブログ: スマートフォンサイトの読み込み速度を改善するために まぁ読まなくてもいいのだが、ここで述べられている重要なことは2つ。 モバイルの平均読み込み時間は7秒 しかし、ユーザーは1秒未満を求めている 平均読み込み時間の7秒とい
このシリーズはHTTPリクエストの理解を通じてWebパフォーマンスの重要性について考える5章構成になっている。 【序章】HTTPリクエストは甘え 【CSS Sprite編】スプライト地獄からの解放 【WebFont編】ドラッグ&ドロップしてコマンド叩いてウェーイ 【DataURI編】遅延ロードでレンダリングブロックを回避 【終章】我々には1000msの猶予しか残されていない 4日目は、本ブログでも何回か話題にしているインライン画像についてです。 データURIスキーム CSS Sprite画像はDataURI画像にすべきか? Data URI画像のテスト結果について 以前の記事で私は以下のように述べましたが、これはいやらしい表現だ。 DataURIの画像は、通常の画像に比べて6倍遅いとかゆう記事もある このような『xxx倍高速化』、『xxx倍遅い』と言った表現は、わかりやすい反面、本質を見失
このシリーズはHTTPリクエストの理解を通じてWebパフォーマンスの重要性について考える5章構成になっている。 【序章】HTTPリクエストは甘え 【CSS Sprite編】スプライト地獄からの解放 【WebFont編】ドラッグ&ドロップしてコマンド叩いてウェーイ 【DataURI編】遅延ロードでレンダリングブロックを回避 【終章】我々には1000msの猶予しか残されていない 2日目は、HTTPリクエストを減らす最もポピュラーな手法、CSSスプライトについて説明する。 まずは動画をご覧頂きたい。 img要素読み込み | WebPagetest Test Result CSS Sprite読み込み | WebPagetest Test Result 左が30個のアイコン画像を一つ一つimg要素として読み込んでいるのに対して、右は1つの背景画像(CSSスプライト)として読み込んでいる。この場合、
モバゲーで知られるDeNAは、バックエンドデータベースにNoSQLを使っていません。なぜか? それはMySQL/InnoDB 5.1の環境で秒間75万クエリという、多くのNoSQLでも実現できないような高性能を実現しているから。DeNAの松信嘉範(まつのぶよしのり)氏は、自身のブログにこんな内容のエントリ「Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server」(英語)をボストしています。 Yoshinori Matsunobu's blog: Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server 松信氏が指摘するように、大規模なネットサービスを提供している企業の多くは分散環境で
Fujitsu Public 1 of 16 © 2023 Fujitsu Limited 本書は、Fujitsu PRIMERGY サーバのディスク I/O パフォーマンスの担当者を対象としています。本書 では、ディスク I/O パフォーマンスの測定方法や性能データについての情報を提供しています。お客様 の要件に沿った、適切な内部ディスクサブシステムのサイジングおよび構成を決定する際の参考としてく ださい。 Fujitsu Server PRIMERGY パフォーマンスレポート ディスク I/O パフォーマンスの基本 バージョン 1.1 2023-10-03 パフォーマンスレポートディスク I/O パフォーマンスの基本 バージョン: 1.1 / 2023-10-03 Fujitsu Public 2 of 16 © 2023 Fujitsu Limited 目次 ディスクサブシステムのパ
概要 Android用のDIコンテナDaggerのパフォーマンスをGuiceと比較しました。 Dagger自体の使い方などは述べていませんので、公式サイトのドキュメントなどを参照してください。 DaggerはSquare社製のAndroidをターゲットにしたDIコンテナです。 開発者の一人であるJesse Wilson氏がプレゼンテーション(InfoQ - Dagger: A Fast Dependency Injector for Android and Java)のなかで It's like Guice, but with speed instead of features と述べているように、Guiceと同じくJSR330のAnnotationを使ってオブジェクトの依存関係を記述します。また、上述のとおりGuiceでサポートされている機能のいくつかはサポートしないかわりにパフォーマン
HTCの新型スマートフォン「HTC One」のベンチマークスコアが、Xperia Zを大きく上回っているとGSMArenaが報じています。 Xperia Z:Snapdragon S4 Pro APQ8064 1.5Ghz クアッドコア HTC One:Snapdragon 600 APQ8064T 1.7Ghz クアッドコア クロックはわずか0.2Ghzの差ですが、ベンチではそれ以上の差がついているように見えます。Snapdragon 600 APQ8064Tでいろいろと処理が効率化されているのかもしれませんね。 これ以外の種類のベンチマーク結果は「GSMArena」のサイトをご覧ください HTC Oneの記事一覧
1. SPDYブーム到来 おかげさまで、ここ数日 SPDY が私の周りで非常にブームになってきています。 前回案内したSPDY&WS勉強会は既に200名以上の申し込みがあり、今ではSPDYネタでブログを書くと非常に注目されるうれしい状況です。時代はまさに、 SPDYはハイプサイクルを順調に駆け上がっている 状況だと思います。 図1:2012年のハイプサイクル: 図はガートナー社のプレスリリース http://www.gartner.co.jp/press/html/pr20120906-01.html から引用 SPDYが、まだ黎明期に入ったばかりなのか、それとも既にピーク期に入ったのか、それは歴史が証明してくれるでしょう。 ということで勉強会までSPDY熱が冷めないよう、私もいろんなSPDYネタを出していきたいと思います。 2. GmailがハマったSPDYの落とし穴とは 先日、 Goo
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
空気を読まずにPostgreSQLのを高速化する10のポイント - 象と戯れ -空気を読まずにPostgreSQLのを高速化する10のポイント - 象と戯れ - postgresqlグループ.の元エントリを読んで思うところがあったのだが、 PostgreSQLを高速化する16のポイント だからそんなせまっくるしいところでトンチンカンにdisる暇あるんだったら自分のブログでお好みの議論を書くかさもなきゃ/dev/nullにでも吐けとやんわりと言ってるんだよハゲ。 というわけでw。 だよねw。 まあ正直、上記元ネタのほうには色々突っ込みどころ満載なのだが、それは置いておくとしてL.starなりの高速化ポイントを一度書いておかないと、と思ったので記す。ただ、L.starはもうPostgreSQL界隈から離れて久しいので、必ずしも最新の内容を網羅していないことに注意されたし。また、出来るだけPos
オープンソースのPHPアクセラレーター「XCache」の開発チームは10月29日、最新版となる「XCache 3.0.0」を公開した。プロジェクトのWebサイトよりダウンロードできる。 XCacheはPHPの中間コード(バイトコード)をキャッシュして再利用することでPHPの性能を向上させるシステム。PHPの拡張モジュールとして実装され、容易に設定、利用できる。開発者らによると、最大で5倍程度の高速化が可能という。PHP 4.3/4.4およびPHP 5系で安定して動作し、PHP 6のアルファ版も実験的という段階ながら対応する。プロジェクトはWebサーバー「Lighttpd」を開発したmOoが率いている。 XCache 3.0は4月に公開されたバージョン2.0以来のメジャーリリースとなる。コードのリファクタリングを行い、機能をサブモジュール単位にしてクリーンにしたという。APIのアップデートも
はい、これは僕がいつも良く見る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
以下のスライドを意訳したものです。Compress周りについては触れていません。「いやいや、最新の書き方だともっと良い書き方があるんだよ!」という方のコメントをお待ちしております! http://www.slideshare.net/paul.irish/perfcompression クエリをキャッシュする // 悪い例 var id = $("#content").data("id"); var itemId = $("#content").data("item-id"); // 良い例 var content = $("#content") var id = content.data("id"); var itemId = content.data("item-id"); // 悪い例 $.each(reallyLongArray, function(count, item) { v
jQuery は CSS セレクタで要素を選んで処理できるのが魅力的ですね。そんな jQuery ですが、CSS セレクタの書き方次第で速度が大幅に変わってきます。 ここでは jQuery の内部処理を疑似コードで示しつつ、jQuery を高速に使うためのポイントを5つに絞って紹介します。 何度も同じセレクタを実行しないクラスだけを指定するのは禁止#id を積極的に使う途中までの結果を再利用する子供セレクタ(>)を使うと速くなることがある ※ この記事は jQuery 1.2.6 のソースコードを元に記述しています 1. 何度も同じセレクタを実行しない 改善前 // 例題 1 $("div.foo").addClass("bar"); $("div.foo").css("background", "#ffffff"); $("div.foo").click(function(){alert
ちょうど1年前に「高負荷サイトのボトルネックを見つけるには」という記事を掲載していますが、この手のトラブルシューティングって結構大変で悩ましいですよね。はじめまして、新入りの@pandax381です。 ログからは見えてこないもの 「サイトの応答が遅い」という問題が発生した場合、その原因はどこにあるでしょうか。 Webアプリケーションの処理に時間が掛かっている DBサーバに投げたクエリーの応答が遅い サーバの処理能力を超えている などなど、いくつもの可能性があります。通常、上に挙げているような問題は、アプリケーションやサーバのログを調査することで、原因を突き止めることができます。 一方で、こういったログの調査だけでは、その原因にたどり着くことができなかったり、相当な苦労が伴うケースもあります。 あるサイトのある日の出来事 つい先日のことですが、KLabの運営している某ソーシャルゲームにて、サ
比較的新しいカーネルを採用したLinuxディストリビューションでは、ファイルシステムのI/Oバリア (I/O barrier)機能がデフォルトで有効になっています。例えばRedhat Enterprise Linux (RHEL) 6やSUSE Linux Enterprise Server (SLES) 11等はインストール直後の状態でext4ファイルシステムのI/Oバリアが有効になっているようです。 I/Oバリアは簡単にいうと、「バリア命令」の後で発行されたI/Oは、バリア命令の前に発行されたI/Oの後に必ず実行されるようにする仕組みです。つまりI/Oの順序(物理ディスクに反映される順番)をまもらせる仕組みといえます。 ファイルシステムにI/Oバリア機能が追加されたのは、ファイルシステムが不整合な状態になる可能性を減らすためです。 そもそも、急な電源断でもファイルシステムの不整合が起こ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く