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の半分ほどなので、この辺は要調査。
自作ライブラリ公開し始めました。
自作ライブラリが溜まってきたので、少しずつgitに公開していきたいと思います。
ConvertUIImage
暗号化→復号化機能、及びキャッシュ機能を持ったUIImageクラス。
Measurement
丸め誤差を考慮した、miri,nano,micro秒計測に対応した処理時間計測クラス
SHA512ver-UUID
UUIDを512bitまで拡張させ、IDかぶりのリスクをさらに低減させたクラス。UUIDはキーチェンに保存されます。
ScreenShotSender
スクリーンショットをslack、またはmailに送信できるビューボタンを常に表示し続けてくれるクラス。デバグがはかどります。
UIPlaceHolderTextView
プレースホルダを持ったテキストビュークラスgithub.com
ScreenShotSenderが我ながら便利です。
詳しい使い方とか、サンプルプロジェクトは徐々に増やしていきます。
サンプルプロジェクトはまだScreenShotSenderしかないですorz
AFNetworking:failureBlockでbodyの中身を取得する方法
いわずとしれた便利な通信ライブラリAFNetworkinggithub.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); }]; }
できないって記事を鵜呑みにせずに自分で検討する力も大事。
その力が身に付きつつあるなと実感。
今後も精進します。
UIScrollViewでの画像表示高速化、最適化についてのtipsその1
60FPS維持しつつ画像描写がめちゃムズい
UIScrollViewは60FPSで動いてるとの事で、
これを維持しつつ、
画像をなめらかにするのは難しい。工夫が必要。
色んな記事でこの問題は良く目にします。
解決策に「imageNamedを使おう」を良くみるが。。。
[UIImage imageNamed:XXX]は画像キャッシュし、読み込みが早い、
[UIImage imageWithContentsOfFile:XXX]は画像キャッシュせず、読み込みが遅い
ってなわけで「imageNamedを使おう!」
で終わっている記事が多いのですが、
imageNamedでもスクロール中に表示すると、
初回読み込み時につっかかる感触がある。
(私の意見としては後述の画像展開が悪さしているのであって、これは本質じゃないと思ってますが、深追いは止めときます)
圧縮形式画像→展開が重い
初回読み込み時だけってなんでかなー・・・。と模索してたところ、
どうやら「圧縮画像ファイル→展開」処理に
すごい時間かかってるらしい事が分かった。
展開を自前でやってみる
ViewDidLoadの段階で無圧縮展開してしまえば、
快適なスクロールビューが実装できるのではと思いたち、
サンプルコードを書いてみる事に。
nonCompressImageメソッドをViewDidロードで呼び、
圧縮画像ファイル→展開を自分でやってます。
自分で展開せずに、UIImageViewに展開を任せた場合の
つっかかりを確認する場合は、コメントアウトしている部分を
入れ替えてみてください。
つっかからなくなった!
つっかかりが一切消えました。やった。
後はメモリへの負担を気にしながらNSCacheなりで
画像のキャッシュ化をしてあげれば
imageWithContentsOfFileのパターンでの
高速表示もできますね。
これもかなり需要ありそうなのでtipsその2でのネタにしたいと思います。
今回は割と自分の勉強にもなりました。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
SwiftとObjective-Cどちらが人気あるか
言語習得の優先度を決める際、1つにGoogleTrendを使って良く検索がかけられているワードの言語を習得するようにしている自分。
swiftとObjective-Cどちらが良く検索かけられているかなーと調べたところ。。。
下記のような感じです。
青がswift、赤がObjective-C
結果、Objective-Cがほぼ見えないほどswiftが圧倒的。
http://www.google.co.jp/trends/explore#q=swift%2C%20objective-C&cmpt=q&tz=
「swiftすげー」と思ったらからくりが。。。
関連キーワードの欄
歌手の「Taylor Swift」が原因でした泣
別途トレンド検索の方法考えないとダメですね。
何か良い方法があれば誰か教えてください。
勉強すれどもSwiftの導入は見送ってしまう自分がいる
今日はObjective-Cの勉強と平行してSwiftの勉強を進めていて、良く感じてしまう事をブログに書き留めたいと思います。
結論として、やっぱり業務の中で取り入れるのにはまだまだ早計すぎるなぁ。。。
と感じます。
もちろんSwiftで開発しているアプリもたくさんありますが、
仕様もころころ未だに変わる、Xcodeで不安定な挙動をする事が多々ある、
Objective-CベースのライブラリをSwiftに入れたら結局Objective-Cのコードを意識させられる、挙げるときりないですが、実務でSwift開発すると、結局Objective-Cの理解が必要になると思うんですよね。
下記の記事でも触れられているんですが、余計な学習コストはかけたくないってのが普通の企業ですよね。
ASCII.jp:アップルは新しいプログラミング言語「Swift」が開発者に気に入られることを望んでいるが、そう上手くいくだろうか?
とりあえず仕様がころころ変わってるとエンジニアに嫌われるので、早めに安定してほしいですね。。。