インデックス
最新記事一覧
| 発行日時 | パイプ名 | 見出し | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010-8-29 20:50 |
gusagiの日記
|
転職しました
すでにご存じの方もいますが、7月末で株式会社RYUSを退職しました。 8月からは、自社で携帯サービスを運営している会社で働いています。 自分が担当している開発のサービスインが間近ということもあり、しばらくはオープンソース活動に割ける時間が減りそうな感じですが、勉強会などで見かけた際には声をかけて貰えると嬉しいです(o・ω・o) |
||||||||||||
| 2010-7-18 19:15 |
gusagiの日記
|
[PHP][勉強会] 第54回PHP勉強会@関東の募集が始まってます
掲題の通り、7/31(土)に開催予定の第54回PHP勉強会@関東の募集が始まっています。
今回は、海外からゲストを迎えての勉強会で、agavi・Lithiumなどフレームワーク関連のセッションが行われます。また、RESTfulなURLの構築に関するお話もあるそうなので、興味のある方はご参加ください。 会場は、マイクロソフト株式会社さんの新宿オフィスにあるセミナールームです。 |
||||||||||||
| 2010-7-15 12:05 |
gusagiの日記
|
[勉強会] ソーシャルアプリセミナー「LAMPで作るソーシャルアプリの負荷対策」に参加してきました
株式会社コンテンツワンさん主催のソーシャルアプリセミナー「LAMPで作るソーシャルアプリの負荷対策 〜アプリとインフラの調和のテクニック〜」に参加してきました。講師は、KLab株式会社の森本さん。 全体的な内容としては、どのようにしてHTTP通信の待ち行列をなくすかという主旨で、ボトルネックとなりやすいDB側の改善と、Web（アプリ）側の改善のどちらについてもお話がありました。 DB側については、目新しく画期的な手法ではなく基本に忠実に対応を行っているようで、やはり土台となる知識と経験は重要と言うことを再認識。Web側はGDを自分たちでカスタマイズされているなど、ライブラリにまで踏み込んで負荷対策が必要な場合もあるということに驚きました。 自分自身への記録をかねて、セミナー中のメモ（メモ抜けや聞き間違いなども含まれている）を貼っておきます。 ---- 本論に入る前に
今日話したいこと対象者
なぜ高負荷対策が必要なのかリリース直後のソーシャルアプリのPV
アプリがヒットすると、3,000アクセス/秒となることもある ''リリース直後から高負荷対策が必要'' 長時間ダウンしてしまったら
モバイルソーシャルアプリ特有の5秒ルール
ソーシャルなインフラに求められる要件
Klabの場合
使用しているソフトウェア
サーバスペック
ボトルネックになりやすいDBのIO周りには高価な機材を利用している サーバ構成-- LVS -- Web(x台) -- DB(マスタ/スレーブ構成) これで大丈夫？''スケールアウトさせやすいインフラであっても、アプリケーションの作りが粗末では負荷対策は不十分'' アプリケーションの高負荷対策とは''HTTPの待ち行列を取り除くこと'' 負荷の正体
DBサーバの待ち行列を減らす
DBとの接続時間を短くするために
サーバパラメタのチューニング
アプリからは高速なSQLだけ実行する
高速なSQLを実行するために
遅いSQLを検出して対策
SELECTクエリはスレーブDBに逃がす
SELECT結果をアプリでキャッシュ
アプリから明示的にDBとの接続を切る
DBサーバの待ち行列が無くなったら''ソーシャルアプリ全般においてDBサーバがボトルネックになりやすいので、これが終われば負荷対策の半分は終わったようなもの''
Webサーバの待ち行列を減らす
Webサーバとの接続を短くするために
APCを導入する
ユーザ情報をキャッシュする
プロファイルをとって現状を把握する1
某アプリでは画像合成処理がボトルネックになっていた 画像合成を高速化する
GDのネイティブ関数を改修
ImageMagickを使って1〜3まで500msec掛かっていた案件でも画像合成が100msec弱と5倍以上高速化することができた 本日のまとめ''負荷対策とはHTTPの待ち行列を取り除く処理''
質疑応答
|
||||||||||||
| 2010-6-28 23:53 |
gusagiの日記
|
[PHP][勉強会] 第53回PHP勉強会@関東に参加してきました
すでに先週のことになってしまいましたが、第53回PHP勉強会@関東に参加してきました。 幹事は前回に引き続きkashiokaさん、会場はマイクロソフトさんのセミナールームでした。本当にありがとうございます！ 以下は、勉強会の内容に関するメモです。 asao_jpさん RESTっぽいHTMLフォーム
shimookaさん スクリプトの難読化
難読化とは
利用シーン
現状
作ってみた
マイクロソフト 奥主さんの発表
super_rtiさん 新潟アクセス修飾子/指定子のご提案
新潟アクセス修飾子
---- asao_jp さんの発表を聞いてて、自分も昔似たようなことを考えたのを思い出しました。でも、なぜ実際に使わなかったのか思い出せず...orz 思い出せていたら、質疑応答の時にもう少し色々と質問できたかも知れません^^; id:shimooka さんの発表のときにパフォーマンスについて質問したら、なぜかパフォーマンス測定をすることになりましたｗ 近いうちに適当な1ファイルのライブラリを使って速度とメモリの両面を測定してみようかと思います。 super_rti さんの発表については、niigata修飾子よりも、修飾子を使えるようにするためのPHP改造の部分が興味深かったです。 メンテナンスやら環境依存やらの問題が出そうなので業務では試すこともできそうにないですが、PHP本体のコードを読むのも色々と勉強になって面白そうに思えました。 懇親会では、お酒を飲まずにやまもとさんやhamacoさん、MugeSoさんやsiroi_mogutanさんと話していたのですが、いつの間にかid:shimooka さんがHTC Desireで録画していましたｗ しかも、動画を見る限り、お酒を飲みまくっているかのようにテンションが高い自分が。。。一滴も飲んでなかったんですけどね...orz 色々と濃い話を聞いたりしつつ、あっという間に終電近くになってしまいお開きに。 3ヶ月ぶりくらいの勉強会参加だったのですが、やはり勉強会は刺激を受けることができて楽しかったです。 なお、次回はPHPフレームワーク「Agavi」のリードコミッタが海外からやってきての勉強会です。Agavi以外にRESTfulネタも話してくれるとのことですので、楽しみです＞＜ |
||||||||||||
| 2010-6-21 1:35 |
gusagiの日記
|
[WizMobile] 今後の展望というか
仕様についてふたつほど悩んでいたりします。 ひとつは、かんたんログイン機能について。 高木浩光さんのブログやHASHコンサルティング株式会社さんのアドバイザリなど、かんたんログイン周りで色々とセキュリティ上の問題が出ていることもあり、仕様を変更する or かんたんログイン自体を削ろうかと考え始めています。 仕様変更で対応する場合の方法は、実は1年以上前から思いついていたものの、ユーザの携帯メアドを登録してもらう必要があり「まだ実装しなくて良いか」と後回しにしていた方法だったりします。 携帯メアドの取り扱いなどをもう少ししっかり考えることができたら、こちらの方法で実装に入るかも知れません。 もうひとつは、セッションの維持について。 現在はhttpsでのクッキーの取り扱いなど色々と面倒な部分もあり、3キャリア共通でセッションIDをURL/hiddenで維持するようにしているのですが、モジュールによっては直接Locationヘッダを発行していて、完全にはセッションを維持できません。 セキュリティ的にもURL/hiddenで維持する方法には色々と問題があるので、正直なところクッキー方式に切り替えてしまおうかと検討しています。 この場合、問題になるのはdocomoのiモード2.0以前の端末。前述の高木氏のブログによれば、docomoのクッキー有効率は30%弱らしいので、クッキー専用にした場合はdocomoの7割のユーザでセッションが維持できなくなります。。。 とはいえ、クッキーが使えない7割のユーザすべてがインターネットを利用しているということもないでしょうし、実際に問題になる比率はもう少し下がるんじゃないかと思っています。 気になっているのは、このふたつについて仕様変更を行った場合に特に問題が出るのは、ひょっとしたらWizMobileを用いてケータイ対応を行っているシステム開発会社かも知れないこと。*1 社内にケータイ関連に詳しい方がいれば、うまくハックしてもらうのが一番だと思うんですが。。。 追記： docomoのiモード2.0以前の端末だけ今の仕様でセッション継続とかも、もちろん考えてはいます。 あまり乗り気ではないんですが・・・ *1：クライアントの意向で、仕様変更を許容してもらえない可能性があるため |
