PerlでContinuationベースのウェブサーバ - karasuyamatenguの日記
Continuationっていうのはプログラムの実行過程を途中でフリーズして別のところから再スタートさせたりすることができるという頭の痛くなるような機能だ。はやり御本家はscheme(call/cc)だけど他のハイレベル言語でもできるものがあるようだ。 ウェブフレームワークとしてはsmalltalkのseasideやcommon lispのuwcが有名。RubyやPythonもGeneratorを使って実装したものがあるらしい。あと、アプリケーションとしてはPaul Graham氏のnews.ycombinator.comが有名。これは彼の「100年言語」(実はPLTの上にマクロで作ったLispの方言)によって実装されている。 perlにはcall/ccやgeneratorのようなコールが無いのでContinuationベースのフレームワークは無いと思っていたが、間違っていた。Perlにで
Kazuho@Cybozu Labs: ウェブサービスのためのMutex - KeyedMutex
« キャッシュシステムの Thundering Herd 問題 | メイン | DBI::Printf - A Yet Another Prepared Statement » 2007年09月27日 ウェブサービスのためのMutex - KeyedMutex 昨日、以下のように書いたのですが、両者のうち２番目のアプローチを実現する Perl モジュール KeyedMutex を作成しました。 サーバにおける Thundering Herd 問題は良く知られていると思いますが、類似の現象はキャッシュシステムでも発生することがあります。 (中略) 対策としては、以下の２種類の手段があります。 バックエンドへの同一リクエストを束ねるような仕組みを実装する エクスパイヤ以前の残存時間が一定以下となった段階で、キャッシュエントリのアップデートを開始する これらの手法には、それぞれメリットとデメリッ
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
さくらインターネットサーバでのCPAN導入を完全に手順化して見た - Perl入門ゼミ
Perl › 環境構築 (この記事の内容は古くなっています、現在はcpanmを使ってモジュールをローカルにインストールするのが簡単でしょう。cpanmによるローカル環境構築を見てください。) otsuneさんのところでさくらインターネットのレンタルサーバでCPANを使用する方法が紹介されているのですが、一部手作業が発生するので、すべてコピペで実行できるように手順化してみました。 さくらインターネットサーバcpan導入手順 # ライブラリのためのディレクトリの作成 mkdir -p ~/local # CPANの設定ファイルを作成 echo no | cpan # cpanコマンドの設定ファイルMyConfig.pmの書き換え # ( __END__の行まで一気にコピーして実行してください。とまった場合はEnter ) perl - ~/.cpan/CPAN/MyConfig.pm > ~/
ウェブリブログ：サービスは終了しました。
「ウェブリブログ」は 2023年1月31日 をもちましてサービス提供を終了いたしました。 2004年3月のサービス開始より19年近くもの間、沢山の皆さまにご愛用いただきましたことを心よりお礼申し上げます。今後とも、BIGLOBEをご愛顧賜りますよう、よろしくお願い申し上げます。 ※引っ越し先ブログへのリダイレクトサービスは2024年1月31日で終了いたしました。 BIGLOBEのサービス一覧
とあるはてな社員の日記 - まっさらなサーバを30分で本番投入できるようにする
すこし前にはてなスターのリリースがされたのですが、サービス開始直後にありがちなことに、時々負荷で遅くなったり、アクセスしにくくなったりしてしまいました*1。これではいけない、ということで、すぐ次の日に、バックエンドのサーバを一気に10台近くまで増やして、おおむね快適に使える状態になっていると思います。この時に、新しいサーバをまっさらな状態から、だいたい30分程度で本番投入することができていました。これを、どのように実現したのかを軽く紹介したいと思います。 ちなみに、サービスの重さは、サーバ増強だけで済むものではなく、それ以降も、Javascriptが重い!とか、アプリケーションロジックで重いSQL を走らせてしまって遅いという問題は何回かありました。が、そこはインフラではなく、アプリケーションの問題で、アプリケーションの改善は、継続的に進んでいると思います。ので、今回は、インフラの話に限定
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
