タグ

serverに関するwozozoのブックマーク (51)

  • Benchmarking Go and Python Web servers

    To build the Web applications I use mostly Python. An year ago I started learning Go, mainly for fun. In the meantime it turned out that I have to rewrite some old CGI application written in C, which have worked with thttpd server in chroot mode. I started searching for a tool with which I could write a standalone web application with embedded web server, easy to chroot. At the same time I started

  • x.com

    wozozo
    wozozo 2011/03/10
    sakura
  • 非同期Webサーバーならばcycloneがよさげ - スコトプリゴニエフスク通信

    まだ深くソースコードを読めていないので「非同期Webサーバー」という言い方が正しいかどうかは自信がない。https://github.com/fiorix/cyclonecycloneはtornadoと非常によく似たAPIをもっている。例えば、お馴染みのHello Worldならば次の通り。 # -*- mode: python -*- # helloworld.tac import cyclone.web from twisted.python import log from twisted.internet import reactor from twisted.application import service, internet class MainHandler(cyclone.web.RequestHandler): def get(self): self.write("He

  • Apache, Cache-Control, 304, 大型サイトで静的ファイルを無駄なく配信 | バレで昼寝

    以前にも書きましたが私は某ポータルサイトのシスアド、兼プログラマをしています。月々1億から3億ページビューを裁いていますが、システムの一番大きなコストはトラフィックです。 100MBit専有とまでなると月40万は軽く行きます。そこでとにかくページビューをあげながらもトラフィックを減らそうと日々努力しています。この記事の目的はハウジングサービスからアマゾンのクラウドフロントに移行した成功例(または失敗例)について書いていきます。 まず、第一回は既存のシステム(静的ファイル用のサーバ)について簡単に説明します。長年、経験を積みながら行った設定です。あくまでも、サーバのスペック、サイトの用途によっても違ってきます。 OS: Gentoo HTTP Server: 最近lighttpdからまたApacheへ ※lighttpdはものすごくライトウェイトだが、バグの対応が遅い、ガンバレMade

  • CakeMatsuriTokyo2009で事例紹介をしてきました - UNIX的なアレ

    nanapiでの事例紹介 2009年10月30日、31日に開催されたCakeMatsuriTokyo2009でサービスの事例紹介をしてまいりました。 今回の発表は、nanapiでcakephpを使っている部分があるのでそのあたりの紹介をしています。cakephpユーザーとしてはまだ半年足らずの初心者ですが、少しでも参考になれば幸いです。 以下は発表したときの資料です。 ポイントはcakephpを使う場所と使わない場所を選定するというところでしょうか。cakephp以外の技術では、lsyncdあたりにもちょっとふれています。 twitterで見ても、参加者の満足度はすごく高かったようですね。これもスタッフの方のがんばりがあったからこそだと思います。 午後は別の用事があり、途中までしか参加できなかったのが残念でした・・・次こそは! 関連リンク http://matsuri.cakephp.jp

    CakeMatsuriTokyo2009で事例紹介をしてきました - UNIX的なアレ
    wozozo
    wozozo 2009/11/12
    nanapi
  • Debianでサーバ色々メモ - tgbtのはてな出張所

    マルチポスト元→http://exth.net/~tgbt/wordpress/2009/10/08/2593/ 備忘録というかまぁメモ. Debianでサーバを構築する機会があったので,適当に残しておく. なんだかんだ言ってそれなりに時間がかかっている.一通り構築済のパッケージとかがあれば楽なのにね!とか思わないでもない. FireWall iptablesを久々に書いた.色々と忘れていた.ゲートウェイじゃないのでINPUTとOUTPUTにいくつかACCEPTとDROPを書いて完.あえて言うなら,ちゃんとログを吐かせるのが重要かしら. http://www.h7.dion.ne.jp/~maruyosi/pasocom/debian_trial_56.html iptablesのsave restoreがちょっと前のDebianと最近のDebianでは違うらしいね.ちょっと悩んだ. We

    Debianでサーバ色々メモ - tgbtのはてな出張所
  • 自分のサーバの性能を知っておく - tokuhirom's blog

    http://github.com/kazuho/manymanythreads ↑kazuhoさんがCで書いたエコーサーバーと、そのベンチマークツールによって、自分のサーバでどんぐらいのQPSがでるのかがわかる。 たとえば自分のマシン(SC440)だと ./testechoclient -c 1 -n 1000000 -f -p 5050で、 77906.624081 reqs./sec. (1000000 in 12.835879 seconds)ぐらいでる。 一番単純なエコーサーバーをうごかしたときの性能を把握しておくことによって、どのぐらいの速度がでてしかるべきなのかが把握できるようになるという。 【追記】 ここで知った echo server の限界性能をもとに、その後、自分がなにかサーバ等を書いた場合に最適化したらどのぐらいの速度がでるかを予測できる(経験が必要だとおもうけど)

  • HanasanWiki

  • 自宅サーバーの構築 - 自宅サーバーの構築

    はじめに 最近はLinuxやBSDなどのPC-UNIXの普及および、ブロードバンドでの常時接続により自宅でインターネットサーバーを構築するのも手軽にできるようになってきました。 そこで私も勉強と趣味を兼ねて、自宅でインターネットサーバーを構築しました。せっかく苦労して構築したのだからその手順をまとめておきたいと思い、このページを作ることにしました。ただ前にも一度、FreeBSDで自宅サーバーを構築した時に、手順を同じようにまとめましたが完成までには至りませんでした。そういうこともあるのでこの記録も完成するかどうか分かりません。でも、今回こそはと決意も新たに頑張ります。(誰に対して頑張るんだ?) この自宅サーバーはマシンにApple Power Book G4 Titanium、OSにDebian GNU/Linux 4.0(etch)を使って構築しました。 ここでの構築手順は、いろいろな

  • HTTPプロトコルパーサのオーバーヘッドは18%以下という話 - kazuhoのメモ置き場

    「テキストプロトコルは遅くないよ」という話 - kazuhoのメモ置き場に関するの具体的な話。 Kazuho@Cybozu Labs: 「サーバ書くなら epoll 使うべき」は、今でも正しいのかを書く際に自作したベンチマークツールがあるのですが、それを使ったベンチマーク結果をid:tokuhiromがhttp://d.hatena.ne.jp/tokuhirom/20091001/1254355956にまとめてくれている*1。それについて、ちょっと補足と実測値を。 まず、コメントにも書いたんだけど、サーバのスループットを測る際にはTCP接続を多重化する必要があるので、-a 100 -n 100 -f *2のようなオプションでベンチマークをとってください。あと、ローカルホスト上での測定か、ホスト間での測定か、によっても当然結果は変わる。 自分の環境 (linux 2.6.18-028sta

    HTTPプロトコルパーサのオーバーヘッドは18%以下という話 - kazuhoのメモ置き場
  • はやいTCPサーバを書く際に忘れがちなこと - kazuhoのメモ置き場

    はやいTCPサーバの書き方 - nyaxtのPC作業ログ で id:nyaxt さんが書いてらっしゃるように、 epoll や kqueue を使う TCP_NODELAY, TCP_DEFER_ACCEPT *1 等を活用する TCP パケットを意識する I/O システムコールの回数を最小にする sendfile といったあたりは、確実にやるべきことだと思います。一方で、TCP 関連以外のオーバーヘッドが実は結構あって、 接続のタイムアウト処理 ログの出力 メモリの確保や解放をやらない あたりにも気を配る必要がある、と思います。 接続のタイムアウト処理については、以前 Kazuho@Cybozu Labs: 高速なCometサーバを書いてみた件 に書いたように、ビットアレイのリングバッファを使うのがベストだと思います。 ログの出力について、複数行を1回のシステムコールにまとめてもいいかど

    はやいTCPサーバを書く際に忘れがちなこと - kazuhoのメモ置き場
  • とってもやさしいリバースプロキシVarnishの使い方 - ¬¬日常日記

    RubyのウェブアプリケーションフレームワークRamazeがとってもとっても素敵なので、ただいま実験としてささいなものを作成しております。HTTPdには今話題のthinを使おうかな、と思っているのですが、こうなると考えなければならないのがリバースプロキシですよね。"reverse proxy rails" あたりで検索すると真っ先にapacheの設定方法が出てくるわけですが、なんでもapacheというのもどうかな、と思いました。設定が煩雑になりますしね。そこでリバースプロキシである varnish を試してみました。varnishに関するドキュメントはあまり多くないのですが、varnish はとっても簡単なので素晴しいと思います。せっかくですから、varnishに関する設定方法などを簡単にまとめておきたいと思います。なお、私はサーバであっても ubuntu を使っておりますので(手抜き!)

    とってもやさしいリバースプロキシVarnishの使い方 - ¬¬日常日記
  • ロケスタの新サービス「ナナピ」で使った技術を紹介してみるよ - UNIX的なアレ

    http://nanapi.jp 日2009年9月1日、株式会社ロケットスタートの新サービス「ナナピ」をリリースしました。 「ナナピ」はライフレシピと呼ばれる生活の便利な知恵や、ノウハウをみんなに共有してしまおう!というサービスです。 なんとか予定通り9/1にリリースをすることができました。すでに投稿数が160ほどあり、生活に便利な内容が投稿されています。 http://r.nanapi.jp/162/%E3%81%82%E3%81%8F%E3%81%B3%E3%82%92%E6%AD%A2%E3%82%81%E3%82%8B%E6%96%B9%E6%B3%95/ http://r.nanapi.jp/158/%E3%83%AC%E3%83%99%E3%83%AB%E3%81%8C%E4%B8%8A%E3%81%8C%E3%82%8B%E6%8C%A8%E6%8B%B6%E3%81%AE

    ロケスタの新サービス「ナナピ」で使った技術を紹介してみるよ - UNIX的なアレ
  • ジョエル・スポルスキー氏の「StackOverflow.com」、構成はわずか4台のPCサーバ

    元マイクロソフトのプログラマで書籍「Joel on Software」などでも知られる著名なプログラマであるジョエル・スポルスキー氏が立ち上げた、プログラマ向けのQ&Aサイト「Stack Overflow」。 月間1600万ページビュー、300万ユニークビジターのこのWebサイトがどのような構成になっているのか、Webサイト「High Scalability」の記事「Stack Overflow Architecture」に分かりやすいまとめが掲載されていました。 最大の特徴はスケールアップ型 Stack Overflowの特徴は2つあります。1つはスケールアップ型のアーキテクチャだということです。現代のマルチコア、大容量メモリ、パラレルプログラミング技術においては、スケールアップ型のアーキテクチャも重要な選択肢だと記事では説明しています。 その説明の通りStack Overflowでは、

    ジョエル・スポルスキー氏の「StackOverflow.com」、構成はわずか4台のPCサーバ
  • SERVERxSERVER β | あなたのウェブサーバを24時間監視します

    サーバ24時間運用監視システムSERVERxSERVER(SVSV)。落ちたら困るWebサーバを監視しましょう。サーバに障害が発生時PC/携帯メールにアラート通知いたします。メールアドレスとサーバ名(またはIPアドレス)を登録すると、すぐにWeb(80番ポート)の監視を開始します。 ログインすると、WEB以外のポートを指定できます。また、新たにサーバ名(またはIPアドレス)を追加することもできます。 監視した結果、異常を見つけると登録したメールアドレスに通知します。

    wozozo
    wozozo 2009/08/02
    監視
  • ユーズドドメイン ← Neo Inspiration

    オールドドメイン とはチョット違いますが、 いわゆるユーズドドメイン(ドロップドドメイン?)ってやつを 検索するサイトを作ってみました。 Used-Domain Checker ドメインエイジは流行らないよとか昨今聞きますが、 基的にユーズドドメインは最初からPRがついてるとか そんなんじゃなくて、以前違うサイトがあったというだけのものです。 なので、ちょっとだけリンクが付いてたりしますが、 基的には すぐクローラーがくるということ以外には 大して効果があるわけではありません。 それでもサテライトサイト作る時とか、 SEOをちょっとでも意識するのであれば すぐクローラーが来るのは便利なので、 こういうのを使ってもいいかなとおもって作りました。 ユーズドドメインチェッカー

  • ウノウラボ Unoh Labs: プロセスの監視を行う デーモン monit

    こんにちは satoです。 monitは プロセスの監視を行うデーモンです。 条件とそれに伴うアクションを指定することができます。 条件とは例えば以下のようなものがあります プロセスが起動していなかったら 特定のプロセスのメモリの使用量が あるサイズを超えたら 特定のプロセスのCPUの使用率が 50%を超えている状態が 10分続いたら 特定のポートに接続できなくなったら など アクションには以下のような物があります 起動、再起動する アラートメールを送信する ユーザスクリプトを実行する など これらを組み合わせて、プロセスの監視を行います。とくにユーザが作成したプログラムの監視などに効果を発揮します。インストールは RedHat系なら yum install monit で入ります。(CentOSや商用のRedHatはrpmforgeをリポジトリとして追加する必要があります) 主な設定ファ

  • 30 Linux System Monitoring Tools Every SysAdmin Should Know

    How do I Find Out Linux CPU Utilization? 2. vmstat – Virtual memory statistics The vmstat command reports information about processes, memory, paging, block IO, traps, and cpu activity. # vmstat 3 Sample Outputs: procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 0 2540988 522188 5130400 0 0 2 32 4 2 4 1 9

    30 Linux System Monitoring Tools Every SysAdmin Should Know
  • » セキュアなサーバを作るために最低限やっておくこと: エスキュービズム ラボ Blog

    Recent Entries セキュアなサーバを作るために最低限やっておくこと Yahooキーワード抽出APIライブラリ テスト駆動開発 (test driven development: TDD) のすすめ GoogleAnalyticsAPI on EC-CUBE 土日で作るコンパイラ OPEN ERPに挑戦3 OPEN ERPに挑戦2 OPEN ERPに挑戦 ERPはたくさんあれど・・・ OpenGLで3D、やってみよう Recent Comments No Responses. Recent Trackbacks テスト駆動開発 (test driven development: TDD) のすすめ 06/11 » Yahooキーワード抽出... みなさんはサーバを管理するときに、何を一番気にしますか? 人によって程度の差はあるのでしょうが、誰もが気になるのが「セキュリティ」でしょ

  • ニコニコ大百科のアーキテクチャ - グニャラくんのグニャグニャ備忘録@はてな

    Twitter mongrelP: @tasukuchan グニャラくーん、ニコ百の鯖がEeePCという話が持ち上がってますがただの監視用ですよね(しんぱいそうなめでみている) http://twitter.com/mongrelP/status/1524183917 ニコニコ大百科のアーキテクチャについてメモしておきます。 当は、このネタでRuby Kaigiに申し込もうと思ったけど、すっかり忘れていたのでエントリを起こしておきます。Rubyあんま関係なかったし。 全てのリクエストを受付、セッション情報も保持するEeePC 次世代サーバプラットフォーム EeePC ニコニコ大百科宛ての全てのリクエストは、全てEeePCに送られます。 実物の写真を載せておきます。 EeePCは2台稼動しており、1台はホットスタンバイです。 EeePCは、SSDとUPSを備えた次世代サーバプラットフォーム

    ニコニコ大百科のアーキテクチャ - グニャラくんのグニャグニャ備忘録@はてな