みなさんこんにちは、サイバーエージェントでフロントエンドを中心に開発しています原(@herablog)です。 アメブロでは、2016年9月にフロントエンドをJavaベースのアプリから、node.js・Reactベースのアプリへとシステムの移行をおこないました。本記事では、その移行へといたる経緯やゴール、システム設計、その結果についてお伝えします。 リリース直後に気づいているツワモノな方もいらっしゃいました。 アメブロのSP版がReactのSSRでフルリニューアルしたのを観測した — hr (@hrloca) 2016年9月1日 システム移行へといたる経緯 2004年から始まり、日本国内で最大規模のブログサービスとなったアメブロは、システムの肥大化や多数の関係者が存在したことによるモジュール・導線の急増などの理由により、ページ表示スピードが遅くなり、ページビュー数にも明らかに影響を与えるよう

ISUCONに出場しました。 残念ながら予選落ちでした。 今、もう一度やってみれば、予選は突破できる気がします。（どのチームも思っているとは思いますが） なぜ予選落ちしたのか振り返りを行った結果とやってはいけないことがいくつかわかったので、 共有します。 皆さんは勝った方法やこうしておけばよかったって書いている人が多かったので、 逆に僕は確実に負けるためにやるべきことを共有します。 ※タイトルは完全に煽りです。 事前準備をしない チャットの作成をしない チームメンバーでのコミュニケーションできる環境は必須です。コミュニケーションを取りづらくするために チャットを作成しないようにしましょう。 GCPの使用準備をしない 今回のISUCONはGCPを使用しての出題だったのですが、GCEのインスタンスにログインできる状態を 作ってしまうと、時間のロスができないので、ログインできるまでの準備はやめと

Handling a tremendous amount of images with Fastly / Yamagoya Traverse 2020

前書き - インデックスの作成はなぜ開発者のタスクなのか インデックスの 内部構造 - インデックスは何に似ているか インデックス リーフノード - 二重連結リスト 検索 ツリー(Bツリー) - バランス木 遅いインデックス パートI - インデックスを遅くする2つの原因 where 句 - 検索のパフォーマンスを改善するためにインデックスを作成 等価 演算子 - 一致するキーの検索 プライマリキー - インデックスの使い方を確認 複合インデックス - 複数列に対するインデックス 遅いインデックス パートII - 前の問題点が再び 関数 - where句の 中での関数 大文字・小文字を区別する 検索 - UPPERと LOWER ユーザ定義 関数 - 関数インデックスの制限 インデックスの作り過ぎ - 冗長性の排除法 パラメータ化 クエリ - セキュリティとパフォーマンスのために 範囲 検

今日のことなんですが、運用しているWebサービスに集中したアクセスがあって繋がりづらい自体に陥ってしまいました（SSHすらも） psコマンドで確認したところhttpdプロセスがメモリをもりもり使っててメモリリーク（メモリリークとは違うけど、まあ今回はそう呼ぶ）していたようで、これはよくないとApacheのチューニングを行ったのでその内容を記事にしておきます。 なにをしたか httpdプロセスが立ち上がりすぎてメモリが溢れないよう、立ち上がるプロセス量を調整しました。 ↓この記事を参考にチューニングしました。 ・Apacheをデフォルト設定のままで使っていませんか？ Apacheに割り当て可能なメモリ量を調べる 参考記事では「OS起動直後にfreeコマンドを打てばわかるよ」というような事を言っていましたが、現在サービス運用中で再起動はしたくないので以下の方法で割り当て量を出しました。 a，V

FINDJOB! 終了のお知らせ 2023年9月29日にFINDJOB!を終了いたしました。 これまでFINDJOB!をご利用いただいた企業様、求職者様、様々なご関係者様。 大変長らくFINDJOB!をご愛顧いただき、誠にありがとうございました。 IT/Web系の仕事や求人がまだ広く普及していない頃にFind Job!をリリースしてから 約26年間、多くの方々に支えていただき、運営を続けてまいりました。 転職成功のお声、採用成功のお声など、嬉しい言葉もたくさんいただきました。 またFINDJOB!経由で入社された方が人事担当になり、 FINDJOB!を通じて、新たな人材に出会うことができたなど、 たくさんのご縁をつくることができたのではないかと思っております。 2023年9月29日をもって、FINDJOB!はその歴史の幕を下ろすこととなりましたが、 今後も、IT/Web業界やクリエイティブ

ランサーズでは、現在、Webエンジニアを募集しています。 詳しくは、募集要項をご覧下さい。 こんにちは、keiです。 今回は、MySQLのチューニングに大活躍な「Jet Profiler」というツールをご紹介します。 【2012/12/13 追記】 JetProfilerバージョン3がリリースされ、日本語対応しました。 この日本語化は、ランサーズ上で依頼されました。 http://www.lancers.jp/work/detail/69629 【追記ここまで】 Jet Profilerとは Jet Profilerは、MySQL向けのクエリアナライザです。 クエリチューニングは、DBパフォーマンスチューニングの中でも重要な作業の1つですが、 Jet Profilerを使えば、その作業をGUIで直感的に行うことができます。 フリーウェアの形態で提供されており、機能限定版であれば無料で利用す

sarとかvmstatとかiostatとかmpstatとか、 リソースステータスを見るコマンドを一定時間だけ実行し、 その結果を一気にグラフ化＆閲覧用HTMLを作成するツールをgithubに公開しました。 https://github.com/yushinhirano/resstat リアルタイムに見るのではなくて、ある期間だけグラフ画像で残す目的で使います。 たいていのLinux系のディストリビューションで動作します。 （テストしたのはRHEL系） こんな感じの出力になります。 インストール＆起動は本当に一瞬で終わります。 興味ある人は使ってみてください。（そしてフィードバックよろしくお願いします） 本当に簡単な使い方 sudo yum -y install zsh sysstat gnuplot expect git clone https://github.com/yushinhir

これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（システム編） こんにちは nob です。 前編　これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（クエリ編）　の記事から１年半が経過してしまいました。ちょっと長いお休みでしたが、その間に蓄えた MySQL パフォーマンス監視の実戦経験を（システム編）としてお届けいたします！ 今回の（システム編）で紹介するツボは 4 つです。（クエリ編）のツボに加えて、この4つに注目して頂ければ MySQL のパフォーマンス監視もバッチリです。 （ツボ１）Load Average < (1 + (cpu数-1)/3) （ツボ２）Checkpoint Age が水平線になったら要注意 （ツボ３）MyISAM は無いよね監視 （ツボ４）万能選手スローログ なお前編と同様この記事では監視ツールとして Cacti と Percona MySQL

UNIX系のOSで利用できるWebサーバの性能測定ツールといえば、Apache Benchやhttperfを思い浮かべる人が多いのではないでしょうか。これらの計測ツールは、残念ながら最近の高速なWebサーバを計測するには非力です。この記事では、高速なWebサーバにも負けないweighttpの使い方を紹介します。 weighttpとは何か weighttpは、Webサーバlighttpdの開発者が実装したWebサーバの性能測定ツールです。以下のような特徴を持ちます。 Webサーバのスループット（リクエスト毎秒）を測定できる ネイティブスレッドを複数起動し測定性能を向上できる libevを利用することで、モダンなポール・システムコールを利用する Apache Benchによく似たコマンドラインオプションを持つ 2.は Apache Benchやhttperfにはない機能です。ここが決定的に異な

声明: 这是一个非商业性、独立的私人网站，与任何其它方面无关。 Disclaimer: It is a non-profit, individual and private website, and has no relations with any other party. 一个好域名就抵挡得上十万将兵 梦想因拥有这个域名而伟大 试问这个域名能留人吗 当然，我们彼此信任与欣赏 抓住机遇，不经意的投资 或许是您一生最有意义的回报！

さてISUCON2も近づいていることですし、チューニングを題材に今実際にWEBアプリを作る中で行なっているチューニングの初歩について書いてみたいと思います。 まず、僕はものすごくMySQLに詳しいわけでもものすごくPerlやPHPに精通しているわけでもない、という前提があり、自分で考えたり少ないながらも経験したことをもとにしてチューニングを進めております。 その中で覚書的に、誰でもいますぐ出来る測定方法などを書いておこうかなーと思います。 チューニングにはものすごく大きく分けて2種類あります。 アプリケーションのチューニング インフラレイヤーのチューニング まずはこの2つが効果的なチューニングになります。 この中でもアプリケーションのチューニングのほうが絶大な効果をあげることが多い、とYAPCでfujiwaraさんがおっしゃっていました。 アプリケーションのチューニング ではWEBアプリケ

チューニングの基礎 それでは、具体的にInnoDBでどこをチューニングするべきかを見ていこう。 バッファプール 最も基本となるのがバッファサイズの調整だ。ワーキングセットが全てバッファに収まらない限り、バッファプールは大きければ大きいほど良い。その分ディスクアクセスが減るからだ。バッファサイズが小さいと、キャッシュミス時にディスクからReadするのに時間がかかり、I/Oがボトルネックになってしまう。予算のある限りメモリを目いっぱい搭載し、バッファプールに割り当てよう。InnoDBのバッファプールは、innodb_buffer_pool_sizeオプションで設定する。利用可能なメモリは、他の処理に必要な分を除いたすべてをInnoDBのバッファプールに割り当てよう。 innodb_buffer_pool=32G ここで一つ注意がある。innodb_buffer_pool_sizeはバッファプー

3. 今回の内容について •  本番環境でPHP使ってますか？ •  どうやって使ってますか？ •  金がないけど微妙に負荷がある環境とか 困るよね •  そんな感じ •  ソーシャルゲームみたいな超負荷の環境の 話はしません •  EC2の話もしません

弊社の一部のサービスでも絶賛活躍中のFusion-io社のioDrive。 Fusion-io ioDriveとFusion-io ioDrive Duoではどちらも、最小容量のモデルはSLC型、そのほかはMLC型を使っているが、Fusion ioDriveの読み込み速度は735〜770MB/s、書き込み速度は510〜750MB/sだ。Fusion ioDrive Duoに至っては、読み込み速度は1.0〜1.5GB/s、書き込み速度は一律1.5GB/sという数値をたたき出す。 ＠IT Special PR：Fusion-ioのクールな技術を使いこなせ！ 今日はデルさん主催の下記セミナーにて、このFusion-ioに関するDELL社の検証結果紹介や、DeNA松信さんによるMySQL環境でのFusion-io検証結果およびDeNAでの利用に関するお話が聞けるとのことだったので、途中からの参加で

WEBサイトに情報を入力するだけで負荷テストができるLoad Impact、GUIから操作できるApache JMeterや、コマンドラインから使うcurl-loader・httperf・Siege・Pylot・abを簡単な使い方と共に紹介していきます。 Load Impact http://loadimpact.com/ Load ImpactはスゥエーデンのGatorhole AB社が管理している、フォームに必要な情報を入力するだけで負荷テストをしてくれるWEBサイトです。 ツールをインストールしたりする必要が有りませんので、非常に楽です。 毎月5回まで無料で負荷テストができます。 それ以上は10回/$30のクレジットを購入する事になります。 トップページのフォームにURLを入れて「Run free test」をクリックすると、世界各地のいずれかのAmazon EC2サーバから負荷テス