2016-02-28

swift製webサーバ"perfect"を試してみた。

perfectサーバを立てて、nginxと静的ページの表示速度の比較してみた。
GitHub - PerfectlySoft/Perfect: Server-side Swift. The Perfect library, application server, connectors and example apps. (For mobile back-end development, website and web app development, and more...)

サーバスペック
1 cpu x 0.8 Ghz 1GB RAM
OS Ubuntu 14.04.4 LTS

ABコマンドによる調査を実施
ab -k -c 1000 -n 5000

nginx

Server Software	nginx/1.8.1
Document Length	5 bytes
Concurrency Level	1000
Time taken for tests	0.651 seconds
Complete requests	5000
Failed requests	0
Keep-Alive requests	5000
Total transferred	1190000 bytes
HTML transferred	25000 bytes
Requests per second	7677.43 [#/sec] (mean)
Time per request	130.252 [ms] (mean)
Time per request	0.130 [ms] (mean, across all concurrent requests)
Transfer rate	1784.40 [Kbytes/sec] received

Connection Times (ms)

	min	mean	[+/-sd]	median	max
Connect	0	15	32.9	0	96
Processing	12	81	103.4	46	494
Waiting	12	81	103.4	46	494
Total	12	95	115.4	46	582

そして期待のperfect

Server Software
Document Length	5 bytes
Concurrency Level	1000
Time taken for tests	4.266 seconds
Complete requests	5000
Failed requests	0
Keep-Alive requests	5000
Total transferred	620000 bytes
HTML transferred	25000 bytes
Requests per second	1172.08 [#/sec] (mean)
Time per request	853.184 [ms] (mean)
Time per request	0.853 [ms] (mean, across all concurrent requests)
Transfer rate	141.93 [Kbytes/sec] received

Connection Times (ms)

	min	mean	[+/-sd]	median	max
Connect	0	64	138.9	0	1780
Processing	51	705	442.2	471	2087
Waiting	4	704	442.2	471	2087
Total	51	768	454.6	658	3776

お・・・・おそ・・・・
お互い何もチューニングしてないので安直に結論は出せませんが、
遊び以外での導入は厳しい。。。
Server Softwareがからっぽなのは新鮮。
Total transferredがなぜかnginxの半分ほどなので、この辺は要調査。

2015-07-10

自作ライブラリ公開し始めました。

自作ライブラリが溜まってきたので、少しずつgitに公開していきたいと思います。

ConvertUIImage

暗号化→復号化機能、及びキャッシュ機能を持ったUIImageクラス。

Measurement

丸め誤差を考慮した、miri,nano,micro秒計測に対応した処理時間計測クラス

SHA512ver-UUID

UUIDを512bitまで拡張させ、IDかぶりのリスクをさらに低減させたクラス。UUIDはキーチェンに保存されます。

ScreenShotSender

スクリーンショットをslack、またはmailに送信できるビューボタンを常に表示し続けてくれるクラス。デバグがはかどります。

UIPlaceHolderTextView

プレースホルダを持ったテキストビュークラス<a href="https://github.com/HidekiYokozeki/iOS">HidekiYokozeki/iOS</a>github.com

ScreenShotSenderが我ながら便利です。
詳しい使い方とか、サンプルプロジェクトは徐々に増やしていきます。
サンプルプロジェクトはまだScreenShotSenderしかないですorz

2015-04-05

AFNetworking：failureBlockでbodyの中身を取得する方法

いわずとしれた便利な通信ライブラリAFNetworking<a href="https://github.com/AFNetworking/AFNetworking">AFNetworking/AFNetworking</a>github.com

errorBlock内ではbodyの中身取れませんって言われた

この前、エンジニア仲間から
「failureBlock内ではbodyを取って来れないって記事見たんでできない」
って言ってたのを聞き、
「んー、そんな事は考えにくいなぁ。。。」って思い、調べたので取得する方法を伝授。

やりかた

下記方法で取ってこれます。

-(void)requestAPI:(NSString*)API parameter:(NSDictionary*)parameters{
    
    AFHTTPSessionManager *manager = [AFHTTPSessionManager manager];
    manager.responseSerializer = [AFHTTPResponseSerializer serializer];
    manager.requestSerializer.timeoutInterval = 10.0;
    
    [manager POST:API
       parameters:parameters
          success:^(NSURLSessionDataTask *task, id responseObject){
              
              
          }
          failure:^(NSURLSessionDataTask *task, NSError *error){
              
              NSData* data = error.userInfo[AFNetworkingOperationFailingURLResponseDataErrorKey];
              NSString* body = [[NSString alloc] initWithData:data encoding:NSUTF8StringEncoding];
              NSLog(@"%@",body);
          }];
    

}

できないって記事を鵜呑みにせずに自分で検討する力も大事。
その力が身に付きつつあるなと実感。
今後も精進します。

2015-03-21

UIScrollViewでの画像表示高速化、最適化についてのtipsその１

iOS

60FPS維持しつつ画像描写がめちゃムズい

UIScrollViewは60FPSで動いてるとの事で、
これを維持しつつ、
画像をなめらかにするのは難しい。工夫が必要。
色んな記事でこの問題は良く目にします。

解決策に「imageNamedを使おう」を良くみるが。。。

[UIImage imageNamed:XXX]は画像キャッシュし、読み込みが早い、
[UIImage imageWithContentsOfFile:XXX]は画像キャッシュせず、読み込みが遅い
ってなわけで「imageNamedを使おう！」
で終わっている記事が多いのですが、
imageNamedでもスクロール中に表示すると、
初回読み込み時につっかかる感触がある。
（私の意見としては後述の画像展開が悪さしているのであって、これは本質じゃないと思ってますが、深追いは止めときます）

圧縮形式画像→展開が重い

初回読み込み時だけってなんでかなー・・・。と模索してたところ、
どうやら「圧縮画像ファイル→展開」処理に
すごい時間かかってるらしい事が分かった。

展開を自前でやってみる

ViewDidLoadの段階で無圧縮展開してしまえば、
快適なスクロールビューが実装できるのではと思いたち、
サンプルコードを書いてみる事に。

nonCompressImageメソッドをViewDidロードで呼び、
圧縮画像ファイル→展開を自分でやってます。

自分で展開せずに、UIImageViewに展開を任せた場合の
つっかかりを確認する場合は、コメントアウトしている部分を
入れ替えてみてください。

つっかからなくなった！

つっかかりが一切消えました。やった。
後はメモリへの負担を気にしながらNSCacheなりで
画像のキャッシュ化をしてあげれば
imageWithContentsOfFileのパターンでの
高速表示もできますね。
これもかなり需要ありそうなのでtipsその２でのネタにしたいと思います。

今回は割と自分の勉強にもなりました。ScrollView最適化に
詳しくなっておくと、色々重宝されそうなのでもっと勉強します。

#import "ViewController.h"

@interface ViewController (){
    
    UIImageView* imageView;
    UIImage* image;

}

@end

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    
    UIScrollView *sv = [[UIScrollView alloc] initWithFrame:self.view.bounds];
    UIView *uv = [[UIView alloc] initWithFrame:CGRectMake(0, 0, self.view.frame.size.width, self.view.frame.size.height*5)];
    imageView = [[UIImageView alloc]initWithFrame:CGRectMake(0, self.view.frame.size.height*2, self.view.frame.size.width,self.view.frame.size.height)];
    [uv addSubview:imageView];
    
    [sv addSubview:uv];
    sv.contentSize = uv.bounds.size;
    sv.delegate = self;
    [self.view addSubview:sv];
    
    image = nonCompressImage([UIImage imageNamed:@"sample.png"]);
    
}

-(void)scrollViewDidScroll:
(UIScrollView *)scrollView{
    
    int page = scrollView.contentOffset.y / scrollView.frame.size.height;
    
    if(page==2){
        
        //こっちのほうに変えるとつっかかる。
        //imageView.image = [UIImage imageNamed:@"sample.png"];
        
        
        //こっちに変えるとつっかからない
        imageView.image = image;
    
    }

}

- (void)didReceiveMemoryWarning {
    [super didReceiveMemoryWarning];
}

static UIImage * nonCompressImage(UIImage *image) {
    
    UIGraphicsBeginImageContext(CGSizeMake(image.size.width, image.size.height));
    [image drawAtPoint:CGPointMake(0,0)];
    image = UIGraphicsGetImageFromCurrentImageContext();
    UIGraphicsEndImageContext();
    
    return image;
    
}

@end

2015-03-12

SwiftとObjective-Cどちらが人気あるか

言語習得の優先度を決める際、１つにGoogleTrendを使って良く検索がかけられているワードの言語を習得するようにしている自分。

swiftとObjective-Cどちらが良く検索かけられているかなーと調べたところ。。。

下記のような感じです。

青がswift、赤がObjective-C

結果、Objective-Cがほぼ見えないほどswiftが圧倒的。

f:id:okogeki:20150312005355p:plain

http://www.google.co.jp/trends/explore#q=swift%2C%20objective-C&cmpt=q&tz=

「swiftすげー」と思ったらからくりが。。。

オープンソースの最新情報を集めるのに便利なWebサイト

メモ書き程度の記事ですが忘れないうちにブログに書き留めたいと思います。

<a href="http://www.moongift.jp/">オープンソースを毎日紹介</a>
オープンソースを毎日紹介 MOONGIFT

OSSを毎日紹介してくれるサイト。
気になるOSSはすぐにビルドして試してみよう。

2015-02-25

勉強すれどもSwiftの導入は見送ってしまう自分がいる

今日はObjective-Cの勉強と平行してSwiftの勉強を進めていて、良く感じてしまう事をブログに書き留めたいと思います。

結論として、やっぱり業務の中で取り入れるのにはまだまだ早計すぎるなぁ。。。

と感じます。

もちろんSwiftで開発しているアプリもたくさんありますが、

仕様もころころ未だに変わる、Xcodeで不安定な挙動をする事が多々ある、

Objective-CベースのライブラリをSwiftに入れたら結局Objective-Cのコードを意識させられる、挙げるときりないですが、実務でSwift開発すると、結局Objective-Cの理解が必要になると思うんですよね。

下記の記事でも触れられているんですが、余計な学習コストはかけたくないってのが普通の企業ですよね。

<a href="http://ascii.jp/elem/000/000/903/903703/" data-mce-href="http://ascii.jp/elem/000/000/903/903703/">アップルは新しいプログラミング言語「Swift」が開発者に気に入られることを望んでいるが、そう上手くいくだろうか？</a>
ASCII.jp：アップルは新しいプログラミング言語「Swift」が開発者に気に入られることを望んでいるが、そう上手くいくだろうか？

とりあえず仕様がころころ変わってるとエンジニアに嫌われるので、早めに安定してほしいですね。。。

Okogeki'sブログ

デキるエンジニアを目指すOkogekiのブログ

swift製webサーバ"perfect"を試してみた。

nginx

Connection Times (ms)

そして期待のperfect

Connection Times (ms)

自作ライブラリ公開し始めました。

ConvertUIImage

Measurement

SHA512ver-UUID

ScreenShotSender

UIPlaceHolderTextView

AFNetworking：failureBlockでbodyの中身を取得する方法

errorBlock内ではbodyの中身取れませんって言われた

やりかた

UIScrollViewでの画像表示高速化、最適化についてのtipsその１

60FPS維持しつつ画像描写がめちゃムズい

解決策に「imageNamedを使おう」を良くみるが。。。

圧縮形式画像→展開が重い

展開を自前でやってみる

つっかからなくなった！

SwiftとObjective-Cどちらが人気あるか

オープンソースの最新情報を集めるのに便利なWebサイト

勉強すれどもSwiftの導入は見送ってしまう自分がいる