最近プロコン（プログラミング・コンテスト）をはじめました。 基本的にはアルゴリズム勝負なのですが、とにかく速度を競うプロコンです。 小手先の速度チューニングもバカにできません。 何が速くて何が遅いのかはっきりさせるため、ボトルネックになりそうな操作のベンチマークを取りました。 実行環境は下記のとおりです。 python2.7.5 OS: MacOSX 11 CPU: Core i7 2GHz (4core) MEM: 16GB その1. 配列の初期化を高速化する まずはプロコンの基本中の基本、配列の初期化です。 下記７つの初期化方法を比較してみます。 空配列へappendして配列をつくる for内包表記で配列をつくる サイズ1(None)の配列を乗算してから値を代入する サイズ1(None)の配列を乗算する サイズ1(ゼロ)の配列を乗算する すべてゼロのarrayをつくる 0〜nのarra
Starting with JDK 7 update 40 (7u40), the Java Mission Control is bundled with the HotSpot JVM. The Java Mission Control can be used for simple monitoring of a Mule instance, for instance during development or for those content with what the community edition of Mule has to offer. In fact, Java Mission Control can be used to monitor any Java application that exposes a set of JMX MBeans. Since I wo
解説 worker_processes auto; - Nginx本体のプロセス数、autoにしてnginx内部判定に任せるのは賢明 worker_rlimit_nofile 100000; - workerプロセスが最大に開けるファイル数の制限。このように設定したら、ulimit -a以上のファイル数を処理できるようになり、too many open files問題を回避できる worker_connections 2048; - 一つのworkerプロセグが開ける最大コネクション数 multi_accept on; - できるだけクライアントからのリクエストを受け取る use epoll; - Linuxカーネル2.6以上の場合はepoll、BSDの場合kqueue server_tokens off; - セキュリティ対策です、エラー画面のnginxバージョン番号を非表示 sendf
2. Copyright © Acroquest Technology Co., Ltd. All rights reserved. 自己紹介 2 • 谷本 心 (Shin Tanimoto) - Acroquest Technology株式会社 - 開発＆トラブルシュート教育 - JavaOneスピーカー - JJUG / 関ジャバ / S2JSFコミッタ - Twitter : @cero_t (日本語) - Facebook : shin.tanimoto (英語) 3. Copyright © Acroquest Technology Co., Ltd. All rights reserved.Copyright © Acroquest Technology Co., Ltd. All rights reserved. 世の中のシステムは 完璧だろうか？ 3 4. Copyrigh
前書き - インデックスの作成はなぜ開発者のタスクなのか インデックスの 内部構造 - インデックスは何に似ているか インデックス リーフノード - 二重連結リスト 検索 ツリー(Bツリー) - バランス木 遅いインデックス パートI - インデックスを遅くする2つの原因 where 句 - 検索のパフォーマンスを改善するためにインデックスを作成 等価 演算子 - 一致するキーの検索 プライマリキー - インデックスの使い方を確認 複合インデックス - 複数列に対するインデックス 遅いインデックス パートII - 前の問題点が再び 関数 - where句の 中での関数 大文字・小文字を区別する 検索 - UPPERと LOWER ユーザ定義 関数 - 関数インデックスの制限 インデックスの作り過ぎ - 冗長性の排除法 パラメータ化 クエリ - セキュリティとパフォーマンスのために 範囲 検
Private content!This content has been marked as private by the uploader.
Javaではさまざまな方法でファイルのコピーを実装できる。Javaプログラマなら誰しも一度は、どの方法がもっとも高速にファイルコピーを実現できるか考えたことがあるだろう。プログラマにとって実行速度はいつでも最大の関心事のひとつだ。 File Copy in Java - Benchmark - Javalobbyに、こうした疑問に対するひとつの結果として興味深い記事が掲載されている。Baptiste Wicht氏が投稿した記事で、コピー実装を10の種類に分類し、それぞれどういった違いが現れるかを紹介している。コピー方法は次のとおり。 読み込みと書き出しのStreamを開いて、byteごとにファイルのコピーを実施。 読み込みと書き出しのReaderを開いて、charごとにファイルのコピーを実施。 読み込みと書き出しのBufferdStreamを開いて、byteごとにファイルのコピーを実施。
個人的Apacheチューニングのメモ。 間違いがあったら教えて下さい！ prefork 前提 Apacheでは、リクエストはApacheの子サーバプロセスが処理する。 子サーバプロセスは動的にforkで生成されたり、殺されたりする。 が、forkはとても重い処理なので、forkが発生しないように設定するのがよい。 チューニング方針 負荷が高かろうが低かろうが常に一定数のプロセスが動いている状態にする。 preforkの動作 MaxClientsは絶対値。 子プロセス数はこの値を超えない。 （以下正確ではないですが簡単に） Apacheは負荷が高くなってきたら 子プロセスを生成していく アイドル状態の子プロセスはMinSpareServers以上になるよう維持 MaxClients以上の子プロセスは生成しない MinSpareServersよりMaxClientsが強い 負荷が低くなってきた
Backing up important data is an essential task for system administrators to protect against all kinds of failures. However, traditional tools like rsync exhibit poor performance in the face of today's typical data sizes of hundreds of gigabytes. We address the problem of efficient, periodic, multi-gigabyte state synchronization. In contrast to approaches like rsync which determine changes after th
Webサーバに限らずだけど、サーバのパフォーマンス測定をするときには、CPU利用率やLoadAverageなどの値を測定しておくとベター。そういうデータがあれば、httpdのセッション数の時間推移とCPU利用率の推移を突き合わてやることで、そのマシンの性能一杯を使っているのか、余裕で動いているのかの判断がしやすくなるわけだ。 Linuxであれば"sar"というコマンドを使えば、比較的簡単にCPU利用率やLoadAverageのデータを取得できるので、それを使うのがいいと思うし、自分でもそれを使ってデータ取りしていることがほとんど。 "sar"は、sysstatというパッケージに含まれているので、Debianだったら aptitude install sysstat CentOSでも yum install sysstat でインストールは完了。 使い方は簡単で sar 10 とコマンドライ
Learn what you need to know to experience nirvana in the evaluation of G1 GC even if your are migrating from Parallel GC to G1, or CMS GC to G1 GC You also get a walk through of some case study data G1 GCRead less
JPAだけで完結するのはさすがにムリがあったのでこういうタイトルにした。が、JPAプロバイダ固有のAPIのレベルではフェッチサイズを変更する効果を確認できた。 JDBCのsetFetchSize変更時の動きをstatspackで見てみる - kagamihogeの日記ではJDBCを直接使用していたが、このエントリではJPAプロバイダ（EclipseLink, Hibernate）固有のAPIを使用して100万行取得するコードの速度を、フェッチサイズ変更無しと100の時とでどのくらい速度差が生じるかを確認する。 環境 DB CentOS-6.4-x86_64 Oracle Database Express Edition 11g Release 2 Java Java SE Development Kit 7u45 Eclipse Kepler(4.3.1) SR1 IDE for Java
Oracle WebLogic Serverチューニングのポイント 1. Oracle WebLogic Server チューニングのポイント 日本オラクル株式会社 オラクルユニバーシティ 岡田 大輔 2013年11月27日 1 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 2. 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するもので す。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み 込むことはできません。以下の事項は、マテリアルやコード、機能を提供す ることをコミットメント（確約）するものではないため、購買決定を行う際 の判断材料になさらないで下さい。オラクル製品に関して記載されている機 能の開発、リリースおよび時期については、弊社の裁量により決定されます 。 O
TCP Fast Open – Webを速くするためにGoogleがやっていること Make the Web Faster 4 – Jxck HTTPは、その下層にあたるトランスポートレイヤーのプロトコルとして、通常TCPを使用します。 したがって、TCPのレイヤで速度が改善することは、そのままWebの高速化につながる可能性があるといえます。 GoogleはWebを速くするための活動として、TCPのようなプロトコルレイヤの改善にも取り組んでいます。 今回はその中の一つ、TCP Fast Openを取り上げ、解説と動作検証、簡単なベンチマークを行います。 検証環境等は最下部に記載します. Make the Web Faster: TCP Fast Open 3 Way Handshake TCPは、「正確、確実にデータを届ける」ことを重視した設計になっています。 特に接続確立時には、双方の状
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
