Contextの生成・破棄を任意のタイミングで制御可能にする Scope::Container(仮) - blog.nomadscafe.jp
追記 CPANリリースしました http://search.cpan.org/dist/Scope-Container/ /追記 mod_perl のアプリケーションでは、Apacheモジュールの提供するpnotesを使うとリクエスト毎のデータを簡単に持つことができます。pnotesに入れたデータはリクエストの処理が終了したところで自動的にクリーンアップされます。これを利用したのがリクエストごとにインスタンスを作成破棄できる、Apache::Singleton(::Request)です。 また、pnotesはデータベースの接続の管理にもしばしば使われます。1リクエストを裁いている間だけデータベースとの接続を維持し、リクエストが完了したところで接続を閉じるような処理に利用されています。このようにすることでmod_perlのプロセス数分(数百）の接続がMySQLに常に張られることもなく、また１
mod_perl 2.0 の Server Life Cycle - daily dayflower
mod_perl 2.0 のサーバ起動にまつわる文書を読み込んでいました。 サーバスタートアップスクリプトは，1.0 時代のドキュメントでは「PerlRequire」記述子で読み込むように書かれていることが多いが，実行される時点が中途半端。なので，PerlPostConfigRequire を使う方が吉。もし設定ファイル自体で Perl の機能を利用しているのであれば（普通そこまでコアなことやらなくて済むんだけど），PerlConfigRequire を使うとサーバ設定フェイズ（すなわちかなり早い段階）で実行される。 Apache 2.x では，graceful restart がうまくいくことの確証を得るために，一度サーバ設定フェイズが終わると，Apache 自身を再起動する。ということは，サーバ起動時に，スタートアップスクリプト等は 2 回実行される。このことで困るってことはたいていな
Catalyst::Manual::Cookbook::Deployment - libnitsuji.so
Cookbook長いので分割。 デプロイについてのレシピ。Webサーバーエンジンとアプリケーションの効率化も含む。 http://search.cpan.org/~jrockway/Catalyst-Manual-5.700701/lib/Catalyst/Manual/Cookbook.pod#Deployment mod_perl Deployment mod_perlは多くのアプリケーションに対しての最適解だけど利点と欠点を述べる。他の方法としてはFastCGIがある。 Pros Speed mod_perlはとても高速で、それぞれのApacheプロセスのメモリにアプリケーションをロードすることによって恩恵を受けられる。 Shared memory for multiple apps 同じサーバーで複数のCatalystアプリケーションをする必要がある場合、mo_perlは共通のモジ
疑問：mod_perl と 後置 if と my - makogの日記
#!/usr/bin/perl use strict; use warnings; { my $flg; { my $cnt = 1 if ( $flg ); $cnt++; print "Content-type: text/plain\n\n"; print join( ', ', $cnt, $$, \$cnt ); } } 1; 上記のような CGI を mod_perl（ModPerl::Registry）上で動かすと、Apacheのプロセス毎に $cnt がカウントアップされます。 なぜでしょう？？？ 誰か教えてください。 $cnt はレキシカルスコープなはずですよね。スコープが外れた {} の後で $cnt を使うと怒られます。なのに、なぜかグローバル変数のように共有されてしまいます。 そもそも、my $cnt = 1 if ( $flg ); はどのように動作するのでしょう
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Linux のプロセスが Copy on Write で共有しているメモリのサイズを調べる
Linux は fork で子プロセスを作成した場合、親の仮想メモリ空間の内容を子へコピーする必要があります。しかしまともに全空間をコピーしていたのでは fork のコストが高くなってしまいますし、子が親と同じようなプロセスとして動作し続ける場合は、内容の重複したページが多数できてしまい、効率がよくありません。 そこで、Linux の仮想メモリは、メモリ空間を舐めてコピーするのではなく、はじめは親子でメモリ領域を共有しておいて、書き込みがあった時点で、その書き込みのあったページだけを親子で個別に持つという仕組みでこの問題を回避します。Copy-On-Write (CoW) と呼ばれる戦略です。共有メモリページは、親子それぞれの仮想メモリ空間を同一の物理メモリにマッピングすることで実現されます。より詳しくは コピーオンライト - Wikipedia などを参照してください。 この CoW に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
