タグ

関連タグで絞り込む (56)

タグの絞り込みを解除

チューニングに関するyamadarのブックマーク (94)

  • チューニング経験が無くてもパフォーマンス改善できる　SQL高速化の白熱ライブ


    世界中の技術者を対象に、最新技術の動向をシェアする﹃Oracle Code Tokyo﹄が2017年5月18日に行われました。普段DBAを指南しているディレクター・柴田 長氏が﹁Live Challenge!!SQLパフォーマンスの高速化の限界を目指せ！﹂というテーマで、デモンストレーションを実施。Oracle Database 12cの最新テクノロジーを駆使して、SQLの高速化を実演しながら説明しました。 しばちょう先生がSQL高速化に挑戦 柴田長氏‥みなさん、こんにちは。日本オラクルの柴田です。このセッションは﹁Live Challenge!!SQLパフォーマンスの高速化の限界を目指せ！﹂がテーマです。いかにSQLが高速化していくのかを体験してもらいたいと思っています。 改めまして、私は日本オラクルの柴田 長︵つかさ︶と申します。長という漢字が﹁つかさ﹂と読めないので、﹁しばちょう﹂と
    チューニング経験が無くてもパフォーマンス改善できる　SQL高速化の白熱ライブ

  • オプティマイザトレースによるちょっとディープな快適チューニング生活


    メリークリスマス！！今日はMySQL Casual Advent Calendar 2015の25日目をお届けするぞ！！ 前回のエントリでは、MySQL 5.7におけるオプティマイザの改良点や新機能についてのスライドを紹介した。MySQL 5.7のオプティマイザの良し悪しは、ぜひみなさんの手で確かめて頂きたい。ところで、オプティマイザといえばひとつ前のバージョンである、MySQL 5.6で追加されたオプティマイザトレースという機能がとても便利だ。使いこなせばクエリチューニングの強い味方になるので、ぜひまだ使ったことがないという方は、一度試してみて欲しい。本ブログではまだ紹介していなかったので、今日はその使い方と見方を紹介しようと思う。 オプティマイザトレースとは一体何か。ひとことで表せば、オプティマイザがどのような実行計画を検討・比較し、どの実行計画を選択したかということを、詳細に表示して
    オプティマイザトレースによるちょっとディープな快適チューニング生活

  • V8エンジンでのJavaScriptの機能と最適化コードの書き方に関する5つのベストプラクティス | POSTD


    数週間前に、JavaScriptが実際どのように動いているかを掘り下げて紹介する記事の連載を始めました。JavaScriptがどのような機能で構成されていてそれらがどのように組み合わさって機能していくのかを知ることによって、さらに良いコードやアプリケーションを作ることができるのではないかと思ったからです。 連載の1回目では 、エンジンやランタイム、コールスタックについての概要を紹介しました。2回目となる今回は、Google V8 JavaScriptエンジンについて細かく説明していきます。また、より良いJavaScriptコードの書き方、すなわち私たちの開発チーム SessionStack がプロダクトを開発する際に意識しているベストプラクティスについても併せて紹介します。 概要 JavaScriptエンジン とはJavaScriptコードを実行するプログラムまたはインタプリタのことです。
    V8エンジンでのJavaScriptの機能と最適化コードの書き方に関する5つのベストプラクティス | POSTD

  • なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策｜ハイクラス転職・求人情報サイト AMBI（アンビ）


    なぜ、SQLは重たくなるのか？──﹃SQLパフォーマンス詳解﹄の翻訳者が教える原因と対策 ﹃SQLパフォーマンス詳解﹄の翻訳者の松浦隼人さんに、8つの﹁SQLが重たくなる原因とその対策﹂を聞きました。システムのボトルネックになるような﹁問題のあるSQL﹂を回避するノウハウを学びましょう。 データの操作や定義をする言語﹁SQL﹂は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか？ そのノウハウを学ぶため、今回は﹃SQLパフォーマンス詳解﹄の翻訳者であり、自身もエンジニアでもある松浦隼人︵まつうら・はやと／@dblmkt︶さんに8つ
    なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策｜ハイクラス転職・求人情報サイト AMBI（アンビ）
    yamadar
    yamadar 2017/07/11
    ORMが荒ぶるのは、王蟲の怒りと呼んでる。王蟲の怒りは大地の怒りじゃ。
    リンク

  • MySQLのメモリー使用量を最適化する設定のベストプラクティス | Yakst


    Percona Data Performance Blogの翻訳。Percona CEOのPeter Zaitevによる、MySQLのメモリー使用量をどのように決めるべきか、またそれを決める時に気にするべきことは何かについてのまとめ。 この記事では、最適なMySQLのメモリー使用量を設定するためのベストプラクティスを扱おうと思います。 使用できるメモリーのリソースをどのように使うか正しく設定するのは、MySQLを最適なパフォーマンスでかつ安定して使うために最も重要なことのひとつです。MySQL 5.7では、デフォルトの設定では非常に少ない量のメモリしか使いません。デフォルトのままにしておくのは、最も良くないことのひとつでしょう。しかし、不適切に設定してしまうと、パフォーマンスを更に悪くする(あるいはクラッシュする)ことにもなりかねません。 MySQLのメモリ使用量を設定するにあたっての最初
    MySQLのメモリー使用量を最適化する設定のベストプラクティス | Yakst

  • CPU使用率100％のWebサーバをOSのチューニングだけでCPU使用率20%まで改善する - 人間とウェブの未来


    こんばんは、 @matsumotoryです。 hb.matsumoto-r.jp 上記エントリにおいて、プロセスの大量メモリ確保に伴うページテーブルサイズとベージテーブルエントリ数の肥大化によるcloneやexecveの性能劣化とCPU使用時間の専有問題、および、それらの解決方法についてシステムコールレベルで確認しました。 そこで今回は、システムコールやそのカーネル内部の処理の性能、というよりは、より実践的な環境であるApache httpdとmod_cgiを用いて、phpinfo()を実行するだけのCGIに対してベンチマークをかけた時にどれぐらいCPUのidleが空くか、システムCPUの使用量が変わるかを、前回示した解決方法の1つであるHugePagesを使うかどうかの観点で比較してみましょう。 特定条件下のWebサーバ環境のシステムCPUに起因する高負荷問題から、システムコールやカーネ
    CPU使用率100％のWebサーバをOSのチューニングだけでCPU使用率20%まで改善する - 人間とウェブの未来

  • PHP製のWebアプリが遅い場合の基本チェック6点 - ほんじゃらねっと


    先日別のチームから、 ﹁PHPで作成したWebアプリの速度が遅いので助けてくれー﹂ という相談を受けた。 対応したものの、結構時間がかかって面倒だったので、 今後こういった問題が起こった時に使えるよう、チェックリストをまとめてやった。 基本的な内容だけど、 このチェックリストの内容をやってみて、それでもダメなら相談しなさい、 と伝えておくことで相談を減らすフィルタとして働いてくれるはずだ。 PHPプロジェクトに限らず、バックエンドでデータベースを使用している Webアプリのプロジェクトなら試す価値のあるものが多いはず。 調査や対応方法の手軽さ順で並べるとこんな感じ: Webブラウザのデベロッパーツールでレスポンスを計測する Webサーバ(Apache)のリクエスト時間をログに出力する ログ解析ツールでURL毎の付随リクエスト数を確認する データベースのスロークエリログを出力する プロファイ
    PHP製のWebアプリが遅い場合の基本チェック6点 - ほんじゃらねっと
    yamadar
    yamadar 2016/03/11
    計測しないで思い当たる所をチューニングすると的はずれな可能性があるので、まず計測するのが基本。
    リンク

  • MySQLでクエリの実行時間を手っ取り早く計測する | きーたろう　QiitaAPIで検索しちゃう！

    yamadar
    yamadar 2015/07/22
    MySQLサーバー内のレスポンスタイムではなく、アプリケーション・サーバーから見たクエリの実測時間（ネットワーキング時間込み）を知る方法
    リンク

  • 5分で出来るMySQLのお手軽チューニング - わーくあうと！


    こちらのエントリーで書いているのですが、開発用のVPS鯖がメモリ使い過ぎで重くなっていて、mysqlに問題がありそうだったのでサクっと調整しました。 その手順を残しておきます。 MySQLのチューニング項目について説明 MySQLのメモリに関する設定項目はたくさんあります。 それぞれの項目に関しての詳しい情報は下記が参考になります。 http://trackback.blogsys.jp/livedoor/klab_gijutsu2/50860867 ただ、これらを全て把握するのは大変だと思うので、簡単に分類すると以下の2種類があります。 グローバルバッファ スレッドバッファ で、MySQLが使うメモリ量は下記になるわけです。 グローバルバッファ + ( スレッドバッファ * コネクション数 ) それらを踏まえた上で具体的なチューニングに入ります。 MySQLで使っているメモリ量を調べる
    5分で出来るMySQLのお手軽チューニング - わーくあうと！

  • シンプルでかつ最高のJavaScriptプロファイラ sjsp を作りました！ ― Webアプリケーションが複雑化する中でプロファイラに求められるものとは何か - プログラムモグモグ


    あらすじ Web技術が複雑になる中で、JavaScriptのプロファイリングをとる方法とは。 プロファイリングを取るためのコードを手で書いてみましょう。 とてもシンプルで、かつ最高のJavaScriptプロファイラ sjsp を作りました。 本当にあった怖い話 上司 ﹁とにかくJavaScriptのコードを速くしてくれ﹂ 私 ﹁分かりました、速くします﹂ (次の日) 私 ﹁いいプロファイラがないなら作ればいいじゃない﹂ 同じチームの人 ﹁えっ？﹂ 私 ﹁最高のJavaScriptプロファイラ作ったよ﹂ 同じチームの人 ﹁﹁えっえっ？？？﹂﹂ 私 ﹁早速使ってみたらこことここが遅いって分かったよ﹂ 同じチームの人 ﹁﹁﹁この子は一体…﹂﹂﹂ JavaScriptのプロファイリングの難しさ 近年、Webブラウザーの処理速度は著しく向上し、その可用性の高さから、アプリケーションのプラットフォーム
    シンプルでかつ最高のJavaScriptプロファイラ sjsp を作りました！ ― Webアプリケーションが複雑化する中でプロファイラに求められるものとは何か - プログラムモグモグ
    yamadar
    yamadar 2015/07/01
    最初の自画自賛はちょっと引いたけど、本論を読んだら素晴らしかった。実力が伴ってる。
    リンク

  • 実録MySQLのチューニング 春の陣 - （ひ）メモ


    long_query_time = 0.5 とか閾値を小さめにしてもスロークエリが出なくなったけど、CPU(user)使用率高いとか、なんか足引っ張ってるクエリがあるっぽいなぁという場合のお話です。 ﹁実録﹂の通り、現在絶賛進行中ですので、逐次動きがあったら書き足していくつもりです。 ﹁あれを見た方がいい﹂とか﹁これをあーした方がいい﹂とかあれば、コメントかTwitterで @hirose31 までお知らせいただけるとうれしいです！ 使用しているのは、MySQL 5.1.41 です。 前提: サーバーリソースのグラフ GangliaでもCactiでもMuninでもなんでもいいんですが、サーバリソースのグラフ化は必須です。チューニングした際の効果測定や、そろそろリソース食い潰してやばいとかの予測にも使えます。 自分はDBサーバの場合このあたりをグラフ化してます。 CPU使用率 (user,
    実録MySQLのチューニング 春の陣 - （ひ）メモ

  • 大人のためのInnoDBテーブルとの正しい付き合い方。


    InnoDB関連でよくある質問のひとつに﹁テーブルのメンテナンスは何をすればいいんですか？﹂というものがある。InnoDBはMySQL 5.5でデフォルトストレージエンジンとなるため、InnoDBのテーブルメンテナンス計画を立ようと思う機会も増えることだろう。そこで、今日はInnoDBのテーブルメンテナンスの各種方法となぜそうしなければいけないかという理由を解説しようと思う。 ANALYZE TABLEテーブルメンテナンスの代名詞といえば、インデックス統計情報の更新ではなかろうか。運用を続けるうちに、知らず知らずインデックス統計情報が狂ってしまい、思うような性能が出ない。RDBMSにはそのような問題がつきものであるが、InnoDBの場合、ANALYZE TABLEは不要である。なぜなら、InnoDBが自発的に統計情報を更新するからだ。InnoDBは以下の条件に適合すると、ANALYZE T
    大人のためのInnoDBテーブルとの正しい付き合い方。

  • MySQL　InnoDBストレージエンジンのチューニング（後編）


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

  • Redmineチューニングの実際と限界 - Redmine performance tuning

    Redmineチューニングの実際と限界(旧資料) - Redmine performance tuning(old), See Below.

    Redmineチューニングの実際と限界 - Redmine performance tuning

  • リアルな DOM はなぜ遅いのか - steps to phantasien


    これは VirtualDOM Advent Calendar 2014 に勝手に参加する記事です。 あたたかい春の昼下がりのこと、あるブラウザベンダの社内を不穏な噂が駆け巡った。 ﹁React.js なるライブラリ、どうも仮想 DOM というやつのせいで速いらしいぞ﹂ もうリアルな DOM はお役御免、ブラウザも商売上がったりか・・・。雇用に不安を覚える人(私)がいる一方、 そのアイデアをとりこんでブラウザの DOM を速く出来ないかと考える人たちもいた。 仮想 DOM はなぜ速いのか。誰かのつてを辿って React.js チームにおいでいただき、速さの秘密をテックトークしてもらう。 イミュータブルなデータ構造による単純化、非同期適用による処理のバッチ化、差分アルゴリズムによる副作用の最小化… いくつかのアイデアはブラウザからはどうにもならないが、たとえば非同期化なんかは形は違えどブラウザ

  • ALTER TABLEを上手に使いこなそう。


    テーブル定義を変更したい。インデックスが壊れてしまったので再作成したい。そんな場合はALTER TABLEを使う。ALTER TABLEはテーブル定義を変更するお馴染みのコマンドであるが、その挙動は意外と知られていない。︵エキスパートとおぼしき方々からも度々質問を受ける。︶そんなわけで、今日はALTER TABLEについて解説しようと思う。 まず結論から言うと、なんとMySQLのALTER TABLEはテーブルのデータを全てコピーし直すのである。なんて無駄なことを！？と思うかも知れないが、テーブル定義︵スキーマ︶の変更を動的に行うには、ストレージエンジンによるサポートが必要であり、動的なスキーマ変更をサポートしているストレージエンジンはまだ少ないのである。︵動的スキーマ変更をサポートしているのはMySQL Clusterぐらいだ。しかも追加だけ。︶デフォルトで利用出来るMyISAMはInn
    ALTER TABLEを上手に使いこなそう。

  • 個人向けCDN「CloudFlare」を試してみた

    今までの自宅サーバー高速化の取り組み このブログはWordPressを自宅サーバー（自作パソコン）で構築・配信しているのですが、今まで様々な高速化への取り組みやパフォーマンスチューニングを行って来ました。代表的なものでも以下のような対策を講じてきました。 サーバーのハードウェアのスペックアップ 自作パーツで、Core-i7 3770 HT8コア、メモリ32GB、SSD512GBで構成 PHPにAPC（アクセラレーター）を導入 php.iniもメモリ関連やAPC関連の設定を最適化 ApacheをやめてNginx1.2の最新版でPHP-FPMのリバースプロキシを構成 NginxからPHP-FPMへの接続をポート通信ではなくソケット通信に切り替え Nginxのプロキシキャシュの範囲を強化 キャッシュ対象を画像、JS、CSSにも適用。HTMLをGZIP圧縮してブラウザに送信 MySQL5.6の導入

    個人向けCDN「CloudFlare」を試してみた

  • フロントエンドチューニングの箇条殴り書き

    普段気をつけてるよリスト "モバイルで、WebViewとブラウザのコンパチで、特にセオリー化されていないデザインモジュールのなか、装飾画像もふんだんに使うぞ系サービス開発" の文脈における、パフォーマンス確保のため気をつけてるよリスト。 よく、パフォーマンス「向上」とか「確保」とか申しますが、メンテナンスコストなどと天秤にかけて、「必要十分」のラインを狙うのが重要だと思う次第。 画像リソース 画像リソースを揃えるときのセオリ。圧縮率とか最適化とか細かいチューニングはあれど、大雑把に下記を守る。そしてImage Optim（or 相当の処理）。 JPEGはプログレッシブで画質60くらい（オレ目安） PNGは差し支えない範囲で色数をきちんと削る 50px未満のサムネイルは@2.0xなリソースにしない 案外、Androidあわせの@1.5xや@1.0xでも大丈夫なことすらある GIFアニメを入れ

    フロントエンドチューニングの箇条殴り書き

  • (pdf) MySQLパフォーマンスチューニング概要 - Oracle


    <Insert Picture Here> MySQLパフォーマンスチューニング概要 日本オラクル MySQL Global Business Unit Copyright© 2011, Oracle. All rights reserved. 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。 また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことは できません。以下の事項は、マテリアルやコード、機能を提供することをコミットメン ト︵確約︶するものではないため、購買決定を行う際の判断材料になさらないで下さ い。オラクル製品に関して記載されている機能の開発、リリースおよび時期につい ては、弊社の裁量により決定されます。 OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文
    yamadar
    yamadar 2013/10/02
    MySQL5.5のパフォーマンスチューニングについて。
    リンク

  • モバイルブラウザでもサクサクに動作する最適化6つのノウハウ


    ﹁Webサイト・アプリ高速化テクニック徹底解説﹂第8回は、モバイルブラウザに向けた最適化について紹介します。 モバイル端末はPCに比べ、CPUやネットワークなどの性能面で劣ることからボトルネックの影響が出やすく、またゲーム開発など突き詰めたチューニングを行う場面では、特殊なノウハウも必要になります。 しかしきちんと最適化を行えば、その効果もその分著しく、比較的低スペックな端末や3G回線であっても、サクサク軽量なサービス提供が可能です。今回の記事では、その勘所をお伝えしたいと思います。 1. ボトルネックを取り除く まずはやってしまいがちなボトルネックの事例について、挙げていきたいと思います。前述のようにモバイル端末では、その性能からPCよりも顕著に、未最適化箇所が体感に影響を及ぼします。 仕事がらそこそこの数のアプリケーションを見てきましたが、モバイル向けに特化したチューニングができていな
    モバイルブラウザでもサクサクに動作する最適化6つのノウハウ
    yamadar
    yamadar 2013/09/25
    JS、キャッシュ、リクエスト数。
    リンク
  • 前のページ 1 2 3 4 5 次のページ

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.