タグ

ブックマーク / takehora.hatenadiary.jp (11)

  • Webパフォーマンスの振り返り 2022年 - Webパフォーマンスについて

    揺らぐ通信インフラへの信頼 今年、最も衝撃的だったのは、相次ぐ通信インフラの障害だったのではないでしょうか? 絶大なる信頼を寄せていた通信インフラが障害で接続障害に陥る、というのは、日人としては驚きの事態でした。 私たちの心の中には、「品質の日」という自負みたいなものがあります。 サイレント障害 ネットワーク上で発生する、エラーとして検知されない障害を「サイレント障害」と云います。 その多くは、自社のインフラだけを見ていて、その稼働状態だけでシステム稼働の正常・異常を判断することが原因です。 携帯網については、有線回線とは異なる複雑な仕組みと、電波を使っているという事もあって、サイレント障害の検出のソリューションは、End-to-Endの通信監視・計測による手法が以前より世界で普及していました。 それを販売していたのは、ドイツにあるSIGOSという会社です。 世界で一番はじめにWebパ

    Webパフォーマンスの振り返り 2022年 - Webパフォーマンスについて
    takehora
    takehora 2022/12/30
  • Webパフォーマンスの振り返り 2020 - Webパフォーマンスについて

    コロナ禍と「新しい日常」のWebへのインパクト 今年、最大のWebパフォーマンスへのインパクトは、コロナ禍でした。 外出の自粛、在宅勤務への移行などにより、インターネットのトラフィックが急増し、インフラに対する大きな負荷となりました。 ネットスーパーやマスク販売のサイトは、急激なトラフィックによって遅延したり、アクセスできなくなったりしました。 アクセス数増大により遅延したり、エラーと遅延が発生したマスクの販売サイト 在宅勤務増加が齎したトラフィックの急増 xtech.nikkei.com xtech.nikkei.com www.zscaler.jp 各社がトラフィックの急増の要因を分析していますが、概ね、在宅勤務の増加によるSaaSの利用、オンライン会議の利用で見解は一致しているようです。 トラフィック急増で露呈したインフラが弱いサービス トラフィックの急増=Webサイトの遅延と、単純

    Webパフォーマンスの振り返り 2020 - Webパフォーマンスについて
    takehora
    takehora 2020/12/01
    WebパフォーマンスAdventカレンダーの第1日目分の投稿です。
  • Webパフォーマンスの振り返り 2019 - Webパフォーマンスについて

    2019年も、残り一カ月となりました。 今年もWebパフォーマンスのAdventカレンダーを今年も開催したので、その初日のエントリーとして、今年のWebパフォーマンスを振り返ります。 今年は法制面で、経産省が坦々と進めてきた制度整備が大きな目玉でした。 従って、法制度の話が中心です。 エンジニアは、技術だけではなく、関連する法制度もしっかりと理解しなければいけません。 品質保証前夜 ついに、2020年4月1日の改正民法債権法施行まで、4か月となりました。 未だに、改正民法債権法を知らない人は多く、施行後、それなりにトラブルが生じると予想されます。 今一度、改正民法債権法で、Webサイトに関連する箇所をおさらいしましょう。 契約不適合責任 今回の民法債権法改正で、大きく変わるのが、ドイツやフランス由来の大陸法から、英米法へ軸をシフトする点です。 今回の民法債権法の改正は、日がウィーン売買条

    Webパフォーマンスの振り返り 2019 - Webパフォーマンスについて
    takehora
    takehora 2019/12/02
    パフォーマンスチューニングって、技術者にとっては、技術の極みであり、そもそも難しい分野であり、だからこそ、皆さん、訳がわかならなくて、Google PageSpeed Insightsとか重宝してるわけでしょ?それじゃダメなのよ。
  • 「外形監視」という訳語の間違い - Webパフォーマンスについて

    要約 Synthetic Monitoringに「外形監視」という訳語を当てている方がいるのですが、Syntheticの意味は「外形」ではありません。 Syntheticは「合成」という意味です。 ですから、日語訳を付けるのであれば、「合成監視」です。 また、External Monitoringの訳語として、「外形監視」という訳語を当てて書いている人も見かけます。 正しくは、 Synthetic Monitoring ... 合成監視 External Monitoring ... 外部監視 です。 何故、Synthetic Monitoringは、「合成監視」なのでしょうか? その歴史と背景を解説します。 Synthetic Monitoringとは何か? Synthetic Monitoringとは、計測システムから、対象システムに対して能動的にアクセスして、性能や可用性に関するデ

    「外形監視」という訳語の間違い - Webパフォーマンスについて
    takehora
    takehora 2019/07/05
    用語の由来を無視した訳語を付けることの問題を書きました。
  • Webパフォーマンスの振り返り 2018 - Webパフォーマンスについて

    2018年も、残り一カ月となりました。 WebパフォーマンスのAdventカレンダーを今年も開催したので、その初日のエントリーとして(遅れているものの)、今年のWebパフォーマンスを振り返ります。 ベアメタル回帰 今年のWeb(に限らず)パフォーマンスで特徴的だったのは、ベアメタルへの回帰でしょう。 IT業界が長い方はご存じだとは思いますが、集中と分散、仮想と物理のサイクルは繰り返されて来ました。 今後も繰り返されるでしょう。 仮想化技術の宿命 クラウドコンピューティングの基礎となっているのは、仮想化技術です。 AWSをはじめとして、多くのクラウドコンピューティングのプラットフォームを提供している事業者は、コンピューティングリソース(計算能力)を塊として扱い、それを物理の枠を超えて、論理の単位で切り出す方法として、各種ハイパーバイザーをベースにした仮想化技術を用いています。 仮想化技術は、

    Webパフォーマンスの振り返り 2018 - Webパフォーマンスについて
    takehora
    takehora 2018/12/07
    遅くなりましたが、今年のWebパフォーマンスを振り返りました。
  • 「推測するな、計測せよ」のWebパフォーマンスにおける真の意味 - Webパフォーマンスについて

    ソフトウェア工学で著名なロバート・C・パイク氏のCプログラミングに関する覚書というものがあります。 ルール1: プログラムがどこで時間を消費することになるか知ることはできない。ボトルネックは驚くべき箇所で起こるものである。したがって、どこがボトルネックなのかをはっきりさせるまでは、推測を行ったり、スピードハックをしてはならない。 ルール2: 計測すべし。計測するまでは速度のための調整をしてはならない。コードの一部が残りを圧倒しないのであれば、なおさらである。 ルール3: 凝った(Fancy)アルゴリズムは nが小さいときには遅く、 nはしばしば小さい。凝ったアルゴリズムは大きな定数を持っている。nが頻繁に大きくなることがわかっていないなら、凝ってはいけない(nが大きくなるときでさえ、ルール2が最初に適用される)。 ルール4: 凝ったアルゴリズムはシンプルなそれよりバグを含みやすく、実装する

    「推測するな、計測せよ」のWebパフォーマンスにおける真の意味 - Webパフォーマンスについて
    takehora
    takehora 2018/09/23
    定常計測は、凄く大事なのよ。「正しく」やってる企業は、必ず業績が伸びます。
  • HTTP/2が速いという幻想 - Webパフォーマンスについて

    難しい話じゃないです。 皆さん、ご自分でChrome Developer Toolで簡単に確認できますから、やってみて下さい。 このブログでも、過去に統計分析をした結果は掲載したんですが、「盲信」はそうそう簡単には消えないようでして… takehora.hatenadiary.jp takehora.hatenadiary.jp 以下の図は、Chrome 63.0.3239.108での結果です。 CDNにFastlyでもAWS CloudFrontでも、どのCDNを使って実験して頂いても結構です。 CDNを使わずに、Webサーバ単体でも結構です。 同様の結果になります。 どちらもHTTPS通信です。 どちらも同じオリジン、同じファイル構成です。 HTTP/1.1は、Keep-Alive設定が入っています。 HTTP/1.1での配信 … Load Event 70ms HTTP/2での配信

    HTTP/2が速いという幻想 - Webパフォーマンスについて
    takehora
    takehora 2017/12/27
    まぁ、ご自身で検証してみて下さい。そうすれば分かります。
  • CMGについて(「2017年Computer Measurement Group AA Michelson Awardについて」の代わりに) - Webパフォーマンスについて

    例年であれば、既に発表されているのですが、今年はまだ発表されていないです。 ノミネーションも怪しかった。 今年は、誰もノミネーションすらされていないのかなぁ… 会員にも情報が来ないんですよ。 今年から、Computer Measurement Groupは規約の改訂があって、大きく組織変更や方針の変更がありました。 その影響かもしれないです。 しょうがないので、今回は、CMG(Computer Measurement Group)について紹介の記事を書きます。 CMGとは "What is CMG"(CMGとは)のページには、以下のように記載されています。 The Computer Measurement Group the most influential worldwide organization of enterprise computing professionals commi

    CMGについて(「2017年Computer Measurement Group AA Michelson Awardについて」の代わりに) - Webパフォーマンスについて
    takehora
    takehora 2017/12/03
    2017年のAA Michelson Awardの発表がまだなので、CMGについて紹介記事を書きました。
  • Webパフォーマンスの振り返り 2017 - Webパフォーマンスについて

    2017年も、残り一か月となりまして、WebパフォーマンスのAdventカレンダーがスタートしましたので、今年のWebパフォーマンスの動向を振り返ってみます。 Googleさん大活躍 今年は、Webパフォーマンス(表示速度)の認知が浸透した一年でした。 その大きな要因は、やっぱり、Googleさんの活動ですね。 昨年のQ4に、Googleの大口顧客向けに、パフォーマンスの重要性を、役員クラスに直接会って説くと共に、今年は更に裾野を広げて、パフォーマンスの重要性を説いて回って、かなり認知が広がったと思います。 Googleさんが顧客に配布している資料を拝見したのですが、三つの事が書かれています。 Webパフォーマンス(表示速度)は収益に大きな影響を及ぼす Webパフォーマンスを高速化しないと、オンライン広告の成果を最大化できない Webパフォーマンスは、オーガニック検索に影響がある その上で

    Webパフォーマンスの振り返り 2017 - Webパフォーマンスについて
    takehora
    takehora 2017/12/01
    Chrome Developer Toolは、プロファイリングツールであって、Webパフォーマンス計測ツールではないです。プロファイリングとWebパフォーマンス管理は別物です。
  • はてなブログを自分で出来る範疇で高速化してみる - Webパフォーマンスについて

    はてなブログの高速化について、はてなスターを外すと速くなるとか、色々話題になっています。 ユーザが手を入れられる範囲でどこまで高速化できるか、いつも私がやっている統計的品質管理のアプローチで、計測・分析・改善してみました。 デスクトップサイト計測 まずは、現状把握、Synthetic Monitoringです。 Synthetic Monitoringとは、実験計画法のフィッシャー三原則に則った、対象ページに介在して計測する手法です。 一ユーザとして、こちら側から、一定間隔で、対象ページにアクセスをして、表示速度に関するデータを取得します。 計測対象サイト takehora.hatenadiary.jp トップに乗っていた記事は、5.3MBあって、かなり重いです。 グラフ関係の画像を多用しているからですね。 計測条件 日の帯域保証型(100Mbps)光回線NTTとKDDI 計測ブラ

    はてなブログを自分で出来る範疇で高速化してみる - Webパフォーマンスについて
    takehora
    takehora 2017/07/18
    はてなブログの高速化や、はてなスターの遅延要因疑惑などが話題だったので、ユーザとしてどこまで高速化できるか、試してみました。
  • 三菱自動車の燃費偽装問題をとやかく言えないWebサイトパフォーマンスのデータ取扱い問題 - Webパフォーマンスについて

    三菱自動車の燃費偽装問題 朝日新聞デジタルに www.asahi.com という記事が掲載されています。三菱自動車の軽自動車「eKワゴン」「デイズ」の燃費のデータ偽装の経緯が書かれています。 偽装の詳細が明らかになったのは軽自動車「eKワゴン」と「デイズ」。日産自動車との合弁事業第1弾として燃費を一番の「売り」に開発が始まり、燃費試験データのとりまとめは子会社「三菱自動車エンジニアリング(MAE)」に委託した。 開発が始まった2011年2月時点の燃費目標は、燃料1リットル当たり26.4キロ。初期段階では、燃費算出の元データとなる、路面や空気との摩擦による「走行抵抗」は、前モデルの実測値から推定した値を使っていた。12年8月までに目標は4回引き上げられ、29.0キロになった。 実車試験で走行抵抗は小さくなるとの見通しに基づき、性能実験部長が同年9月の会議で「目標は達成」と報告。同年11月の実

    三菱自動車の燃費偽装問題をとやかく言えないWebサイトパフォーマンスのデータ取扱い問題 - Webパフォーマンスについて
    takehora
    takehora 2016/05/13
    今回の三菱自動車の燃費偽装問題もそうですが、品質について、全体的に軽視する傾向を感じるます。それが、現在のWebサイトの表示速度を気にしない傾向と何かリンクしているように思えます。
  • 1