極めて稀とはいえ、Linux もハングすることはある。 ハードウェア自体には何ら異常はなく、 リセットスイッチを押したら正常に再起動してしまって、 何が問題だったか分からずじまい、という経験は誰にでもあるのではなかろうか。 原因不明のハングが全く無くなるのが理想ではあるのだが、 ハングして止ったままになるよりは、 自動的にリセットがかかって再起動してくれたほうがいい、という場合もあるだろう。 もちろんハードウェア障害が原因でハングしてしまった場合は、 リセットスイッチを押しても解決にはならない。 再起動を試みることにより、障害がより致命的になる可能性もあるので、 ウォッチドッグ・タイマーを設定する際は、 「止ったまま」と「自動再起動」とどちらがマシか天秤にかける必要がある。 そんなとき、 ウォッチドッグ・タイマー (watchdog timer) が便利。 一定時間 (例えば 30秒) 放
こんにちは！やまもと＠テスト番長です。 TestingGeekという耳障りの良い名前のサイトをご存知でしょうか？ 総合的にテストの話を取り扱っており、それでいて読みやすいサイトです。 そこのTemplatesのコーナーにWeb Application Testing Checklist という便利そうなものがありましたので、日本語にしてみました。 ちょっとそのままだと物足りない感がありますが、テストポリシー作成の叩き台に使ってみるのも良さそうですね。 この手のリストを他にもご存知の方がいらっしゃれば、是非ご一報ください。 1. 機能テスト 1.1 リンク 1.1.1 記載された通りの先に遷移するか 1.1.2 どこからもリンクされないページは存在しないか 1.1.3 全ての外部リンク 1.1.4 参照しているサイトおよびメールアドレスはハイパーリンクになっているか？ 1.1
すこし前にはてなスターのリリースがされたのですが、サービス開始直後にありがちなことに、時々負荷で遅くなったり、アクセスしにくくなったりしてしまいました*1。これではいけない、ということで、すぐ次の日に、バックエンドのサーバを一気に10台近くまで増やして、おおむね快適に使える状態になっていると思います。この時に、新しいサーバをまっさらな状態から、だいたい30分程度で本番投入することができていました。これを、どのように実現したのかを軽く紹介したいと思います。 ちなみに、サービスの重さは、サーバ増強だけで済むものではなく、それ以降も、Javascriptが重い!とか、アプリケーションロジックで重いSQL を走らせてしまって遅いという問題は何回かありました。が、そこはインフラではなく、アプリケーションの問題で、アプリケーションの改善は、継続的に進んでいると思います。ので、今回は、インフラの話に限定
こんにちは！ やまもと＠テスト番長です。 ウノウラボのコメント欄まで熟読されている慧眼な方は既にお気づきかもしれませんが、WebLOADという商用の負荷テストツールがオープンソース化され、無料で利用出来るようになりました。 http://www.webload.org/ 以前自分が書いた WEBアプリのテストに必須なツール7種のエントリにsaltysonicさんがコメントで教えてくださいました。ありがとうございました！ souceforge.net を探してみたところ、見つかりました。 WebLOAD 早速触ってみていますが、さすがに元商用だけあって多機能なようです。 関連記事も探してみたところ、以下のものが見つかりました。 http://news.earthweb.com/ent-news/article.php/3670176 http://www.testingreflec
2007年05月11日18:45 カテゴリiTech あなたのページを最速にする14の掟 人気Webサイトの管理人、必読。 紹介ページ: 14 rules for fast web pages (Skrentablog) PPTのスライド: http://www.web2expo.com/presentations/webex2007/souders_steve.ppt 実は、これらはYahoo!の"Chief Performance Yahoo!"(本当にそういう役職名)であるSteve Soudersによる以下のblog entriesをまとめたもの。 Performance Research, Part 1: What the 80/20 Rule Tells Us about Reducing HTTP Requests Performance Research, Part 2:
Posted by nene2001 at 15:56 / Tag(Edit): amazon ec2 rightscale / 3 Comments: Post / View / 0 TrackBack / Google Maps ETech07 - AmazonEC2を無料で試せる RightScale -たたみラボ- 相変わらずいい情報をありがとうございます。 早速試してみましたが、RightScaleすごくいいです。 何がいいって、やっぱりWebからサーバイメージを生成して、イメージの作成日時等まで含めてS3への登録まで、Webからボタンポチでできてしまうのがすごくいいです。 今まではいちいちSSHで接続して、ややこしいコマンドラインコマンドを打たなければ（シェル化はしてましたが、それも自分でやんなきゃだし）イメージの作成ができず、またイメージのS3登録まであわせ
という感じになりました。 やっぱり、プロセスを常駐させた方が大分早いようです。 CGIでのCとPerlの実行速度差に比べ、PerlのFastCGIがCのFastCGIと比べて遜色ないのは、Perlはプロセス起動時に中間コードにコンパイルされるらしいのですが、FastCGIだとその中間コードがプロセスが落ちないため保持されるので、リクエスト毎のコンパイル時間が不要になるためらしいです。 FastCGI職人からの聞きかじりですが...。 C-CGIとPerl-FastCGIの間の比較は、所詮環境変数表示だけのプログラムですので、複雑なプログラムになると実ロジック部分のCとPerlの実行速度差でどうなるかは判りませんが、今回は環境変数表示だけのプログラムでの結果なので、プロセスは小さいんじゃないかと思います。 なので、プロセスが小さければCGIでも...というのは、？がつきました。 （と
Assurer - サーバテスティングフレームワーク #0 Posted by Gosuke Miyashita Fri, 05 Jan 2007 15:44:44 GMT 構築したサーバがちゃんと動作するかどうかのテストを自動化したいなー、とスクリプトを書こうと思ったのですが、Perler としてはここはやはり、Plagger とか Archer みたく、プラガブルで YAML で設定書けば OK みたいのを作るべきだろう、ってことで、Assurer (SVN) というサーバテスティングフレームワークをでっちあげてみました。 テストのことを Quality Assurance とか言ったりするし、Plagger や Archer が er で終わってるので、それに倣って命名してます。 今のところ Plagger や Archer からコピペして、ごく簡単な HTTP テストプラグインをつ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
