Redmineチューニングの実際と限界 - Redmine performance tuningRedmineチューニングの実際と限界(旧資料) - Redmine performance tuning(old), See Below.
OTN Japan マニュアル
お探しのものを見つけるために、以下の項目を試してみてください。 キーワード検索のスペルを確認してください。 入力したキーワードの同義語を使用してください。たとえば、「ソフトウェア」の代わりに「アプリケーション」を試してみてください。 新しい検索を開始してください。
Apache JMeter で負荷試験をしよう!
© 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice 2007 Apache JMeter 2007 1 30 2 19 2 14 • • Apache JMeter − • − − 3 19 2 14 • − • 2 − • − 4 19 2 14 • • • • • • Free Apache JMeter Apache JMeter 6 19 2 14 JMeter JMeter Jakarta / z z 100% pure Java Windows Linux z GUI z / z HTTP(HTTPS) FTP WEB z z Web 7 19 2 14 JMeter y y Java y y J
CSV 出力を１０倍高速にする方法 - オラクル・Oracle PL/SQL 入門
PARALLEL_EXECUTE パッケージ・モジュール ジョブを使用してマルチタスク処理させるためのフロント・モジュール このモジュールから UNLOAD のプロシージャを複数個、並列化して呼び出す。 仕様と制限 物理 ROWID を使用してデータの格納ブロックによってチャンク分割を行なっている。 論理 ROWID を使用する 索引構成表、外部表、および、ビュー などには使用できないため、別の分割方法を組み込んでカスタマイズする必要がある。NTILE 分析関数などは簡単なバケット分割方法であるがパフォーマンスを上げるひと工夫が必要だろう。 BIGFILE 表領域 に対してもソースの変更作業が必要となる(※2) DBMS_SCHEDULER 組み込みパッケージを使用しているため、Oracle 10g 以上の環境が必要。 ファイルの結合処理は含まれていない：ファイルを１つに結合したい場合には
ORMのパフォーマンス最適化
これは明らかに遅く非効率だ。この問題はEager Loadingというテクニックを使うことで解決できる。もし最初の注文クエリの一部として後で必要となる顧客とのアソシエーションをすべてロードしておけば、Customerに対するアクセスはただのプロパティへのアクセスになる。こうすれば後のデータベースクエリは不要になり、N+1問題も起こらない。 LightSpeedでは、そのEager Load設定をTrueに変更することで（もしくは手書きコードのエンティティにEagerLoadAttributeを適用することで）、アソシエーションのEager Loadを可能にする。Eager Loadされるアソシエーションをもつエンティティをクエリすると、LightSpeedは追加のSQLを生成して、‘プライマリ’エンティティと同じように関連したエンティティを取得する。 Order.Customerアソシエー
Oracle SQL の Hint（ヒント）句まとめ（一覧）
以前 Oracle SQLのHint句のメモ って記事を書きましたが、これが意外と検索されているんですよね。 バッチ処理向け SQL での話なのですが、パフォーマンスを突き詰めるとどうしてもヒント句に頼らざるを得ないケースがでてきます。なんでそっちのインデックス使うんだよぉ〜とか、何故かテーブルフルスキャンしてるときとか・・・その他もろもろ Oracle のコストベースの判定に泣きを見るケースがあります。 そんな僕もヒント句を使いこなせているわけではありません。 昨日 Oracle 使いなら手元におきたい！ - 書評 - 詳解Oracle アーキテクチャ を書いていて知らないヒント句があまりにたくさんあったので一覧をまとめてみました。情報ソースはオラクルのマニュアルです。無料で入手できて、最も正しく、最も情報量が多い教科書です。（わかりやすいかどうかは全く別問題です。ｗ） ※下記サイトの閲
パフォーマンステスト自動化の取り組み - GeekFactory
このところ、Webアプリやバッチのパフォーマンステストを自動化するために四苦八苦してるので書いてみます。 パフォーマンステストは泥臭い作業です。毎回似たような感じで待ち時間の長い単調作業と、ボトルネックを解析して実装やミドルウェア設定を見直すような神経を使う作業が入り混じって疲れます。このうち前者を自動化してしまえば、本質的な部分に力を注げるだけでなく、夜間や休日を活用して多くのバリエーションを試すことができます。 パフォーマンステストの流れはWebアプリとバッチで以下のように整理できると思います。 Webアプリ デプロイメント クライアントサイド（負荷生成側）で必要なデータセットの準備 サーバサイドで必要なデータセットの準備 アプリケーションの設定 負荷生成 クライアントサイドのログ収集 サーバサイドのログ収集 分析 バッチ デプロイメント サーバサイドで必要なデータセットの準備 アプリ
Node.js vs Play framework リベンジマッチ - from scratch
このブログはPlay! framework Advent Calendar 2011 jp #play_ja : ATNDの19日目です。 それでいて、Node学園の発表ネタというわけで、一石二鳥を狙った内容になっています。 ただ、Node学園では発表に失敗したので、今回は伝えきれなかった部分をお伝えし、少しPlayよりに話を してみたいかと思います。 Node vs Playベンチマーク 軽くおさらいします。 Node vs Play @ikeike443 さんの記事でも紹介されていますが、 Nodejs vs Play for Front-End Appsという記事で、NodeとPlayのベンチマークが行われています。 そこでの結果は、下記の通り。 Node 0.4.3 と Play 1.1.1 のベンチマーク結果として、レンダリングも含めて計測するとNodeの方が早い。 でもレンダリ
メンタリング・プログラムとは？
従来のピラミッド組織をプロジェクト制に転換、単純にフラット組織にしても、直ぐに高業績 を達成することにはなりません。従来のプロジェクト別の職制では、組織の垣根が厳然として存在 し、これを乗り越えることは、非常に難しいのが現実です。 高業績を達成するには、限られた人材を如何に効率的に、やる気ある人材の育成にあてる組織横 断的育成支援システムが必要となります。また、社員に留まらず、外部のメンバーも含めたプロ ジェクト・チーム全体を対象とした統合的育成支援システムにすることです。良い事例が、育成支 援プログラム（英語名：メンタリング・プログラム）を組んで進める方法です。その中心的役割を 果たすのが、組織横断的なメンターであり、メンターの抱える問題点を全社的立場で、調整する コーディネータ（育成担当）の存在が重要になります。これらが統合的に機能して、パフォーマ ンスをあげることが出来るのです。この
VMWareがクソ重くて殺したくなる時に読むべきもの - いつまでもブタだと思うなよ
冗談抜きでキレそうになって、悪いのは林檎なんだけどWindowsXPとかいう何年も前のOSを動かすのにこんなにクソトロイのは何でだ。とディスクアクセスとか調べまくってたら何かゲストOSがHDDにアクセスしてないタイミングでもアクセスが発生しまくっている事を発見し、色々と検索した結果見つけたのが下記のテキスト。http://wizardbible.org/49/49.txt該当部分について、何かtxtとかそういうファイルなので消えてしまわないように転載しておく。しかし本当にこの金床って人は凄い人だ。Blogなんかに何の確証もなく「この設定を.vmxにすりゃいいよ！ ○○○ = "xxxx"」とか書いているだけの何の価値も無い情報でなく、自分の調査方法を合せて読みやすくまとめてくれている。こういう記事をブログに書いていきたいと思ったね。 x0xXx0xx0xXx0xx0xXx0xx0xXx0x
＠IT：Javaパフォーマンスチューニング 第3回
本記事は、HP-UX Developer Edgeに掲載された記事を株式会社アットマーク・アイティおよび本記事の筆者が独自の判断のもとに加筆・修正したものです。 今回は、Javaにおけるヒープ・メモリ管理の詳細を説明します。JVMのヒープ・メモリの中で、新しいオブジェクトと古いオブジェクトがどのように配置されるかを理解することで、ヒープ・メモリが有効に利用されているか否かを判断することができます。また、JVMが出力するガベージ・コレクションのログを解析し、オプションの指定によってヒープ・メモリのサイズを適切にチューニングする方法を紹介します。 Java ヒープ・メモリの構造 Javaにおけるガベージ・コレクションのメカニズムを理解するには、まずヒープ・メモリの構造を知っておく必要があります。 図1は、JVM におけるヒープ・メモリの構造を示したものです。この図が示すように、ヒープ・メモリの
Hotspot VMの基本構造を理解する
J2EEがミッションクリティカルな分野に適用されるようになり、Javaのパフォーマンスチューニングの重要性はさらに高まっています。パフォーマンスチューニングにはさまざまなパラメータがありますが、中でもJava VMに関連するチューニングの効果は大きいといわれています。本稿は、Java VMに関連するチューニング手法を学ぶための前提知識を提供することを目的にしています（編集部）。 Java VMに関連するチューニングを行い、J2EEアプリケーションのパフォーマンスを上げるためには、Java VMについて詳しく知る必要があります。本稿は2回に渡ってJava VMの基本構造と動作原理を詳細に解説しますが、内容を理解するためにはプログラムがコンピュータ上で動作する基本原理とJava VMの基本用語を知っている必要があります。Java VMの基本用語に関しては、「実行スピードに挑戦するJavaアーキ
ガーベジ・コレクション：GC ( Garbage Collection ) についての簡単な説明と調査方法
Java の GC について簡単に説明いたします。 GC はヒープやヒープサイズと密接な関連があります。以下のページも合わせて参照ください。 「Java のヒープサイズ」についての簡単な説明 Java プログラムが動作するとオブジェクトはメモリ上にロードされます。 大きなオブジェクトを使用したり、また、使用するオブジェクトの数が多ければ、その分メモリの使用領域は増加します。 そのまま、新しいオブジェクトをロードし続けると、Java が使用できるメモリ領域がメモリが一杯になります。 * 「 Java が使用できるメモリ領域 」、これをヒープ領域と言います。( ヒープ領域以外にも Permanent 領域が存在します。) メモリが一杯になると新しいオブジェクトをロードできず、プログラムを実行することができなくなります。 このような状態を回避するための仕組みが ガーベジ・コレクショ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
Nodejs vs Play for Front-End Apps 翻訳
スケーラブルシステムのデザインパターン