生成AIを活用したSaaSサービス提供企業

  • Company
    • Company
    • 会社概要
    • グループ会社
  • Service
  • Work
  • News
  • Recruit
  • Blog
  • Contact

ブログBlog

  • ALL

  • お知らせ

  • 技術/デザイン/制作

  • ベトナム

  • ごはん

  • 日常/プライベート

  • WebSocketでチャットアプリを作る with Redis&Node.js

    どうも。営業部の伊藤です。

    もともとHTML5の仕様の一部として策定が進められていたWebSocketについて勉強するため、Node.jsを利用して簡単なチャットアプリを作ってみました。(目指せブラウザ版LINE!)

    今回はデータベースとしてRedisを採用しましたので、まずはRedisのインストールとコマンドラインを使った簡単な動作確認までを書きます。

    まず、Redisをインストールします。
    yumでもインストールはできますが、最新をインストールするため、ソースからインストールします。
    ※2012年9月頃

    # wget http://redis.googlecode.com/files/redis-2.4.16.tar.gz
    # tar zxvf redis-2.4.16.tar.gz
    # cd redis-2.4.16
    # make
    # make install

    あっという間です。
    RedisはANSI-Cで実装されているため、インストール時に依存ライブラリなどのインストールが不要です。
    よって、コンパイルは上記ステップで完了となります。

    既知の情報だと思いますが、念のため。
    Redisはインメモリベースの
    KVSです。
    KVSはRDB(リレーショナルデータベース)のJOINのように複雑、且つ高負荷なSQLは発行せず、高速化/拡張性に趣をおいたNoSQLのデータベース管理システムとなります。
    いわゆる分散型データ保管技術の1つです。
    同様のデータベースにはGoogle検索で採用されているBigtable(ビッグテーブル)、Amazonで採用されているDynamo(ダイナモ)、有名どころだとmemcachedなど様々な種類があります。
    また、RDBのような複雑なシステムではないため、サービス(mixi、Amazonなど)や大学の研究で独自のKVSが開発/採用されているケースも多々あります。

    そんなKVSですが、KVSごとの特徴は?ということで、今回選定したRedisの特徴をいくつか記載します。
    1. 永続化機構
    通常メモリ上でデータを管理しているため、memcachedのように障害時、再起動時にはデータを喪失してしまいますが、Redisは定期的にデータのスナップショットをダンプファイルにし、再起動時にこのファイルをメモリに読み込むことでデータを復元する仕組みを備えています。
    定期的という事で不安を抱く方も多いと思いますが、”Append Only File”という仕組みを利用することで全ての更新コマンドを管理しておき、再起動時にこのコマンドを読み込むという方法もあります。これであればデータの喪失は最小限に食い止めれます。
    注意すべきなのは、永続化機構といってもあくまでもインメモリベースのため、最大容量はRAMに依存します。
    RAM容量より多くのデータを保存したい場合はスワップファイルを利用し、一部のデータをHDDに退避させる必要があります。(RedisVM)

    2. 豊富なデータ型とコマンド
    Redisはハッシュ(HASH)以外の型もサポートしており、リスト型(LIST)、集合型(SET)、順序付き集合型(SORTED SET)などのデータ構造が扱えます。
    また、コマンドが非常に豊富、且つアトミックに操作が可能なため、CAS操作などトランザクションを考慮した処理が不要です。
    ただし注意すべき点として、アトミック実行(MULTI/EXEC)は一般的なトランザクションとして実行されている訳ではないため、実行中にエラーが発生した場合にROOLLBACKはされません。残りの処理も実行されます…ここは要注意です!
    (値を設定&取得くらいのアトミック操作であれば”GETSET”という1つのコマンドで対応可能)
    KVSの利用用途としてはデータの整合性よりもスピード重視の利用用途が多いと思いますので、トランザクションを考慮する機会は少ないと思いますが、アトミックに操作が可能な事でデータ管理方法の幅が広がります。

    3. レプリケーション
    Redisはマスター/スレーブのレプリケーションが設定ができ、スケールアウトが非常に容易です。
    設定は簡単で、スレーブ側の設定ファイルに以下項目を追加するだけです。

    # cp redis.conf redis_slave.conf
    # vi redis_slave.conf
    …
    # port 7000 <= スレーブはポート7000番で稼働
    # slaveof localhost 6379 <= slaveofにマスターのホスト名とポート番号を指定
    …
    # redis-server redis_slave.conf

    設定できているか否かの確認はinfoコマンドを実行するか、実際に値を設定して確認します。
    infoコマンドの場合、実行後に「role」を確認してください。

    # redis-cli -p 6379 -h localhost <= マスターに接続
    redis 127.0.0.1:6379>info
    …
    role:master
    …

    役割がマスターになっていますね。次にスレーブに接続します。

    # redis-cli -p 7000 -h localhost <= スレーブに接続
    redis 127.0.0.1:7000>info
    …
    role:slave
    …

    役割がスレーブになっていますね。無事設定できているようです。

    最後に、実際にレプリケーションできているかを確認するため、マスターにデータを登録し、その後スレーブでデータを取得してみます。

    # redis-cli -p 6379 -h localhost
    redis localhost:6379> set test “test-data”
    OK
    redis localhost:6379> get test
    “test-data”
    redis localhost:6379>exit# redis-cli -p 7000 -h localhost
    redis localhost:7000> get test
    “test-data”
    redis localhost:7000>

    問題なさそうです。

    4. Publish/Subscribe型(Pub/Sub型)の通信をサポート
    今回DBにRedisを採用したのはこの「Pub/Sub型通信」をRedisがサポートしているためです。
    送信側と受信側がトピックを介して”多対多”で通信できるモデルのため、Redisを中継サーバとしてWebSocketサーバを冗長化する事ができます。
    Node.jsについて説明できていないため順番が前後しますが、Nodeを利用してPub/Sub通信の動きを確認してみます。

    nodeのコンソールを起動し、以下スクリプトを実行します。

    # node
    > var sys = require(“sys”);
    > var redis = require(“redis”);> var subscriber = redis.createClient(6379, “localhost”);
    > subscriber.subscribe(“I am subscriber”);
    > subscriber.on(“message”, function(channel, message){
    > sys.puts(channel + “に「” + message + “」というメッセージが送信されたようです。”);
    > });

    > var publisher = redis.createClient(6379, “localhost”); //publisherは敢えて作る必要ないです。var subscriberを使って問題無いですが、分かりやすくするため!
    > publisher.publish(“I am subscriber”, “I am publisher”);

    6379番ポートのredisの「I am subscriber」というトピックに対して配信を申し込み(subscribe)、配信があればコンソール上に受信内容を出力するようにします。
    その後、6379番ポートのredisの「I am subscriber」というトピックに対して”I am publisher”というメッセージを配信します。

    上記スクリプトを実行すると、以下メッセージが表示されます。

    > I am subscriberに「I am publisher」というメッセージが送信されたようです。

    Pub/Sub通信のイメージ湧きましたでしょうか?
    分かり辛いですね…なんというか…自作自演ってな感じですね。

    という事で、上記コンソールはそのままにしておき、別コンソールを起動して以下コマンドを実行してみます。

    # redis-cli -p 6379 -h localhost
    redis localhost:6379> publish “I am subscriber” “I am publisher”

    するとnodeコンソール上に先ほどと同様に以下メッセージが表示されます。

    > I am subscriberに「I am publisher」というメッセージが送信されたようです。

    これこそがPub/Sub型の配信モデルです。
    node側ではトピック「I am subscriber」を購読(subscribe)状態のため、
    別イベントで「I am subscriber」にメッセージが登録されたと同時にメッセージをお知らせしてもらっています。

    今回は受信/購読者(Subscriber)、発行/公表者(Publisher)共に単一で確認しましたが、前述したように多対多の通信モデルのため、複数のSubscriber、またはPublisherでも上記通信が可能となります。
    WebSocketサーバーを冗長化した際に各々のサーバーでsubscribeしておき、連携したいデータをpublishすればサーバー間連系はこの中継サーバーに委ねられます。
    単一であればWebSocketでブロードキャストすればいいだけですが、冗長化を考えるとPub/Sub型を利用できるredisは非常に便利です。
    エンドポイントはWebSocketで管理しているため、サーバー間はPub/Sub型じゃなくてTriggerでもいいんじゃない?という方も居ると思いますが、サービス独自の特殊な通信制御が必要でない限りはPub/Sub型通信モデルの方が便利だと思います。

    Redisの準備は一旦ここまでとし、次はNodeの準備を進めます。
    少し長くなってしまったため、Nodeと各種ライブラリ(Socket.IOやExpressなど)のインストールについては
    次回ブログで投稿させていただきます。

    このエントリーをはてなブックマークに追加
    Share on Tumblr
    Tweet

    伊藤 康平投稿者 伊藤 康平

    投稿日: 2012/10/182012/11/13

    カテゴリー 技術 / デザイン / 制作
  • 究極のUX

    UXとかUIとか大好き竹内です。こんにちは。
    究極のUXって多数決でしかない様な気がするのは気のせいですかね。

    元々は何用語なんでしょうか?詳しいことはわかりませんが、WEB界隈ではかなり頻繁にこの言葉を目にしたり聞いたりする様になりました。
    仕事柄、WEBサイトのUIや、サービスフローや動きに関するUXなどにはいつも「なんで?」「どうして?」と疑問を抱きながら接するようにしています。

    もちろんそれはPCやスマートフォンの画面の中だけではないです。
    「どうしてここは引き戸なんだろう?」「どうして左が登りで右が下りなんだろう?」「手すりがここで終わってるのは何でなんだろう?」「こっちにもあれば便利なのにな」「どっちがどっちかわからないよ」「なんで何も書いてないの?」「一見お洒落なだけで使いにくいね」・・・などなど、それがUXとかUIとかいう言葉で括られる物とは特に意識しなくても生活していれば色々と感じるものです。

    そんな中、先日、ちょっと「おやっ?」と思う蛇口に出会いました。
    皆さんは蛇口は「ひねる(まわす)もの」という感覚が強いですよね?
    もちろん他にも上下に上げ下げするものや、自動で出るものなどもありますが、多くの人が蛇口と言えば「ひねる(まわす)」と思うのではないでしょうか。
    ではそんな決め付けの文章を書いた後ですが、皆さんは
    こんな水道を見たらどうしますか?
    自分だったら上にあげます。
    こんな水道だったらどうでしょう?もう「ひねる(まわす)」と思う人は少ないと思います。
    では、この白い部分が蛇口の両サイドに付いていたらどうでしょうか?
    (今、写真を撮ってこなかったを猛烈に後悔しています)
    いかにも「上にあげる」と思われる形のものが蛇口の両サイドにある場合、人は慣習的に「ひねる」のか「あげる」のか?

    ちなみにその蛇口は「ひねる」のが正解でした。
    何度かその洗面台を使ったのですが、自分は無意識に「あげる」操作をしようとしていて少しイラついたのを覚えています。

    蛇口だとそれほど違和感のあるものへの遭遇機会は少ないと思いますが、ドアの取っ手(ドアノブ)などであれば遭遇機会はそこそこあるのではないかと思います。
    「まわす」のか「下におろす」のか、「押す」のか「引く」のか「横にスライドさせる」のかなどなど。
    横へスライドして開けるドアにまるいドアノブが付いている所を想像してもらえればかなりの違和感を想像できるのではないでしょうか。
    上の蛇口については全然伝わらなかったと思いますが、このドアの例と同じくらいの違和感でした。

    実生活での体感も、画面の中での体感もそれほど大きくは変わらないはずですので、ユーザに不便や違和感や気持ち悪さを感じさせないものづくりをして行けたらなと思いました。

    このエントリーをはてなブックマークに追加
    Share on Tumblr
    Tweet

    アバター投稿者 staff

    投稿日: 2012/10/172012/11/13

    カテゴリー 技術 / デザイン / 制作
  • RoRと格闘中

    お疲れ様です。横井です。

    現在、案件と案件の谷間におりまして、ちょっと時間に余裕ができましたので、
    普段できないことをやろうと思い、Ruby on RailsをMy PC(Windows7上)にインストールしていろいろ触っているとろこになります。

    最近、Rubyの本を読みだしたこともあり、非常に気になっていたので、ちょうど良いタイミングと思い、始めてみました。
    がしかし、環境を構築するだけでもなかなかどうしての状態で思うように進んでいない状態です。

    まず、はまったところは、RMagick(ImageMagickをRubyで扱えるようにした関数)のインストールのところです。
    最新の環境(Ruby1.9.2 + rails3.2.8)でRMagickをインストールしようとしましたが、どうしても途中でアボートしてしまって、インストールできませんでした。
    (Google先生に聞くとインストールできた方を紹介してくれましたので、マネをしてみましたが、無残な結果となりました。結局、Rubyのバージョンを1.8系に入れ直して、無事インストールできました。)

    現在は、FacebookのOAuth認証をやってみようとがんばっておりますが、エラーの嵐から抜けられないくなっております。

    RoRはフレームワークと言うより、ミドルウェアに近い感覚で、扱いに慣れていないと設定している時間をかなり取られそうだなという感じです。

    しばらくは戦いから抜け出せないと思いますが、戦いから抜けだせるレベルになったら、案件でも使ってみたいと思っております。

    ではでは。

    このエントリーをはてなブックマークに追加
    Share on Tumblr
    Tweet

    アバター投稿者 staff

    投稿日: 2012/09/252024/04/26

    カテゴリー 技術 / デザイン / 制作
  • 「インターフェースデザインの心理学」読了

    ミステリー小説が大好き竹内です。こんにちは。
    森博嗣の作品が大好きですが最近のはまったく読めていません。

    そんな中、先日、インタフェースデザインの心理学という本を本屋で見かけて購入しました。
    もともとUI/UXには興味関心が強いのでこういった読み物は大好きです。

    書評が出来るほど沢山の本を読んでいる訳でもないですし、知識がある訳でもないのでただの感想になりますが、読み物として非常に面白かったです。
    人間はインプットをどの様に解釈して、脳はどの様に理解し、それをどの様にアウトプットするのか?そんなことが各章毎にテーマ別に書かれていますので、興味のある章だけつまみ読みする事も出来ます。
    自分が特に面白いなと思ったのは以下の項目でした。

    031 人はシステムを使うときメンタルモデルを作る
    043 ある事態に対する注意力は頻発が予想されるか否かで決まる
    052 ドーパミンが情報探索中毒を招く
    074 データより物語のほうが説得力がある
    087 エラーはすべてが悪いとはかぎらない

    それぞれに説明すると長くなってしまうのとネタばれになってしまうので解説はしませんが、どれもこれもなるほどなぁと思える内容でした。
    「当たり前じゃん」と切り捨てようと思えば切り捨てられる項目もあるのですが、その部分に再度注目することで意識が高まるので良かったです。
    「当たり前」の中にこそ真理はあり、「当たり前」は決して外す事はできず、そして「当たり前」の事を「当たり前」にやるのがどれだけ難しい事かを再認識する良い機会になったと思います。

    この本はリファレンス本ではないのですが、コンテンツを制作する上で迷った時にはたま~に目次に目を通して参考にできそうです。

    あまり遠くの人には貸せませんが、社内であれば誰でもお貸ししますので、興味があれば一言かけて貰えればと思います。

    次は何読もうかなぁ~。

    このエントリーをはてなブックマークに追加
    Share on Tumblr
    Tweet

    アバター投稿者 staff

    投稿日: 2012/09/132012/11/13

    カテゴリー 技術 / デザイン / 制作
  • レスポンシブウェブデザインについて思ふ

    WEB大好き竹内です。こんにちは。
    生活の殆どがWEBと繋がっています。

    レスポンシブウェブデザイン。流行っていますね。
    実際の導入以上に言葉がバズワード化して一人歩きするのはこの業界ではよくあることですが、これもまたそのひとつと感じています。
    レスポンシブウェブデザインの定義がはっきりしないまま「PCとスマホで同じコードで見られること」とか「PCとスマホでレイアウトが変わる」とか「画面サイズを変更するとレイアウトが変わる」など漠然とした意味でこの言葉を使っている人も多い気がします。

    別に言葉遊びがしたい訳ではないので「レスポンシブウェブデザイン」がどうということでもないですし、レスポンシブウェブデザインの意味について問いただそうという訳でもないです。
    ただ、流行言葉になってしまったこの概念が少し寂しいなと感じています。

    と言うのも、
    レスポンシブウェブデザインの様な「多種のデバイスで適切なアウトプット」という概念は、もっともっと昔から存在して、その頃はまだスマートフォンやらタブレットやらが存在していた訳ではないので、あまり目立った主張や華やかな世界ではなかったのも事実なのですが、その当時でも「テキストブラウザ」や「音声ブラウザ」の様なブラウザ、いわゆるPDAと呼ばれる様なデバイスなどは存在していて、それらの利用者に対しても問題なく情報が伝えられるというのが標準化(ではないかもしれませんが)などの理念に含まれていた様に思っています。

    それが今やHTML5だ、JavaScriptを用いたリッチインターフェイスだ、レスポンシブウェブデザインだ、モバイルファーストだと叫ばれ始め、旧デバイス利用者はどの様にWEBを利用出来ているのかを想像すると心が痛みます。

    僕自身、WEBは弱者の為にこそあるべきだという想いが強いので、
    このままWEBが先端者(?)だけのものになって行かなければいいなと思っています。
    そこにかける優しさがあるのであればこっちにも。。。そんな風に思いながらレスポンシブウェブデザインという言葉を眺めるそんな夏の終わりでした。

    このエントリーをはてなブックマークに追加
    Share on Tumblr
    Tweet

    アバター投稿者 staff

    投稿日: 2012/08/292012/11/13

    カテゴリー 技術 / デザイン / 制作
  • ApacheとnginXを比較してみた感想

    最近家庭の事情により留守番が多く、色々なパフォーマンスの比較に凝っています。
    言語間の処理(演算)スピードの比較、ボトルネックになりやすい
    データベース周りの比較などなど
    文献を読むだけでは知能レベル的にしっくり来ず理解できないため…
    実際に比較して勉強しています。

    今回はその中からWebサーバーの比較結果について書いてみます。
    2011年頃から一気にシェア率を伸ばし、シェア率第2位「IIS」の
    すぐ背後に迫る勢いのシェア率第3位「nginx」と不動の第1位「Apache」を比較してみました。
    Azureが順調なのかMS IISも2012年頃から復調の兆し(逆にApacheのシェア率は縮小)
    があるため、今後のシェア率の動向には要注目です。
    http://news.netcraft.com/archives/2012/07/03/july-2012-web-server-survey.html
    (nginxのシェア率10%越えてるんですね!!)

    比較はベンチマークの定番簡易ツールであるabコマンド(Apache Bench)を利用しました。
    基本オプションは以下になります。
    -c 同時に発行するリクエスト数
    -n リクエスト発行総数
    -t 負荷テストの実行時間

    検証方法としては、-n(総リクエスト数)を指定してどれだけの”応答時間”で捌けたのかを
    検証する方法や、-t(負荷テストの実行時間)を指定して、どれだけの”リクエスト数”を捌けたのか
    を検証する方法がありますが、今回は-nを指定して、所定のリクエスト数に対してどれだけの
    応答時間で捌けているのかを検証してみます。(総処理時間やスループットを比較)

    ******************************************************************************************
    ※例
    ab -c 10 -n 100 “http://localhost/”
    この場合、http://localhost/ に対して、同時発行(接続)リクエスト数が10、
    合計100リクエストを投げることになります。(同時に10個ずつのリクエストを合計10回実施)

    abコマンドの結果は以下になります。
    Server Software: nginx/1.3.4
    Server Hostname: comparehost
    Server Port: 8000

    Document Path: /
    Document Length: 43279 bytes => レスポンスデータサイズ(アクセス先ファイルサイズ)

    Concurrency Level: 10 => 同時接続数
    Time taken for tests: 6.005 seconds => 全ての処理が完了するまでの総時間
    Complete requests: 100 => 成功したリクエスト数
    Failed requests: 0 => 失敗したリクエスト数
    Write errors: 0
    Total transferred: 4383881 bytes
    HTML transferred: 4360146 bytes
    Requests per second: 16.65 [#/sec] (mean) => 1秒あたりの平均処理リクエスト数(スループット)
    Time per request: 600.516 [ms] (mean) => 1同時リクエストあたりの平均所要時間
    Time per request: 60.052 [ms] (mean, across all concurrent requests) => 1リクエストあたりの平均所要時間
    Transfer rate: 712.91 [Kbytes/sec] received => 1秒あたりの受信容量(byte数)
    Connection Times (ms)
    min mean[+/-sd] median max
    Connect: 28 552 244.4 576 2030
    Processing: 0 29 68.9 5 464
    Waiting: 0 2 7.7 0 34
    Total: 220 581 208.7 584 2030

    Percentage of the requests served within a certain time (ms) => 処理時間毎の割合
    50% 584 => 左記の場合、50%のリクエストが584ms以内に処理されたことを表す
    66% 605
    75% 623
    80% 635
    90% 702
    95% 879
    98% 1050
    99% 2030
    100% 2030 (longest request)

    ******************************************************************************************

    検証前に、環境の確認です。
    ○abリクエスト元ホストは同一マシン(自サーバーからではなく別ホストからのリクエストのため
    ○検証環境(リクエスト先サーバー)は同一マシン
    ○レスポンスデータサイズ(Document Length)は同じ ※nginx贔屓でリクエスト内容は静的コンテンツ…
    ○ApacheのMPMはprefork
    ○ApacheのVerは2.2.3(2.4.3ではないです。。)

    準備ができたので検証してみます。
    まずは同時接続数1で100回リクエストしてみます。
    ◆Apache(ab -c 1 -n 100 “http://comparehost/”)
    Server Software: Apache/2.2.3
    Server Hostname: comparehost
    Server Port: 80

    Document Path: /
    Document Length: 43279 bytes

    Concurrency Level: 1
    Time taken for tests: 12.173 seconds
    Complete requests: 100
    Failed requests: 0
    Write errors: 0
    Total transferred: 4355000 bytes
    HTML transferred: 4327900 bytes
    Requests per second: 8.22 [#/sec] (mean)
    Time per request: 121.727 [ms] (mean)
    Time per request: 121.727 [ms] (mean, across all concurrent requests)
    Transfer rate: 349.38 [Kbytes/sec] received

    Connection Times (ms)
    min mean[+/-sd] median max
    Connect: 98 121 19.1 119 220
    Processing: 0 0 0.4 0 3
    Waiting: 0 0 0.0 0 0
    Total: 98 122 19.1 119 220

    Percentage of the requests served within a certain time (ms)
    50% 119
    66% 123
    75% 128
    80% 130
    90% 145
    95% 157
    98% 198
    99% 220
    100% 220 (longest request)

    ◆nginx(ab -c 1 -n 100 “http://comparehost:8000/”)
    Server Software: nginx/1.3.4
    Server Hostname: comparehost
    Server Port: 8000

    Document Path: /
    Document Length: 43279 bytes

    Concurrency Level: 1
    Time taken for tests: 13.142 seconds
    Complete requests: 100
    Failed requests: 0
    Write errors: 0
    Total transferred: 4351400 bytes
    HTML transferred: 4327900 bytes
    Requests per second: 7.61 [#/sec] (mean)
    Time per request: 131.420 [ms] (mean)
    Time per request: 131.420 [ms] (mean, across all concurrent requests)
    Transfer rate: 323.35 [Kbytes/sec] received

    Connection Times (ms)
    min mean[+/-sd] median max
    Connect: 97 130 27.4 123 330
    Processing: 0 2 1.4 2 10
    Waiting: 0 0 0.0 0 0
    Total: 99 131 27.3 124 330

    Percentage of the requests served within a certain time (ms)
    50% 124
    66% 127
    75% 133
    80% 137
    90% 158
    95% 187
    98% 194
    99% 330
    100% 330 (longest request)

    接戦です。
    総処理時間はApache、スループットはnginxが競り勝ちました。
    nginxの方がスループットが勝っているため、マルチ処理が得意なnginxが
    総処理時間でも勝りそうな気もしますが、総リクエスト数が少ない&受信容量が勝った分なのか、
    総処理時間はApacheに軍配が上がりました。
    ただし、どんぐりの背比べでもあり、同時接続数も1のためあまり参考にはならない結果です。

    ******************************************************************************************

    次は一気に同時接続数を増やし、同時接続数50で1000回リクエストしてみます。
    ◆Apache(ab -c 50 -n 1000 “http://comparehost/”)
    Time taken for tests: 62.630 seconds
    Requests per second: 15.97 [#/sec] (mean)

    ◆nginx(ab -c 50 -n 1000 “http://comparehost:8000/”)
    Time taken for tests: 63.534 seconds
    Requests per second: 15.74 [#/sec] (mean)

    一気に同時接続数&リクエスト数を増やしましたが、これもほとんど変わらない結果でした。
    リクエスト数を10000回まで増やしても大きな差は発生しなかったため、
    同時接続数50、且つリクエスト数10000程度であればApache、nginxで特に大きな差はなく捌けるようです。

    ******************************************************************************************

    それではということで、次はリクエスト数を固定(1000回)し、
    同時接続数を増やしていきながら処理結果を観察してみました。
    ※ここからリクエスト元を自サーバーからに変更してます。

    ◆Apache
    =>同時接続数100(ab -c 100 -n 1000 “http://comparehost/”)
    総処理時間 :0.229897 seconds
    スループット:4349.77 [#/sec] (mean)

    =>同時接続数200(ab -c 200 -n 1000 “http://comparehost/”)
    総処理時間 :0.266142 seconds
    スループット:3757.39 [#/sec] (mean)

    =>同時接続数300(ab -c 300 -n 1000 “http://comparehost/”)
    総処理時間 :0.794779 seconds
    スループット:1258.21 [#/sec] (mean)

    =>同時接続数400(ab -c 400 -n 1000 “http://comparehost/”)
    総処理時間 :7.133020 seconds
    スループット:140.19 [#/sec] (mean)

    =>同時接続数500(ab -c 500 -n 1000 “http://comparehost/”)
    総処理時間 :14.90692 seconds
    スループット:70.97 [#/sec] (mean)

    同時接続数が300以上から明らかに性能が落ちています。
    MaxClientsを256に設定しているため、許容範囲を超え捌ききれなくなっているためだと考えられます。
    (因みに、MaxRequestsPerChildは200にしている)
    nginxはどうでしょうか!?

    ◆nginx
    =>同時接続数100(ab -c 100 -n 1000 “http://localhost:8000/”)
    総処理時間 :0.94022 seconds
    スループット:10635.81 [#/sec] (mean)

    =>同時接続数200(ab -c 200 -n 1000 “http://localhost:8000/”)
    総処理時間 :0.180318 seconds
    スループット:5545.76 [#/sec] (mean)

    =>同時接続数300(ab -c 300 -n 1000 “http://localhost:8000/”)
    総処理時間 :2.794196 seconds
    スループット:357.88 [#/sec] (mean)

    =>同時接続数400(ab -c 400 -n 1000 “http://localhost:8000/”)
    総処理時間 :1.264635 seconds
    スループット:790.74 [#/sec] (mean)

    =>同時接続数500(ab -c 500 -n 1000 “http://localhost:8000/”)
    総処理時間 :0.100467 seconds
    スループット:9953.52 [#/sec] (mean)

    ん?んん??
    Apacheよりスループットは高いけど、やっぱり同時接続数が増えるのと合わせて
    性能は落ちるな。。。と思いきや、同時接続数が500になったタイミングで一気に
    スループットが上がっています!

    =>同時接続数600(ab -c 600 -n 1000 “http://localhost:8000/”)
    総処理時間 :0.85274 seconds
    スループット:11726.90 [#/sec] (mean)

    =>同時接続数700(ab -c 700 -n 1000 “http://localhost:8000/”)
    総処理時間 :0.592253 seconds
    スループット:1688.47 [#/sec] (mean)

    600でも引き続き高いままで、700になり再度下降し始めました。
    nginxの場合は同時接続数が少なすぎると性能が落ちるのか、特性を活かしきれないようです。
    いずれにせよ、Apacheと比較すると圧倒的に静的ページへの同時アクセスを捌く能力は高いようです。

    【比較結果の個人的な感想】
    ○負荷が高くなく、早期セットアップが必要な場合は「Apache」
    ○負荷が高く、スケーラビリティが要求される場合は「nginx」
    ○静的ページに同時多数のアクセスが想定される場合は「nginx」
    ※動的ページは処理内容やサーバスペックによるため現状では判断できない(要調査)
    ○ある程度の同時アクセスが見込めない場合は「Apache」
    ○同時アクセス数は小さく、単純にリクエスト数が多い場合は「Apache」

    Apacheも2.4.x以降に大きく性能改善がされ、同時アクセス時の処理耐性はnginxよりも
    優れいているという情報もあるため、静的ページにおいてもチューニング次第ではnginxより
    優れたパフォーマンスを得られる可能性もあります。
    と、結局のところ確信にせまる特性を掴みきれてはいない状態ですが、、、
    少しだけnginxの特性を理解できたと思います。(動的ページの比較検証はできてないけど。。。)

    動的ページの検証はさておき、次回はデータベース周り、
    特にNoSQL(Redis、HBase、Cassandraなど)関係のプロダクトについて比較検討してみようと思います。
    噂のRedisの爆速っぷりを体感しようと思います。

    このエントリーをはてなブックマークに追加
    Share on Tumblr
    Tweet

    伊藤 康平投稿者 伊藤 康平

    投稿日: 2012/08/272012/11/13

    カテゴリー 技術 / デザイン / 制作

投稿ナビゲーション

前のページ ページ 1 … ページ 43 ページ 44 ページ 45 … ページ 49 次のページ