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

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

ブログBlog

  • ALL

  • お知らせ

  • 技術/デザイン/制作

  • ベトナム

  • ごはん

  • 日常/プライベート

  • ビール

    PM部の里山です。
    y先日夏季休暇だったので、ふらっと松山へ足を延ばしてきたのですが、
    そこで飲んだ道後ビールなるものがお気に入りです。

    3種類あるのですが、スタウトタイプ(通称:漱石ビール)がお勧めです。
    苦みがある黒ビールですが、冷やすと飲みやすくなって良い感じです。

    個人的なビールのツートップは、
    ホーチミンで飲んだハイネケンと道後ビールです。
    今の所。

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

    里山 智秋投稿者 里山 智秋

    投稿日: 2012/08/302020/11/05

    カテゴリー 日常 / プライベート
  • レスポンシブウェブデザインについて思ふ

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

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

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

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

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

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

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

    アバター投稿者 staff

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

    カテゴリー 技術 / デザイン / 制作
  • ソムリエセット!

    こんにちは

    伊藤です。

    バイタリフィでは毎月恒例の月毎、誕生日を祝うイベントがあるのですが、
    僕の番がやってきました!

    包装紙に包まれて受け取るので、受け取った瞬間に想像より重くビックリしました!
    中をあけてみるとソムリエセットの文字。

    何かソムリエのコスプレセットかと思いきや本格的なソムリエセットでした!!
    しっかりした箱に入っていてなかなか高そうです!
    こんな感じです↓

     

     

     

     

     

     

     

     

     

     

     

     

    使うのがもったいない!!

    これで来年はソムリエの服をもらえば、

    バイタリフィ専属のなんちゃってソムリエになれそうです!(見た目だけ。)

    ちなみにソムリエになる為の試験を受けるには

    「ソムリエ」の試験を受けるためには、ワインおよびアルコール飲料を提供する飲食サービス業を通算5年以上経験し、現在も従事している必要があります。なお、3年以上会員である人は3年以上の従事で構いません。

    が条件の様です。

    飲食サービス業を通算5年以上はちょっとキツイですね。

    ちなみにソムリエの資格は、民間の資格はありますが国家資格はありません。
    しかも食べるもの(刺激物)にも気をつかわないといけないので大変です。

    ソムリエもなかなか大変だ。

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

    伊藤 博孝投稿者 伊藤 博孝

    投稿日: 2012/08/282012/11/12

    カテゴリー 日常 / プライベート
  • 大人の鉛筆

    お疲れ様です。横井です。
    今日の朝礼での1分間スピーチのネタですが、ブログにも残しておこうと思います。

    最近気になっているのが「大人の鉛筆」なるシャープペンシルになります。
    仕事がら、1日中パソコンを使っているので、紙に字を書くことはほとんどありませんが、
    一応、筆記用具は携帯しておりまして、シャーペンも携帯しております。

    個人的には、100均で売られているようなシャーペンはイマイチ(本体がプラスチックのものはぐにゃぐにゃした書き味がします)なので、今使っているシャーペンは製図用でちょっとお高いのものを使用しております。
    それで先日、雑誌を見ていたら、「大人の鉛筆」の記事を見つけまして、内容を読んでみると、非常によさそうな感じがしましたので、早く実物をさわってみたい衝動でいっぱいとなっております。

    今度の休みに新宿辺りで探してみようと思います。
    (世界堂辺りへ行けばありそうかな?!)

    ではでは。

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

    アバター投稿者 staff

    投稿日: 2012/08/282024/04/26

    カテゴリー 日常 / プライベート
  • 夏に聞きたい曲たち集

    どうも坂田です!もう8月も終わりですね、、、、入社して早3ヶ月…。
    1週間目にして社内で納豆を食べてひかれてたので、
    もう何をしても許されるのではないか。と密かに思い始めているのは秘密です。

    最近はプロジェクトに携わるようになり、色々と成長も感じながら、
    試行錯誤の日々を過ごしております。
    「今日はやってやったぜ!」と思うこともあれば、「あ~もっとああすればよかったなぁ」と
    落ち込む日もあります。

    そんな時に、私を癒してくれるのは・・・

    “夏に聞きたい曲たち集” の続きを読む

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

    アバター投稿者 staff

    投稿日: 2012/08/282012/11/12

    カテゴリー 日常 / プライベート
  • 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 … ページ 380 ページ 381 ページ 382 … ページ 560 次のページ