タグ

パフォーマンスに関するlax34のブックマーク (37)

  • Aurora Serverless v2 でのパフォーマンスとスケーリング - Amazon Aurora

    以下の手順と例は、Aurora Serverless v2 クラスターとそれに関連する DB インスタンスの容量範囲を設定する方法を示しています。以下の手順を使用して、DB インスタンスのビジー状態をモニタリングすることもできます。その結果によって容量範囲を増減させる必要があるかどうかを判断できます。 これらの手順を使用する前に、Aurora Serverless v2 のスケーリングの仕組みを把握しておいてください。スケーリングのメカニズムは、Aurora Serverless v1 とは異なります。詳細については、「Aurora Serverless v2 でのスケーリング」を参照してください。 Aurora クラスターの Aurora Serverless v2 での容量範囲の選択 Aurora Serverless v2 DB インスタンスでは、最初の Aurora Serverl

  • 組織パフォーマンスを改善しよう! - kakakakakku blog

    今週,社内で「技術的負債」をテーマにしたイベントがあり,トーク枠で発表をしてきた.タイトルは「技術的負債を "なるべく" 作らないためのコツ」で,意図的に技術の話をせずに,エモ系のストーリーに仕上げた. 特に伝えたかった部分は最後の「組織パフォーマンス」を改善する Tips で,雑談の重要さ,質問の重要さ,相互理解の重要さ,表情の重要さなどを語った.その中でも「ノンバーバルなコミュニケーション」の Tips はイベント中も気になっていて,発表者がもっと気持ちよく話せるように反応しましょー!と,緊張をほぐすようなアプローチもした. もっと「組織パフォーマンス」を改善していきましょ!!! 発表資料 関連記事 「組織パフォーマンス」を改善する Tips はコーチングの文脈からもインスパイアされていて,コーチングを学ぶならまずこのから読むのが良いのではないかなと思う. kakakakakku.h

    組織パフォーマンスを改善しよう! - kakakakakku blog
  • AWS での分散負荷テスト | AWS ソリューション | AWS ソリューションライブラリ

    大規模な負荷時のソフトウェアアプリケーションテストを自動化して、潜在的な性能上の問題をより容易に特定する AWS での分散負荷テストは、大規模な負荷時のソフトウェアアプリケーションテストを自動化して、リリース前に潜在的な性能上の問題を特定するのに役立ちます。このソリューションは、一定のペースでトランザクションレコードを生成する数多くの接続ユーザーを作成およびシミュレートします。サーバーをプロビジョニングする必要はありません。また、このソリューションでは、複数の AWS リージョンにまたがってテストを実行することができます。

    AWS での分散負荷テスト | AWS ソリューション | AWS ソリューションライブラリ
  • DevelopersIOブログ基盤を北米に移設して, AWSコストを33%削減してみた | DevelopersIO

    今回、現地でのブログ執筆環境の改善をコストパフォーマンスよく実現するため、 ブログ基盤で利用する AWSのリージョンを 東京(ap-northeast-1)から オレゴン(us-west-2) へ 移転する機会がありましたので、紹介させていただきます。 構成図 改善効果 東京リージョンからオレゴンへの移設により、AWS利用費は月額750ドル、約33%の削減を見込んでいます。 東京、オレゴンコスト比較一覧 サービス Type 消費量(月間) 東京単価($) オレゴン単価($) 東京月額($) オレゴン月額($) 削減率

    DevelopersIOブログ基盤を北米に移設して, AWSコストを33%削減してみた | DevelopersIO
  • お前らのReactは遅い - Qiita

    煽りタイトルですみません。 最近、Reactプロジェクトのページを動かしていて、 もっさりしてる(レンダリングの負荷が高いな)と思ったので どうやったら無駄なレンダリングを減らせるか思考錯誤したことをまとめました。 preactとか別ライブラリの話はしません。 よかったらこちらもどうぞ ReactJSで作る今時のSPA入門(基編) 2019年07月06日追記: ブラウザのレンダリングの仕組みに関して良記事があったので先に一読しておくことをおすすめします。 良記事1:実際のところ「ブラウザを立ち上げてページが表示されるまで」には何が起きるのか 良記事2:ブラウザレンダリング入門〜知ることで見える世界〜 1ピクセルがブラウザに表示されるまで:Life of a Pixel 2018 この記事に関してはReactのDOMツリー(レイアウト)レンダリングに関する最適化戦略です。 2020年02

    お前らのReactは遅い - Qiita
  • MySQL データベースの負荷対策/パフォーマンスチューニング備忘録 インデックスの基礎〜実践 - Qiita

    TL;DR この記事に書いた事 二分探索木のお話(前提知識) MySQLのInnoDBで利用されているB+木インデックスの構造と特性 (前提知識) MySQLのClusteredIndex,SecondaryIndexについて(前提知識) カーディナリティについて(前提知識) 実際の負荷対策 検出編 スロークエリ 検出編 その他のクエリ割り出しいろいろ クエリ・インデックスの最適化 explainの使い方と詳細 ケース別実践 単純にインデックスがあたっていないケース カーディナリティが低いインデックスが使われているケース 部分的にしかインデックス/複合インデックスがあたっていないケース 複合インデックスの順序誤りでインデックスが適用できていないケース 複合インデックスの最初がrange検索のケース ソートにインデックスが適用できていないケース ソートにインデックスが適用できていないケース(

    MySQL データベースの負荷対策/パフォーマンスチューニング備忘録 インデックスの基礎〜実践 - Qiita
  • ブラウザレンダリング入門〜知ることで見える世界〜 - Qiita

    はじめに 『レンダリングの仕組みなんて知らなくても、ブラウザが勝手にやってくれるじゃん!』 当時駆け出しのエンジニアだった私はそう思っていました。 実際、当時の私はレンダリングの『レ』の字も知りませんでしたが、特に業務上で問題はありませんでした。 しかし、その時は突然訪れました。 クライアントの要望でアニメーションを多彩に取り入れた案件を実装した際に、テスト段階で一部ブラウザ(S○f○ri、E○ge)でアニメーションがひどい状況になっていることが発覚しました。 (開発中はChromeで確認を行っており、Chromeでは特に問題はなかったので発覚が遅れました。) それからは、狂ったようにパフォーマンスの改善方法をググり、修正する日々が続きました。(最終的には、なんとかマルチブラウザでの動作も担保し、納品まで完了しました。) その案件が落ち着いた後、改めて自分の調べたことを振り返ると、局所的な

    ブラウザレンダリング入門〜知ることで見える世界〜 - Qiita
  • いまさら聞けないLinuxとメモリの基礎&vmstatの詳しい使い方 - Qiita

    さくらインターネット Advent Calendar最終日は、硬派にLinuxのメモリに関する基礎知識についてみてみたいと思います。 最近はサーバーを意識せずプログラミングできるようになり、メモリの空き容量について意識することも少なくなりましたが、いざ低レイヤーに触れなければいけないシチュエーションになった際に、OSを目の前に呆然とする人が多いようです。 基的にLinux のパフォーマンスについて、メモリをたくさんつめばいいとか、スワップさせないほうが良い とか、このあたりは良く知られたことだと思います。 ただ、なんとなく ps コマンドや free コマンド などの結果を見るだけでなく、もう少しメモリのことについて掘り下げてみてみたいと思います。 メモリとキャッシュ Linux におけるメモリの状態を大きく分けると「使用中のメモリ」「キャッシュ」「空きメモリ」「スワップ」の 4 つに分

    いまさら聞けないLinuxとメモリの基礎&vmstatの詳しい使い方 - Qiita
  • Linuxパフォーマンス調査などで使うコマンドメモ - Qiita

    パフォーマンスなどの調査をする時に利用する便利コマンドメモ。 これないぞ、あれないぞなどあると思いますがとりあえずなどを参考にまとめたものをピックアップしています。 参考 [24時間365日] サーバ/インフラを支える技術 ‾スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ) 絵で見てわかるシステムパフォーマンスの仕組み CPU使用率やメモリなど全体の概要把握 top デフォルトでは3秒ごとにOSで利用しているプロセスの数や状態、またOS全体のシステムリソース状況が分かります。 パフォーマンスが悪い場合にOS全体としてどのリソースの利用が多いのか(CPU負荷なのかメモリ利用率が高いのか)などの判断に有用だと思われます。 top - 22:36:56 up 28 min, 2 users, load average: 0.00, 0.02, 0.

    Linuxパフォーマンス調査などで使うコマンドメモ - Qiita
  • JavaScriptでのDOM操作は重いのかという話とForced Synchronous Layoutについて - id:anatooのブログ

    2015年にもなるのにJavaScriptでのDOM操作のパフォーマンスについて書く。ウェブページにインタラクションを持たせたい時に、JavaScriptでDOM操作を行うことがよくある。このDOM操作のパフォーマンスについて、よく聞く意見を大別すると次の2つがある。 JavaScriptによるDOM操作は重たい レンダリングが重いだけで、DOM操作そのものはそれほど重たくない JavaScriptでオブジェクトのプロパティを操作したりする単体の処理は通常1ミリ秒もかからないが、DOM操作をするとレンダリングが完了するまでに数十ミリ秒程度かかったりする場合がある。1番目のDOM操作が重たいと言っている人は経験則的にそう言っていることが多い。 レンダリングの仕組みを知っている人は2番目の意見を言うが、重箱の隅をつつくような話をするとこれも必ずしも正しいわけではない。DOM操作するコードによっ

  • ssig33.com - docker ホストを長期間運用する際の注意点

    うちには 2013 年末ごろからずっと docker コンテナを運用し続けていた物理ホストがあったのだけど、最近 $ docker ps とかしても結果が戻ってくるのに 20 秒ぐらいかかるし、コンテナの起動とかにも同じくらい時間がかかる $ /etc/init.d/docker restart などとしようもんならコンテナが使用可能になるまで 3 時間ぐらいかかってた。とはいえそう頻繁にコンテナを手動で起動したり終了したりするホストではないし、 docker のデーモン自体を再起動するとかは当に稀なのでずっと放置してたんだけど、さすがに放置できなくなってきた。 $ docker ps --all | wc -l とすると 103781 とかなってて、ゴミコンテナやイメージが大量にありすぎるのが諸悪の根源なのではないかという予想を立てた。 そこでこのようなスクリプトでコンテナを掃除してみ

  • Apacheのチューニングメモ - Qiita

    個人的Apacheチューニングのメモ。 間違いがあったら教えて下さい! prefork 前提 Apacheでは、リクエストはApacheの子サーバプロセスが処理する。 子サーバプロセスは動的にforkで生成されたり、殺されたりする。 が、forkはとても重い処理なので、forkが発生しないように設定するのがよい。 チューニング方針 負荷が高かろうが低かろうが常に一定数のプロセスが動いている状態にする。 preforkの動作 MaxClientsは絶対値。 子プロセス数はこの値を超えない。 (以下正確ではないですが簡単に) Apacheは負荷が高くなってきたら 子プロセスを生成していく アイドル状態の子プロセスはMinSpareServers以上になるよう維持 MaxClients以上の子プロセスは生成しない MinSpareServersよりMaxClientsが強い 負荷が低くなってきた

    Apacheのチューニングメモ - Qiita
  • Apacheをデフォルト設定のままで使っていませんか? - OSSコンソーシアム

    TIS株式会社の小林です。今回はApache HTTP Server(Apache)の設定についてお話しします。 NetCommonsやSugarCRMなどスクリプト系言語で実装されたビジネスアプリケーションをApacheで動作させる場合、mod_perl、mod_phpなどApacheの追加モジュールで動作させることが良くありますが、この時のApacheの1プロセスの使用メモリは100MBを超える場合も少なくありません。 もしmod_perlやmod_phpなどを利用して、かつApacheをデフォルト設定で動かしているならば、アクセス数が多くなった時にメモリが足りなくなり、スワップが頻発して急激な性能劣化を引き起こしたり、最悪の場合OOM-Killerが動作して他のプロセスにまで影響を与える可能性があります。そのようなトラブルを未然に防ぐためにApacheの設定を見直しましょう。 ここで

  • (帰ってきた)InnoDBパフォーマンス最適化の基礎 | Yakst

    MySQL Performance Blogの翻訳。Perconaのサポートエンジニアである筆者が、InnoDBのパフォーマンスチューニングの基礎について、ハードウェアやOSの選定からパラメータの推奨値まで解説する。 最近、2007年にPeter Zaitevが書いた「InnoDBパフォーマンス最適化の基礎」という記事を見つけた。これは素晴らしい記事で、読んでいると、MySQLとPercona Serversそして今日利用可能な全ての基盤技術に関して、6年近くの間に何が変わってきたのかを見直してみたいと思わせるものだ。 当にたくさんのことが変わったものだ!この記事では、InnoDBの使用に効果的なパラメータの多くに、特にパフォーマンスの観点から焦点を当てる。私はサポートエンジニアで、Percona SupportではInnoDBパラメータの適切なサイズに関する質問がたくさん寄せられている

    (帰ってきた)InnoDBパフォーマンス最適化の基礎 | Yakst
  • 1216彩票-官网平台

    您不具备使用所提供的凭据查看该目录或页的权限。 请尝试以下操作: 如果您认为自己应该能够查看该目录或页面,请与网站管理员联系。 单击刷新 按钮,并使用其他凭据重试。 HTTP 错误 401.1 - 未经授权:访问由于凭据无效被拒绝。 Internet 信息服务 (IIS) 技术信息(为技术支持人员提供) 转到 Microsoft 产品支持服务 并搜索包括“HTTP ”和“401 ”的标题。 打开“IIS 帮助”(可在 IIS 管理器 (inetmgr) 中访问),然后搜索标题为“身份验证”、“访问控制”和“关于自定义错误消息”的主题。

  • jQueryより20倍速い!最強トゥイーンライブラリTweenMaxJS | DECONCEPTER

    Flash界最強ライブラリの一角 jQuery animateよりも圧倒的パフォーマンス。Flashの最強アニメーションライブラリTweenMax。JavaScript版があるのはご存知でしょうか。 TimlineMax/Lite TweenMax/Liteの4つのライブラリ群の総称でGSAP JSというパッケージ構成です。※要ライセンス注意(後述) まずはその圧倒的パフォーマンスを体感してください。プルダウンから主要ライブラリを選んで、STARTを押すと右下のfpsの数値が変わります。 GreenSock Animation Speed Test 豊富なアニメーション機能 GSAP JSの主要な機能として下記の物が挙げられます。パララックスなどのインタラクティブなサイトを作る上でもとてもすごく重宝しそうです。 ベジェアニメーション 繰り返し 逆再生 時間指定 一時停止 フレームラベル ゆ

  • DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング!

    MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください! まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in

    DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング!
  • これだけ見れば大丈夫!ーMySQLパフォーマンス監視のツボ(クエリ編)|技術ブログ|北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ

    これだけ見れば大丈夫!ーMySQLパフォーマンス監視のツボ(クエリ編) こんにちは、インフラ担当新人の nob です。 サーバー監視ツールで MySQL を監視しているのにデータが多すぎて活用していない。という方はいませんか?その豊富なデータをパフォーマンス・チューニングに活用しない手はありません。今回はサーバー監視ツールのグラフを読み解いた実戦経験を元に、「これだけ見れば大丈夫」というツボをまとめてみました。 これだけ見れば大丈夫! クエリ編 3つのつぼと5つのグラフ (その1)監視ツールが何を見ているのか知る (その2)監視のキモ、グラフ3点セット (Questions, Lock Waits と Transaction Handler) (その3)グラフでチェックする SQL チューニング ( Select Type と Handler) シンプルでお勧め、サーバー監視グラフ化ツール

    これだけ見れば大丈夫!ーMySQLパフォーマンス監視のツボ(クエリ編)|技術ブログ|北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
  • 過負荷をかわす Apache の設定 : DSAS開発者の部屋

    KLab Advent Calendar 2011 「DSAS for Social を支える技術」の9日目です。 前回は php を動かしている Apache の手前にリバースプロキシを 置く必要性を解説しました。 今日は、 その前の php のプロセス数を絞る設定と合わせて、実際に Apache で 設定する方法を紹介します。 以降、 php を動かしている Apache の事をアプリサーバー、リバースプロキシ+ 静的ファイル配信を行っている Apache の事をプロキシサーバーと呼びます。 基設定 まずは基的な設定のおさらいです。 アプリサーバー 並列数を絞るには MaxClients を設定します。アプリがどれくらいの時間を CPUの処理で使って、どのくらいの時間を外部リソース待ちに使っているかにも よりますが、だいたいCPU数の1.5倍〜2倍くらいが適当だと思います。 Hyp

    過負荷をかわす Apache の設定 : DSAS開発者の部屋
  • perfの使いかた

    概要 Linuxのパフォーマンス解析ツールであるperfの使いかたの紹介 背景 個人的にperfよくできてると思うので紹介したいというのと、 パフォーマンスカウンタの読み方ってあんまり知られてないみたいなので、 それの解説を書きたい。 構成 perf について説明したあと、パフォーマンスカウンタの読みかた、見かた、を説明する。 perfとは何か Linuxに付いてくるプロファイラ。 man perf によると、 NAME ---- perf - Performance analysis tools for Linux と、書いてある。名前がひどいのでなんとかしてほしい。 perf の特徴 個人的には、手軽に使えるのが素晴らしいと思う。 2.6.31以降カーネルに標準で付いてる。(Ubuntuだとlinux-tools-common(TODO:あとで確認)で入るはず) 特殊な設定が必要無く、