Devsの常識、DBAは非常識AIとAWSで現世から離れる試み-仕事がちょっと大変な時もあったりするから�俺のかわりにAIにシステム作ってもらえるシステム作った話.pptxJun Suzuki
ニコ動 超チューニング祭で最優秀賞もらいました
ニコニコ超会議で開催された「超チューニング祭り」に恋人である武藤スナイパーカスタムからお誘いされて参加しました。 投票してくださった方々のおかげで最優秀賞！ ありがとうございます！ ニコ動モバイル版のトップページのhtml,css,jsを軽量化するお祭りでして、にぎやかな会場、狭いブースの中で詰め込まれておもしろかったです。 チーム：ウルフギャングの紹介 エンジニア、デザイナーのバランスチーム。 武藤さんが狼が好きなのでそれっぽい名前にしました。ギャングらしくふたりとも革ジャン装備。 武藤スナイパーカスタム Twitter : tai2 コンピューターグラフィックスとPythonをこよなく愛すマッチ棒エンジニア。 イシジマミキ Twitter : woopsdez 写真をアップするたびにおおつねさんに「太った？」と言われる番付上昇中のデザイナー 他はエンジニアふたり、個人での参加などが
YappoLogs: なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか
なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか ここ最近の大規模サービス関連したデータページング考です。 mysql 5.5.34 で試して記事書いてます。 bigdata テーブルは id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, PRIMARY KEY (id) なカラムがある前提です。もちろん InnoDB です。 2014年なんだからCOUNT(*)とかSQL_CALC_FOUND_ROWSとかLIMIT OFFSETのページングはやめようぜ - Togetterまとめが発端にみえるけど、わりと昔から話されてる事なんだけど、「nippondanji SQL_CALC_FOUND_ROWS」でググっても有用な情報ないし文書化されてないからしとく。 ページング処理で使われがちな機能です。 S
Webアプリのパフォーマンス改善をWeb標準で行う方法、まとめ - ふろしき Blog
「HTML5 Advent Calendar 2013」の24日目の記事です。 Webアプリのパフォーマンス改善と言えば、JavaScriptやDOMアクセスなど、既存の技術ベースな改善手法を想像する方も多いでしょう。最近では、こうした改善のあり方を、別の視点からもう少し広げようというアイデアが存在感を持ち始めています。それは「Web標準」です。 そこで今回、Web標準側でできるWebアプリのパフォーマンス改善について、掻い摘んで紹介します。全てを説明となるとキリがないので、キーワードを中心とさせて頂きます。最近になって、結構実用化が進んできているので、悩んだ時には試してみる価値はあるでしょう。 1. リソースを先に読み込む linkタグにてURLなどを指定することで、これから先に読み込ませる可能性が高いWebページのリソースを予め読み込むWeb標準があります。ニュースサイトでは次のページ
PHPのジェネレータはイテレータより速い - hnwの日記
先日の記事「PHPのジェネレータの実装を調べてみた」で僕は次のように書きました。 GeneratorクラスはIteratorインターフェースを実装しており、対応するPHPメソッドを持っています。また、Cで実装した場合のみ指定できるイテレータ関数も実装しています。このように両方が指定されている場合、foreachループではCの関数が呼ばれ、イテレータメソッドを明示的に指定した場合はPHPメソッドの方が呼ばれます。 ところで、イテレータに対応するPHPメソッドとC関数となぜ2つとも実装する必要があるのでしょうか。実は、PHPメソッドの方だけ実装すれば正常に動作します。C関数を実装する理由は速度面のメリットからだというのが僕の理解です。C関数は関数ポインタで単に呼び出せるのに対し、PHPメソッドの呼び出しは命令実行器の状態保存・復元の必要があるなど、呼び出しのコストがやや高いのです。 PHPのジ
isucon3本戦いってきた＆勝ってきた！ #isucon - たごもりすメモ
isucon3の本戦にLINE選抜チームとして出た。ガッカリな感じだった予選時の状況はこちら。 isucon3予選参戦の記録 - tagomorisのメモ置き場 引き続き @kazeburo @sugyan @tagomoris の3人チーム。 ざっくりまとめ みんなこれまでこんな楽しいイベントに参加してたのか！ ずるい！！！！！！ 普段やってることを普段通りやる、と思っていたが焦って普段やらないようなミスを次々連発、社会は厳しい 思いきった構成変更とかできるのがisuconでしょｗｗｗｗ とかドヤ顔していたが、やりきれた。ドヤッ。 これからisuconという名前を口にするときに堂々とドヤ顔しようと思います。嘘です。元出題者のくせに成績出ないとかｗｗｗみたいにならなくて本当に安心しました。終わったあとのビールおいしかったです。 ということで、勝ちました。優勝と、あと僅差で特別賞もいただきま
PHPカンファレンス2013でpixivのインフラについて発表してきました - pixiv engineering blog
去年と比べて体重を8kb・・・間違えました8kg落としたbokkoです。目標体重まであとさらに8kgとなりました。道は険しく遠いです。 先週末の9/14(土)に東京都大田区産業プラザ(PiO)にて開催されたPHPカンファレンス2013にスピーカーとして参加してきました。以下はその資料になります。 inside pixiv’s infrastructure〜application cluster side〜 やや駆け足でしたが、トークではpixivの開発体制、アプリケーション基盤でのPHPの使われ方、データストア・キャッシュ戦略、 pixiv内部で利用されているRESTful APIの仕組みについてお話させていただきました。 今回は「application cluster side」ということでアプリケーション基盤の話がメインでしたが、 機会があれば「contents delivery cl
サイト速度とonload再考 | ゆっくりと…
単にウケ狙いなら「革新的！GAのページ平均読み込み時間を劇的に速くする方法」とか「もう3rdパーティーに邪魔させない、超高速スクリプト読み込み術」（笑）とかの煽りタイトルを付けるところですが、今回はもっと本質的なことを論じてみたいと思います。 「プログレッシブレンダリングでUXを向上させるJS非同期読み込みのベストプラクティス」では、スクリプトの読み込みと実行を window.onload 対象から切り離し、見た目のページ速度を速くする方法について書きました。この方法は既存のスクリプトを書き換える必要があるため、Stoyan Stefanov によって 実験的に実装された Facebook SDK か、自前のスクリプトにしか適用できませんでした。 しかし今回、Hatena や Twitter、Pocket、Disqus など、他の 3rd パーティ製スクリプトにも適用できる方法 − “進化
HTTPリクエストを減らすために【序章】HTTPリクエストは甘え - MOL
このシリーズはHTTPリクエストの理解を通じてWebパフォーマンスの重要性について考える5章構成になっている。 【序章】HTTPリクエストは甘え 【CSS Sprite編】スプライト地獄からの解放 【WebFont編】ドラッグ＆ドロップしてコマンド叩いてウェーイ 【DataURI編】遅延ロードでレンダリングブロックを回避 【終章】我々には1000msの猶予しか残されていない 1日目は、HTTPリクエストの概要について説明する。 例えに、私のポートフォリオページ（t32k.me）が表示されるまでの流れを見ていく。まず、検索からでも方法はなんでもよいが、ブラウザのURLバーにt32k.meと打ち込んでアクセスする。そのページを見にいくということは、つまりt32k.meに対してHTTPスキームでリクエストするということを意味している。 クライアントであるブラウザは入力されたURLを判断して、リソ
ユーザーの体感速度を高めるためのJavaScriptチューニング（前編）
連載「Webサイト・アプリ高速化テクニック徹底解説」第2回は、JavaScriptの高速化について、まずは前編、後編に渡ってユーザーの体感速度を向上させるための方法を紹介します。JavaScriptの同期・非同期の仕組みやscript要素のasync属性、defer属性について詳しく解説します。 今回から複数回に分けて、JavaScriptの高速化をテーマに解説していきます。まずは、ユーザーの体感速度を高めるためのJavaScriptチューニングということで、単純なJavaScriptの構文によるスピードを比較するようなものではなく、主にユーザー視点からの高速化を主眼に解説します。その中で、同期・非同期といったJavaScriptの仕組みやscript要素のasync属性、defer属性などについても触れていきます。 ユーザーの体感速度を向上させる 一概にJavaScriptの高速化といっ
ScaleOut | Supership
2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。
HTML5 CanvasとCSS3のスマホブラウザでの描画性能 - ICS MEDIA
スマートフォンのブラウザでどの程度のグラフィック表現が可能なのか、性能が気になりませんか？ 近年、HTML5を利用できる分野はウェブサイトのみならず、ゲームやSPA（シングルページアプリケーション）など多岐に渡っています。そこで、本記事ではiOSやAndroidの新旧さまざまな端末を使ってパフォーマンスを検証。記事の前半では描画性能を、後半ではJavaScriptの計算性能を測定しています。 描画性能の検証ビデオをご覧ください さまざまな端末を使って、描画検証の様子を録画しました。この80秒の動画では画像のオブジェクトの表示可能な個数を測定しています。ビデオの後半が見どころで、iPhone 5のパフォーマンスが良すぎてビデオを早送りするほどスコアがでるまで時間がかかっています。 さまざまな端末のスコアを測定しました 次の表に、2012年までに発売されたスマートフォンのスコアを掲載しました。
HTML5開発者必見、最速のJavaScriptライブラリはどれだ!? パフォーマンスの徹底検証 | ICS MEDIA
HTML5で2次元のインタラクティブコンテンツを制作するには、さまざまなJavaScriptライブラリがあります。どれを選択するべきか迷いどころではないでしょうか？ そこで今回はHTML5の各種JavaScriptライブラリについて、パフォーマンスを比較検証してみました。 今回検証したフレームワーク メジャーなJavaScirptライブラリとして次の5種類でテストしました。バージョンは2013年4月10日現在の最新版を使っています。詳しい検証方法は記事の後半にまとめています。 CreateJS (EaselJS 0.6.0) Arctic.js (v0.1.11) enchant.js (v0.6.3-48) Pixi.js (v1.0.0) Processing.js (v1.4.1) 各種JavaScirptライブラリのベンチマーク結果 ※グラフの数値が高いほどパフォーマンスが高いこと
最低2秒、目指すは1秒以内。ウェブサイトを高速化するためのTIPS at #SMX Advanced Seattle 2012
[対象: 上級] ページの表示速度が、Googleのランキングを決める指標として日本を含むインターナショナルで導入されていることがSMX Advanced Seattle 2012で判明しました。 そこで今日は、ウェブページの高速化を取り扱ったセッションをレポートします。 スピーカーは、ECサイトのREIでSEOに携わるJonathon Colman（ジョナサン・コールマン）氏です。 ウェブサイトのパフォーマンス最適化 サイトを高速化する理由 コンバージョン率の最適化 カスタマーエクスペリエンスとカスタマー満足度の向上 直帰率を下げる。 競争率が非常に激しいキーワードでオーガニックからのトラフィックを増やす。 全体的な競争力を高める。 運用費を節約する。 数字で見るページスピード Googleではページスピードが検索の1%に影響している。 ユーザーがページ表示に待てるのは2秒まで。 3秒以
［1］画面表示に10秒もかかる
大規模サイトの性能改善作業とは、どういうものなのか。リクルートの中古車情報サイト「カーセンサーnet」を全面リニューアルした体験を基に、その実態をレポートする。新システムはオープン2カ月前の時点で、目標性能に遠く及ばないことが判明。最終的に、Linuxカーネルのある処理方式が性能劣化の原因だと分かった。 「ブラウザーの表示に10秒もかかる。処理できるアクセス件数も全然足りない。これでは話にならない」――。 2010年夏。中古車情報サイト「カーセンサーnet」の全面リニューアルで、性能検証を担当していた私はあぜんとした。リニューアルオープンを間近に控えながら、新システムの性能が遅すぎることが判明したのだ。 そこから私の2カ月にわたる苦闘が始まった。検証作業は連日深夜まで続き、性能試験の実施回数は約100回に及んだ。その中で、性能が出ない理由が一つひとつ判明していった。ファイル共有システム「N
SHOW FULL PROCESSLIST を使った MySQL のプロファイリング : DSAS開発者の部屋
KLab Advent Calendar 2011 「DSAS for Social を支える技術」の3日目は、 引き続き MySQL 周りのチューニングノウハウとして、すぐに役立つ プロファイリング方法を紹介します。 DBサーバーの負荷が高い時、 slow_log を見て問題になっている重いクエリを 発見するのが一般的かもしれませんが、 slow_log に一切ログが残らないのに 負荷が高い状況や、むしろ負荷が高すぎてごく一般的でどう考えても遅いはずが ないクエリ ("SET NAMES utf8" や "BEGIN") すら slow_log に大量に乗ってしまう場合が あります。 slow_log 以外で問題になっているクエリを見つける方法として、 "SHOW FULL PROCESSLIST" コマンドがあります。これを数回〜数十回叩いてみて、 よく出ているクエリは、遅かったり量が
hamano's gist: 第2回 Tuningathon チューニングメモ
tuningathon2_memo.txt �ف��U #���U # 第2回 Tuningathon チューニングメモ このメモは @hamano が [第2回 Tuningathon][1] に参加した際に行ったチュー ニングポイントと感想です。 [1]: http://www.zusaar.com/event/agZ6dXNhYXJyDQsSBUV2ZW50GLmFBgw "第2弾！いろいろチューニングしてパフォーマンスを競うバトルイベント開催！「Tuningathon」2!! #tuningathon" 今回のお題は MediaWiki への参照性能という事でまたPHPか! とは思いました が2台構成可、Web Serverの入れ替え可、という条件でしたのでチューニングの 範囲が大きく広がった様に感じました。 ただ、この程度の平行数ではapacheをその他実装に置き換えた所で大した
チューニンガソン2で2位でした : DSAS開発者の部屋
10/1(土)にチューニンガソン2 というイベントに参加してきました。 もちろん前回に引き続き優勝を 目指していたのですが、今回は残念ながら2位でした。 今回もどんなチューニングをしていたのかの記録を公開します。 （ちなみに優勝したのは元KLabの濱野さんで、同じく メモを公開されています。） 今回のチューニンガソンのお題は、 Wikipedia の高速化で、 MediaWiki と Wikipedia の データが入った MySQL のデータには修正を加えずに、ランダムな100ページの表示速度を競いました。 マシンはメモリ1GBでデュアルコアのものが2台で、今回はWebサーバーの部分は自由に構成できます。 1. ボトルネックの確認 とりあえず AMI Linux の標準の php + apc で計測したところ、1ページの表示に1秒くらい使っています。 またphpか！ということで、やっぱり
例えば GC を止める・Ruby ウェブアプリケーションの高速化 - 2nd life (移転しました)
最近クックパッドでは、アプリケーションサーバの大半が Rails 2.3 から Rails 3 に置き換わったのですが*1、リリース前のベンチマークの時点ではあまりパフォーマンスが出ず四苦八苦していました。具体的には Rails 2.3 の時と比べ MRI 1.8.7 だとレスポンスタムが200%ぐらい遅い結果でした。Rails 3 になって実装が Merb core を取り入れ疎結合で綺麗になった反面、より多くのオブジェクトと・メモリを利用する様になった影響かと思います。 そこで Ruby インタプリタの変更*2を行い検証をしたところ MRI 1.8.7 (Rails 2.3と比べ) 約200%遅い MRI 1.8.7 -> Ruby Enterprise Edition 1.8.7 2011.03 (tcmalloc 無効) 約180%低速 MRI 1.8.7 -> Ruby Ente
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
実践・ウェブアプリ高速化テクニック#Chrome+HTML5 Conference