タグ

serverに関するaki77のブックマーク (295)

  • 画像配信の負荷分散も比較的簡単?(その2) - 最速配信研究会(@yamaz)

    http://d.hatena.ne.jp/yamaz/20060426 の続き.待ち行列理論に従うと遅延のないサービスを行うためには サーバの単位時間のリクエスト処理能力 > ユーザの単位時間のリクエスト数 という非常に単純なことを行えばいいことになる.「なにをあたりまえのことを...」と思われるかもしれないがもうちょっと付き合っていただきたい. ところでたいていのBlogや画像サービスのサービスURLはこうなってる. http://ホスト名/<ユーザ名>/ http://ホスト名/id?ユーザ名 http://ホスト名/ディレクトリ名/コンテンツ名 例で言うと下記のような感じだ. http://d.hatena.ne.jp/yamaz/ http://mixi.jp/show_friend.pl?id=128497 http://i.yimg.jp/images/search/head

    画像配信の負荷分散も比較的簡単?(その2) - 最速配信研究会(@yamaz)
  • 画像配信の負荷分散も比較的簡単?(その1) - 最速配信研究会(@yamaz)

    30万個ぐらいの静的ファイルを配信するサーバーの選び方 で静的な配信サーバに関することが述べられている. naoyaさんが公開されてるInside Hatena Bookmark's Backend の資料などを読むと、mod_perlなサーバーやMySQLサーバーの選び方の参考になったりするわけですが、世の中を見渡してみても、静的コンテンツ(画像とか)を配信するサーバーの指南書らしきものはなかなか見あたりませんでした。 なので、経験を元に書いてみることにします。 ということらしい.書いてあることはすべて同意だけど, つい3ヶ月くらい前まで 平均15k×1万URL×50億httpアクセス/day 平均4KByte×100万URL×3億HTTPアクセス/day な画像サーバと某所で向き合ってたため,ちょっとは役に立てるかもしれないと思ったので,私の経験を書いてみようと思う. 動画配信の負荷分

    画像配信の負荷分散も比較的簡単?(その1) - 最速配信研究会(@yamaz)
  • YappoLogs: tracとsvnwebとapache1.3.*でオープンソース開発環境の構築

    tracとsvnwebとapache1.3.*でオープンソース開発環境の構築 http://plagger.org/のようなtrac&svn環境を作りたかったので頑張ってみました。 Apache1.3系でtracとsvnwebの構築をしました。 例としてBloxabというプロジェクトを立ち上げる時の構築方法で書いていきます。 ディレクトリとかユーザー名とかは適時書き換える事。 tracの細かい事についてはドキュメントとかを参考に。 svnリポジトリの作成 $ svnadmin create /usr/local/bloxab/repos普通にリポジトリを作ります。 この作成したリポジトリは、apacheとtracdを動かすuid双方で読み書きできるしておく必要があります。 適切なchownとchmodをしておいて下さい。 以上 tracのインストール tracを動かす為の各種ソフトをインス

  • GIGAZINE - GIGAZINEのLoadAvarageを「27」から「2」へ下げた方法

    ここ3日間ぐらい超絶な重さだったのはサーバに物理的トラブルが発生したからではなく、単純に閲覧者数が満員御礼となり、各時間で倍増したためです。LoadAverageはひどいときで15分間の平均値「27.1」程度。瞬間最大風速だともっと高いです……明らかにまずい。 というわけで、Apacheのデフォルト設定で今までは大丈夫だったのですが、ついに高負荷サイト用の設定に変更せざるを得なくなりました。 そのため、実際に行った対処方法は以下の通り。1日30万PV近い動的サイトの高負荷を緩和させる方法として参考になれば幸いです。 まず大前提として、既にDNS逆引きや.htaccessの余計な読み込みなどは停止させていました。下記ページに書いてあることは実行済み。 @IT:Apacheパフォーマンス・チューニングの実践(1/2) この状態で負荷が15分平均で「27」になっていたわけです。 また、LoadA

    GIGAZINE - GIGAZINEのLoadAvarageを「27」から「2」へ下げた方法
  • PHPコードの実行を無料で高速化する「Zend Optimizer 3」

    サーバに入れるだけで実行時間を数%から数十%高速化することで有名な「Zend Optimizer」の最新版が出たようです。前バージョンの「Zend Optimizer」よりもさらに40%ほど高速化されているとのこと。 PHPコードの最適化モジュールの最新版「Zend Optimizer 3」リリース 日よりゼンドWebサイトにて無償ダウンロードサービス開始 http://www.zend.co.jp/press/2006/press0510.php ■「Zend Optimizer 3」の新機能 ・PHP5.1への対応 PHP5.1は、PHP5.0の高速化とともに多くの意欲的な新機能を提供しています。 ・「Zend Guard」によって暗号化されたPHPコードの実行 強力なコードセキュリティを実現する「Zend Guard」によって暗号化されたPHPコードの実行に使用します。 ・従来と比

    PHPコードの実行を無料で高速化する「Zend Optimizer 3」
  • cyano: 30万個ぐらいの静的ファイルを配信するサーバーの選び方

    naoyaさんが公開されてるInside Hatena Bookmark's Backend の資料などを読むと、mod_perlなサーバーやMySQLサーバーの選び方の参考になったりするわけですが、世の中を見渡してみても、静的コンテンツ(画像とか)を配信するサーバーの指南書らしきものはなかなか見あたりませんでした。 なので、経験を元に書いてみることにします。 弊社の画像配信サーバーには、平均10kbぐらい(たぶん)の画像が30万個ぐらいあって、それをDell PowerEdge 1750+lighttpdを使って配信してます。 以前は搭載メモリ1GBのサーバーを使っていたのですが、その時のvmstatがこのような感じ。 procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- r b sw

    aki77
    aki77 2006/04/27
  • サーバやPCのボトルネック箇所の簡単な見分け方(Linux編):佐野裕のサーバ管理者日記:ITpro

    前回はWindowsでのサーバやPCのボトルネック箇所の簡単な見分け方をご紹介させていただきましたが、要望がありましたので今回はLinuxの場合をご紹介いたします。 4つの主要ボトルネック要素の復習です。 サーバやPCには4つの主要ボトルネック要素があります。このいずれかがボトルネックとなった場合システム全体のレスポンスが低下します。 CPU使用率 メモリ使用量 ディスクI/O TCPコネクション数 Linuxにおいてはボトルネック箇所を以下のように見分けることができます。 1. CPU使用率 CPU使用率が常に100%に近い場合はCPUがボトルネックであることが判明します。CPU使用状況を簡単に調べるには3つの方法があります。「top」「w」「vmstat」コマンドを使う方法です。 -----------------------------------------------------

    サーバやPCのボトルネック箇所の簡単な見分け方(Linux編):佐野裕のサーバ管理者日記:ITpro
  • Apache 2.2でWebサイトをパフォーマンスアップ!(1/3) ― @IT

    ■ドキュメントキャッシュ機能の見直し メモリキャッシュやディスクキャッシュなど、HTTPコンテンツの動的キャッシュ機能が強化されました。開発バージョン時よりも安定性が向上し、Apache 2.2では実用的なレベルになっています。キャッシュ機能を用いることで、一般的にHTTPサービスの応答性を向上させることができます。 また、Apacheをリバースプロキシサーバとして利用する場合もキャッシュ機能を利用可能です。 ■プロキシ機能によるロードバランシングの実現 プロキシでロードバランス機能を実現するmod_proxy_balancerモジュールが追加されました。HTTPやFTPサービスはもちろん、Apache Tomcatなどのサーブレットコンテナとの通信で使われるAJP13プロトコルのロードバランス機能も提供します。 バランシングの制御は、「リクエスト回数」と「トラフィック量」の2つのアルゴリ

  • 1GServers.com :: 1G/10G/20G High Bandwidth Dedicated Servers

    High performance bare metal dedicated servers, with a network to match All servers include unshared 1Gbps, 10Gbps or 20Gbps ports Auto Deploy Servers Customize A Server High Bandwidth 10/20Gbps Unmetered Servers Unlock the potential of your online presence with our state-of-the-art dedicated server hosting services. 1GServers provides a high-performing, and robust environment for your data, accele

    aki77
    aki77 2006/02/12
    月額500円のレンタルサーバ
  • ADSL+自宅Linuxサーバ

    当サイトへのアクセスいただきまして、ありがとうございます。 恐れ入りますが こちら をクリックしてください(※該当のページへ移動します)。 管理人:しかぼう

  • ][Web Service][SOAP][WDSL]さくらインターネットで PHP5(CGI 版) + SOAP モジュール構築までのメモ - ryuzi_kambe の?D

    PHPPHP 5 の使用方法「自分でインストールして設定すれば可能。自分でインストールしたphp5を~/www/somewhereにphp.cgiという名前でコピーして、実行権を付けておく。」ビルドされた CGI 版 php バイナリの在処(.configure で何も指定しない場合)「また、従来のCGI版もソースを展開したディレクトリの「./sapi/cgi/php」として作成されています。」.configure ので指定した例「nazonoDiary - さくらのレンタルサーバでPHP5」$ ./configure --prefix=$HOME --with-config-file-path=$HOME/www/php5.ini --program-suffix=5 --with-pear=$HOME/share/pear5 --enable-force-cgi-redirect --

  • HTTP リクエストの処理完了までの所要時間をログに記録する

    Landscape トップページ | < 前の日 2005-12-27 2005-12-28 次の日 2005-12-29 > Landscape - エンジニアのメモ 2005-12-28 HTTP リクエストの処理完了までの所要時間をログに記録する 当サイト内を Google 検索できます * HTTP リクエストの処理完了までの所要時間をログに記録するこの記事の直リンクURL: Permlink | この記事が属するカテゴリ: [IIS] [Apache] [http] http リクエストの処理にかかった時間をロギングする方法のメモ。 集計や分析、パフォーマンス劣化の監視などで活用するため、http サーバ側でリクエストを処理したあとレスポンスを返すまでどれだけ時間がかかったかを記録したい。 所要時間などの値は http サーバ上で動くアプリケーション側でロギングする仕組みを作るの

  • FrontPage - (・∀・)イイ!!Memo

    (・∀・)イイ!! Memo 〜ネットワークとプログラムは芸術ナリ〜 仕事、プライベート、学校、それぞれで 学んでいる技術を1つのページに記録・統合し、共有するのが目的。 でも、個人的なメモというスタンスでいっています。 2006/03/26 Pukiwiki 1.4.6 になりました。 2006/02/21 wikiがぶっ壊れたため、ページの作成日が2006-02-21になってしまった。 2005/06/25 カテゴリにCを追加。 2005/06/13 Adsenseを試験的に導入、見た目変更。 2005/05/24 vi,Mobile,Perlカテゴリ追加。 2004/11/07 Pukiwiki 1.4.4 になりました。 2004/12/23 カテゴリを整理。 現在の記事の数。割と読める記事は20コぐらい。 カテゴリ † Program プログラミング全般。および下記カテゴリに分類

    aki77
    aki77 2005/06/09
    lampチューニング等
  • sanonosa システム管理コラム集

    WEBサイトの作り方について述べられた文献は多いですが、WEBサイトの閉じ方について述べられた文献は滅多に見ません。そこで今回は私が考えるWEBサイトの閉じ方について考えてみたいと思います。 【WEBサイト閉鎖までに行うこと】 流れとしてはこんな感じになるでしょう。 1.まず最初に「WEBサイトを○月○日に閉鎖します」というアナウンスを出す。 2.閉鎖日になったら「このサイトは○月○日に閉鎖しました」というアナウンスに切り替える。(WEBサーバごと切り替えるのが良し) 3.サービスに使っていたサーバを適切に処理する。 4.その後閉鎖告知ページを残すのであれば、そのページが残るように適切に処理する。 WEBサイト閉鎖はネガティブな作業であるためあまり気合が入らないかもしれませんが、最後まできちんと気を抜かずにがんばりましょう。 【閉鎖告知用サーバでよくあること】 ・COPYRIGHT表記が古

    sanonosa システム管理コラム集
  • レンタルサーバー、ホスティング 比較 | レンタルサーバー完全ガイド

    インプレスR&Dが運営。激安・格安サーバーから高機能サービスまで国内サーバーホスティング1600件以上からレンタルサーバーを比較・検索お詫びと訂正 8月30日発売『レンタルサーバー完全ガイドVol.14』の「レンタルサーバーニュース Pick Up」において掲載内容に誤りがございましたのでお知らせいたします。 32ページ下段左「サイバートラスト、年次分割購入可能な有効期限3年のサーバー証明書を発売」におきまして、証明書の名称を「SuperServer3年割」としておりますが、正しくは「SureServer3年割」です。ご迷惑をおかけした読者の皆様ならびに関係各位には深くお詫び申し上げます。 >> 続きを読む