チューニンガソン第3弾で優勝しました!
3/24日の第三弾チューニンガソンに参加したので、その詳細をまとめました。 ツッコミ大歓迎です！！！ 今回福岡でもリモートで参加可能だと聞いて、これは参加せねばと思いエントリしました。 基本ぼっちなんで一人で参加。 ~前日福岡のインフラ勉強会で一度、傾向と対策的なことをしてました。 ここでは、主にチューニング項目の洗い出しと、次のお題の予想してました。 私の予想では、webサーバーにnginx、appにredmineじゃないかと予想してました。。。 あとは、前回までがphpがお題だったので、php触った事無いのでapcインスコする手順とかを一応予習。 (結局、全く役に立たなかったのですが・・・・) その他にも、apacheやmysqlの設定を勉強してました。 msqlの勉強で最後の砦として読んだのが↓です。 オススメですよー あと、今回必ず使おうと思っていたのが、dstatでした。 dst
Tomcat 7のParallel deploymentを試してみた。 - コンピュータクワガタ
@ITの技術者が知っておきたいTomcat 7の新機能20連発で、Tomcat 7の新機能としてWebアプリのバージョン管理「Parallel deployment」が取り上げられていました。 これがうまく動くようだと場合によっては運用面で非常に楽になるため、簡単に検証してみました。 準備 まずTomcat 7の最新版を以下からダウンロードします。今は7.0.16のようです。zip版のものをダウンロードしています。 http://tomcat.apache.org/download-70.cgi ダウンロードしたファイルを今回は以下に展開しました。 C:\temp\apache-tomcat-7.0.16これでTomcatの準備は完了です。 アプリケーション アプリケーション概要 続いてデプロイするアプリケーションを作成します。セッションを持たないと意味がないため、無理やりセッションを使用
技術者が知っておきたいTomcat 7の新機能20連発
■ リクエスト処理のアーキテクチャ Tomcat 4時代から採用されているリクエスト処理のCatalinaアーキテクチャは変更なしで、そのまま採用しています。Tomcatが受け付けたリクエストは、リクエスト処理パイプラインによってServletまで到達し処理されます。 ■ クラスタリング（セッションレプリケーション） 若干のインターフェイスの改良はありますが、基本的には同じ仕様です。 「All-to-All」「primary-secondary」の2つのレプリケーション方式が利用可能となっています。 ■ DBコネクションプール 今までどおりApache Commons DBCPを使用し、バージョンはDBCP 1.4系(JDBC 4用)を採用しています。Tomcat独自のjdbc-poolを利用する場合は別途ビルドが必要です。jdbc-poolは近いうちに同梱されるかもしれません。 では、T
Servlet3.0でcometチャットを作ってみる - きしだのはてな
Cometとは？ ブラウザベースのチャットをつくろうとする場合、以前は定期的にクライアントからリクエストを送信して更新を確認するという手法がとられました。そうすると、平均して更新間隔の1/2の遅延が発生し、更新がないときの問い合わせが無駄になるなど、ユーザーにもサーバーにもうれしい手法ではありませんでした。 そこで使われるようになったのがCometです。 Cometは、HTTPでクライアントからの接続への返答を保留して、サーバーからデータを送信する必要がでたときに返答を返すことで、サーバーからのリアルタイムデータ送信を行う手法の総称です。 Servlet3.0でのComet対応 Cometでは、クライアントからの接続を保持しつづけるので、これまでのServletの仕組みをつかって実現しようとすると、各接続にスレッドを割り当てることになり、スレッド数が多くなりすぎるため、多くのユーザーには対
Tomcat7の新機能(CSRFとメモリリーク） - カタヤマンがプログラマチックに今日もコードアシスト
巷でうわさのTomcat7ですが、新しい機能として Generic CSRF protection Web application memory leak detection and prevention という気になる機能が入っているね、とT2チーム内で話題になっていました。 Tomcatのサイトを見るとバイナリ版配布が開始されていたので、とりいそぎJadってみることにしました。 Generic CSRF protection CSRFについては高木先生などの専門家に解説をまかせますが、要はサイト外からのリクエストによって不正な処理が行われてしまう、というセキュリティホールです。（リンクを押すと、mixiに勝手に書き込まれてしまうとかありましたよね） これを防ぐには、リクエストデータがサイト外からきているかどうかを判定する（=リクエストがサイト内から来ていることを判定する）ことが必要です
静的ファイルはTomcatに処理させない - やさしいデスマーチ
TeedaなどJavaEEでウェブアプリを構築する場合、バックエンドのTomcatやGlassfishにApacheから転送すると思います。しかし、CSSなど静的なファイルまでTomcatに処理させるのはムダなので、これらはApacheで処理を終わらせるような設定を行いましょう。 ProxyPass とか使えば簡単じゃんと思いますが、開発時もスムーズに動くようにするには結構工夫が必要です。開発時に運用時の環境を踏まえておき、デザイナ、プログラマ、デプロイヤー（？）のタスクがスムーズに回るようにしましょう。 構成 サーバアドレスのルート直下にアプリケーションが展開され、それらはTeedaで構築しているとします*1。 さらに静的ファイルに関してはまとめて扱う方が便利なので、１つのディレクトリに納めてしまいます。なのでこんな感じです。 webapp + /media | + css | + js
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
