スキップしてメイン コンテンツに移動

EstevaX メモ パフォーマンス測定


[EstevaX 作業日記]
   KyoroTextのコードはすべて捨てることにしました。 新たに作り直します。
   次のアプリのメタファはEstevaです。  AESTIVALISを誤記した結果、Estevaになりました。
     # Just In Time に、情報を表示すること
     # AESTIVALIS のように直感的に扱えること
   を目標とします。


[課題]
    KyoroTextの反省として、パフォーマンスの問題があります。 ちょっとした修正が、大きくパフォーマンスに影響することがありました。
    そして、このような問題をそくざに検知することができませんでした。
    今回は開発を開始したタイミングで、この問題に対応したいと考えています。

[試み]
    EstevaXでは、 パフオーマンス測定用の自動テストを作ることにTRYしてみることしました。
    具体的には、以下のような感じです。
      -A. Instrumentation#setAutomaticPerformanceSnapshots()
      -B. Aでしている事を、別の方法で実現する。
      -C. cpuの使用率を計測する。

    ○Aは「Android Application Testing Guide」 で紹介された方法です。(http://dtmilano.blogspot.jp/)
    cpuの処理時間を元に計測できるので、より良い的なことがかかれいました。
 
    ○Bは、直接必要なAPIをたたけば良いのではないか?と考えるにいたり、「PerformanceCollector(Androidのソース)」から
    APIの使い方を流用することを思いつきまた。

    ○Cは、「TOPコマンドをたたくだけで良いかな」と考えています。
 

[A. Instrumentation#setAutomaticPerformanceSnapshots()]
   Instrumentation#setAutomaticPerformanceSnapshots() を コールすると、Instrumentationが終了時に、
   以下のような素敵ログをはいてくれます。
   このうち、cpu_time execution_time に着目して、実際にプロセスが使用した時間を取得できます。
INSTRUMENTATION_RESULT: other_pss=3969
INSTRUMENTATION_RESULT: java_allocated=6146
INSTRUMENTATION_RESULT: global_freed_size=20128
INSTRUMENTATION_RESULT: native_private_dirty=16
INSTRUMENTATION_RESULT: native_free=132
INSTRUMENTATION_RESULT: global_alloc_count=1475
INSTRUMENTATION_RESULT: other_private_dirty=2880
INSTRUMENTATION_RESULT: global_freed_count=344
INSTRUMENTATION_RESULT: sent_transactions=-1
INSTRUMENTATION_RESULT: java_free=193
INSTRUMENTATION_RESULT: received_transactions=-1
INSTRUMENTATION_RESULT: pre_sent_transactions=-1
INSTRUMENTATION_RESULT: other_shared_dirty=2604
INSTRUMENTATION_RESULT: pre_received_transactions=-1
INSTRUMENTATION_RESULT: execution_time=5230398
INSTRUMENTATION_RESULT: native_size=2912
INSTRUMENTATION_RESULT: native_shared_dirty=24
INSTRUMENTATION_RESULT: cpu_time=317
INSTRUMENTATION_RESULT: java_private_dirty=1396
INSTRUMENTATION_RESULT: native_allocated=2779
INSTRUMENTATION_RESULT: gc_invocation_count=0
INSTRUMENTATION_RESULT: java_shared_dirty=8796
INSTRUMENTATION_RESULT: global_alloc_size=91221
INSTRUMENTATION_RESULT: java_pss=1685
INSTRUMENTATION_RESULT: java_size=6339
INSTRUMENTATION_RESULT: native_pss=16
INSTRUMENTATION_CODE: -1

   ためしに 私が書いたコードは、以下のところに起きました。
   https://github.com/kyorohiro/KyoroSamples/tree/master/InstrumentationSample

   adb shell am instrument -w .kyorohiro.samples.android.instrumentation/info.kyorohiro.samples.android.instrumentation.MyInstrumentation
   で動作します。



[-B. Aでしている事を、別の方法で実現する。]
    Aは使い勝手が悪いです。 instrumentationの動作が完了するまで結果が出力されまん。
    なので、別の方法をとることにしました。

    Androidの該当するコード(PerformanceCollector)を呼んでみると、対応するAPIは公開されていることがわかります。
    具体的には、SystemClock.uptimeMillis() と、 Process.getElapsedCpuTime() です。
    直接このメソッドをコールすれば、プロセスがCPUの使用している時間だけをとることができます。
    かなり便利です。そして簡単です。

    ※ためしに 私が書いたコードは、以下のところに起きました。
    https://github.com/kyorohiro/KyoroSamples/tree/master/PerformanceCheckSample
    ※ ↑はCPUの使用時間以外も、Aの場合と同等の結果を任意のタイミングで返すことができます。


   当面は、 Process.getElapsedCpuTime()を使用してパフォーマンスを測定することにしました。
   何か問題が見つかるまでは、これでいこうと考えています。

コメント

このブログの人気の投稿

KyoroStressの技術 -1- Low Memory Killer を意図的に発生させたい

[課題] Low Memory Killer を意図的に発生させたい Androidには、ヒープが涸渇すると使われていないアプリをKillする機能があります。 この記事では、意図的にヒープを枯渇させて、この状態をつくる方法について説明します。 単純にヒープを大量に消費するアプリを作成すれば良いように思えます。 しかし、これだけでは上手くいきません。   -A ひとつのアプリで消費できるヒープが制限されているため、ひとつのアプリで端末のヒープが涸渇している状態をつくれない。   -B ヒープを涸渇しているアプリがPFにKILLされる場合がある。 といった問題があります。 KyoroStressV2での解決方法を紹介します。 [KyoroStressでの解決方法] Kyoro Stress では、以下のような方法をとりました。 - 1. 複数のServiceを、各々異なるプロセスで起動する。 - 2. 各々Serviceで大量のヒープを消費する。 複数のプロセスを立ち上げれば、PFのヒープを枯渇させることができます。これで、(A)の問題が解決できました。 また、Bについては、「生きているプロセス」が「KILLされたプロセス」の分もヒープを消費すれば上手くいけそうです。 [BigEater(ヒープ消費サービス)の動作] KyoroStressV2で、ヒープを消費するサービスは以下のシナリオで動作しています。 - 1. 指定されたヒープを取得する。 is retry が true の時、指定されたヒープを取得できるまで、1を何度も繰り返す。 - 2. KILLされたサービスを復活させる。 is retry が true の時、Threadが死ぬまで、何度も2を繰り返す。 - 3. 終了 といった感じです。 このままでは、すべてのServiceがPFにKILLされたら上手くいかないように思うかも知れません。 しかし、時間がたつと(数秒)、PFはKILLしたServiceを再起動します。 このため、ServiceがすべてKILLされても、ヒープを大量に消費しようとする状態は保持されます。 [使い方] KyoroStressV2の操作方法…

P2P探訪 STUNでNAT越え その1

UPnPを用いて、NAT越えできました。しかし、ルータがUPnPをサポートしていなかったり。UPnPだけでは越えられないNATがあります。

本文では、その代案として前回解説できなかった。「適当なサーバーに接続してみて、相手から見えているアドレスを返してもらう方法」について解説していきます。

TCPの限界 インターネットで公開されている情報のほとんどは、TCPという通信方法でデータをやり取りされています。ですから、インターネットで情報を公開したい場合は、TCPサーバーを立ち上げる事を考える事でしょう。
 しかし、ルータがUPnPをサポートしていない場合、TCPを用いたサーバーを運用する事は困難になります。※ 基本、無理と考えもらって問題ありません。


接続相手から教えてもらう方法はどうした? 適当なサーバーに接続してみて、相手から見えているアドレスを返してもらう事で実現できないのでしょうか。前回はできそうな事を臭わせていました。しかし、TCPにおいて、これは困難です。

実際にTCPのプログラムを書き確認して見ましょう。接続相手のホストアドレスは推測できます。しかし、ポート番号を知るすべはありません。


import java.io.IOException; import java.net.Inet4Address; import java.net.ServerSocket; import java.net.Socket; import java.net.UnknownHostException; public class TCPTest { public static void main(String[] args) { TCPTest test = new TCPTest(); test.startServer(); try { Thread.sleep(3000); } catch (InterruptedException e) { e.printStackTrace(); } test.startClient(); } private Server mServer = new Server(); public void startServer() { mServer.start(); } public v…

P2P探訪 Raider その1-2 Torrentファイルフォーマット

というわけで、前回に引き続いて、この記事ではTorrentファイルについて説明します。 [Torrent file format] 前回、Bencodingを実装したのでTorremt Fileを読み込めることができるようになりました。 今回は、Torrentファイルから必要な情報を読み込む方法について解説します。 torretファイルから取得できる情報はどんなものかは、別の機会に解説します。 ここでは、torrentファイルには 2つのフォーマットがあることとデータ構造を説明します。 たとえば、「"announce"というデータが何なのか?」については解説しません。 torrentファイルでは、ダウンロード/アップロードの対象としているファイルが、ひとつの場合と複数の場合で構造がすこしだけことなります。 ひとつの時を、「single file」 複数の時を「multi file」と呼ぶことにます。 では、データ構造を紹介します。 - single file pattern bendiction benstring "announce" beninteger "creation date" bendiction "info" beninteger "length" benstring "name" beninteger "piece length" bebstring "pieces" - multi file pattern bendiction benstring "announce" beninteger "creation date" bendiction "info" benlist "files" bendiction beninteger "length" benlist "path" benstring be…