Twitter見てたら、以下のツイートを見た。 数時間後、dev.toと阿部寛のホームページどっちが速いですか？というブログがTLに現れた。 GoogleのPageSpeed Insightsで測って阿部寛のホームページの方が早かったという結論付けてよいのかという疑問が浮かび、webpagetest.orgで計測することにした。 設定 阿部寛のホームページに関しては、Tokyoリージョンにあるものとする。 そして、dev.toはNY発らしいので、サーバーの設定をNYにして測定する。 The platform was created in 2016. The twitter account, @ThePraticalWeb 評価結果 Webpagetest - 阿部寛のホームページ Webpagetest - dev.to 阿部寛のホームページ サーバーからのレスポンスの圧縮がされておらず、
日本経済新聞は国内を代表する経済誌だ。その電子版はwebでの継続課金を大成功させ、いまや50万以上の有料会員を擁するモンスターサイトだ。 その日経電子版が11月6日に全面リニューアルしたのだが、公開後、web業界がにわかにざわついた。表示速度が爆速だったのだ。日経公式もモバイルで2倍の表示速度を達成したと堂々と宣言していた。 webサービスは継続率こそ神KPIで、その継続率には速度が大きく影響する。 これはチェキらないとヤバイと感じ、友人のkitakさんとスピードの秘密を調査してみた。 Fastlyをコンテンツキャッシュに使う殆どのデータはFastlyを経由して取得されていた。Fastlyは最近注目を集めているCDN（世界中にエッジサーバーを配置し、高速にコンテンツを配信するサービス）で、非常に高機能でユニークなサービスだ。 一般に、CDNはいったん世界中にコンテンツをばらまくと、それを無
「爆速すぎて笑う」「速すぎて逆に不安になるレベル」――「dev.to」という米国のWebサイトの表示速度が異常に速いと、ネット上で話題だ。なぜ速いのか、サイト創設者のベン・ハルパーンさんがサイト内の記事で説明している。 2016年にオープンしたdev.toは、プログラマーが情報を交換したり、議論したりできるコミュニティーサイト。トップページにはユーザーが投稿したブログ記事のタイトルやコメントが、SNSのタイムラインのように並んでいる。このトップページの表示にかかる時間、各記事をクリックしたときのページ遷移が“一瞬”なのだ。 なぜ速いのか。ハルパーンさんが17年2月に投稿したブログ記事によれば、米Fastlyが提供するCDN（Content Delivery Network）を活用している。CDNは世界中にキャッシュサーバを分散配置し、ユーザーごとに最も（ネットワーク的に）近いサーバにキャッ
5，インラインイメージのメリット・デメリットと注意点 5.1，メリット インラインイメージを使うことで画像自体のHTTPリクエストが発生しません。 例えばファイルサイズの小さな10個の画像を読み込んでいるとします。それらすべてをインラインイメージ化することで10回のHTTPリクエストを削減できます。 データサイズが37％増加するというデメリットはありますが変換前のデータが数MBでもない限りHTTPリクエストが減らせることの方が有益です。 5.2，デメリット IEの古いバージョンでは使えない Base64エンコードによりデータサイズが約37％増加する HTMLやCSSに直接埋め込むため画像を変える度に差し替えが必要（ツールで改善可能） data URI schemeで埋め込まれたデータはキャッシュされない 同じデータを複数箇所に表示したい場合、それぞれの場所に埋め込む必要があるためインライン
今回はオールアバウトのnnmrが弊社サイトAll About Japanの速度を高速化した経緯についてまとめます。 All About Japanとは そもそもAll About Japan（以下AAJ）とは何かといいますと、弊社が提供している訪日外国人向けの日本紹介サイトです。 外国人向けサイトで、英語、中国語（繁体字）、中国語（簡体字）、タイ語、韓国語の5か国語に対応しております。 「Anime」「Izakaya」「Ninja」といったような特集や、実際に観光する人向けのモデルルート記事が特色です。 ■ 特集 (url : http://allabout-japan.com/en/tag/sushi/ ) ■ モデルルート記事 (url : http://allabout-japan.com/en/article/222/ ) 技術的な紹介 LAMP環境です。 （サーバー構成は後に記述
こんばんは、 @matsumotoryです。 hb.matsumoto-r.jp 上記エントリにおいて、プロセスの大量メモリ確保に伴うページテーブルサイズとベージテーブルエントリ数の肥大化によるcloneやexecveの性能劣化とCPU使用時間の専有問題、および、それらの解決方法についてシステムコールレベルで確認しました。 そこで今回は、システムコールやそのカーネル内部の処理の性能、というよりは、より実践的な環境であるApache httpdとmod_cgiを用いて、phpinfo()を実行するだけのCGIに対してベンチマークをかけた時にどれぐらいCPUのidleが空くか、システムCPUの使用量が変わるかを、前回示した解決方法の1つであるHugePagesを使うかどうかの観点で比較してみましょう。 特定条件下のWebサーバ環境のシステムCPUに起因する高負荷問題から、システムコールやカーネ
圧倒的なコスパを実現した13.3型モバイルノート「ZENBOOK UX305FA」 ASUSTeK Computerが2015年PC春モデルとして投入した新製品群の中で、目玉はキーボード着脱式のモバイルノート新鋭機「ASUS TransBook T300 Chi」だ。 中国語で「氣」を意味する「Chi（チー）」の名前からも分かるように、アップルのMacBook AirやiPad Airの“Air”を強く意識した製品である。CPUにCore Mを採用し、ファンレス設計の薄型ボディに搭載された12.5型液晶（2560×1440ピクセル）は、キーボードを取り外すことでそのまま高性能なWindowsタブレットとしても活用できる。 このTransBook Chiの影に隠れがちだが、もともとMacBook Air対抗として投入されてきた「ZENBOOK」シリーズもCore Mベースのシステムに刷新され
1. Chrome Developer Tools を 使いこなそう！ 2013/04/02 Google Developers Live Japan #3 このスライドを使ったセッションはこちら → http://bit.ly/YYtStr Toru Yoshikawa (@yoshikawa_̲t) 2. Who? 吉川 徹 / Toru Yoshikawa @yoshikawa_̲t Google Developer Experts (Chrome) html5j/HTML5とか勉強会スタッフ Web先端味⾒見見部 顧問 ⽇日本jQuery Mobileユーザー会 管理理⼈人 Sublime Text 2 Japan Users Group 管理理⼈人 allWebクリエイター塾/jQuery Mobile担当講師 Blog:
The best of CES 2025Presenting our 12 finalists, plus the winner of our best in show award.
甲子園名物「ブラスバンド」の応援――演奏曲の「著作権」は問題にならないのか？ 弁護士ドットコム 8月21日(木)12時11分配信 阪神甲子園球場で開かれ、連日盛り上がりを見せている全国高校野球選手権大会。今年も高校球児達のはつらつとしたプレーに日本列島が沸いている。 その熱闘を一層盛り上げるのが、応援ブラスバンドの存在だ。応援団が吹き鳴らすトランペットやホルンの演奏を楽しみにしているファンもいるだろう。『狙いうち』のような定番から、大ヒット映画『アナと雪の女王』の主題歌まで、さまざまな曲が演奏されている。 ただ、こうしたファンの中には「曲の著作権」を気にする人もいるようだ。ツイッターでも、「甲子園のブラバンは著作権使用料を払ってんのかな？」「さすがに甲子園の演奏は問題にならないのかな」などとつぶやいている人がいた。甲子園のブラスバンドで音楽を演奏するためには、著作権者の許可が必要なのだ
asm.jsを手書きしつつフィボナッチで速度比較をしてみる
asm.jsを触ってみたので所感など。 asm.jsはJavaScriptのサブセットで、限られた型しか使えないが高速に動作する言語との事。とりあえずどの程度速くなるのか、計算量が多くなるfibonacciの実装で試してみた。参考資料はasm.jsの仕様ぐらいしか無かったのでこれを見ながら。 で、実際に書いてみると型がゆるゆるなJavaScriptのイメージは脆くも崩れ去り、厳格な型チェックの世界である事がわかった。コンパイル言語を書いている時の頭に切り換えないと、コンパイルエラーと延々格闘する事になる。まずはasm.jsのコードは次の形式で、module exportする。 function create_my_asm_module(stdlib, foreign, heap) { "use asm"; function hoge() {...} function fuga() {...
12月2 Emscripten によって生成された asm.js 対応コードは本当に人間が書いたコードより速いのか？ はじめに 先日、いつものように Twitter 監視業務に勤しんでいたところ、下記のような発言を見かけました。 asm.jsは対応してないブラウザでは読めないし遅いって説明をされることが多いけど、ams.jsはJavaScriptの中で高速実行可能なものだけを使って更に少し制約を加えて底上げをしてるものなので、多のブラウザであっても普通に人間が書いたコードよりも速いっすよ— dynamis (でゅなみす) (@dynamitter) 2013, 11月 29 なるほど、機械によって生成された asm.js 対応のコードはどんなブラウザでも速いよという主張です。 自分は JavaScript で高速に動作するように注意して書いた zlib.js というのを作っていたので、zl
仏L'Expansion紙は、Googleがアンドロイド端末のパフォーマンス向上アプリdroidBoosterを開発するフランス企業FlexyCoreを買収したと報じています。 Google a racheté la start-up française FlexyCore - LExpansion.com http://lexpansion.lexpress.fr/high-tech/google-a-rachete-la-start-up-francaise-flexycore_408510.html Google buys Flexycore, creator of a “10x speed boost” app for Android | Ars Technica http://arstechnica.com/gadgets/2013/10/google-buys-flexycor
9. 問題の実装 9 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 <?php class BlackListDB { const DBPATH = "/tmp/db.gdbm"; public function isBlock($id) { $dbh = dba_open(self::DBPATH, "r", "gdbm"); if ($dbh === false) { return null; } $ret = dba_exists($id, $dbh); dba_close($dbh); return $ret; } } 10. 問題点 10 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 <?php class BlackListDB { const DBPATH = "/tmp/db.gdbm"; publ
金融系でFPGAというとHFTへの応用が知られてるけど、この事例はリアルタイムトレードの話ではない。金融業務で必要とされるバッチ処理やHPC（High Performance Computing）でもFPGAが本格的に使われ始めてるという話だ。 元ネタは、2011年にJP Morgan Chaseの人がスタンフォード大学で講演した内容。このビデオを見ていたらとっっっても面白かったので、 #fpgax 第3回で使う資料として要点を訳し、俺のコメントや補足を追加してみた。 http://www.youtube.com/watch?v=9NqX1ETADn0 （スライドはこちら） なお、FPGAも金融も素人なので、勘違いや誤訳があるかもしれない。FPGAとは何かよく知らない人はこちらをどうぞ。 リーマン・ショック対策のスパコン開発 JP Morgan Chaseは、社債やモーゲージ（不動産を担保
いつの時代もより高速に動作するフレームワークや言語に対する関心は高いものですが、そんな疑問に答える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
先日、会社で使っている自端末がリース切れと言うことで新しい端末になりました。新しい端末になると毎度のコトながら不要アプリが一掃できてシンプルな環境に戻るし、CPU とかも新しくなって軽快快適な動作に１日ほどは酔いしれる。 ・・・はずなのですが、どうにも不定期（定期的？）にPCがプチフリーズしてしまって、すんごく使い勝手が悪いんです。これがあの有名な SSD プチフリーズかっ！って思いたくなりますが、普通に HDD を使っているので SSD プチフリってわけではありません。ちょいと悩みつつ、だましだまし使ってきたのですが、３日でキレました。（￣^￣）凸 こういうときには、Process Explorer ってのを使って動作を監視していれば、悪さをしているプロセスの判別ができるんです。で見てみました。 なんですかっ？この定期的な I/O ピークはっ！プロセスは jqs.exe ってやつみたいで
Twitterがフロントエンドのアーキテクチャを見直し、Webページの読み込み速度を改善したことをブログで明らかにしています。 新しいアーキテクチャでは、これまでWebブラウザ上でJavaScriptの処理によって行ってきたWebページのレンダリングを見直し、サーバ側でレンダリング済みのHTMLページを送信し表示することにしています。これによってWebページの読み込みから最初のツイートの表示までの時間が大幅に短縮されることになりました。 When we shipped #NewTwitter in September 2010, we built it around a web application architecture that pushed all of the UI rendering and logic to JavaScript running on our users’
先日、SSDを換装したノートパソコン。 期待された（？）プチフリーズはほとんど発生せず、快調に使えていたわけですが…。 それでは面白くもなんともないので、ここは一発、無理くりにでもプチフリーズを発生させるべく、いろいろやってみることにしました。 で、タイトルにも書きましたが、 SSDにもデフラグは要ります！！ってか必須です！！でも条件付。 実際、別のサイトの実験結果（こちらの方がしっかり書かれてます）でもそういう結論は出てましたが、今回はたまたま別方向で検証してみた結果を書いておきます。 ----- たまたま、もともとのハードディスクの断片化状態は悪くなかったので、結果的にはいい状態で、快調ではありました。 じゃ、ここはいっちょ、わざと断片化させてみますかね。 その昔、「デデフラグ」という、ハードディスクをムリヤリ断片化させるソフトがあったのを思い出してぐぐってみましたら…ありました。 デ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
