Perl5 における HTTP Client library の選び方 - tokuhirom's blog
HTTP::Lite依存すくないのがうり。速度重視じゃないし、機能もすくない。インターフェイスも、LWP にくらべるとナマナマしいかんじ。 CPAN module をいれたくなくてしょうがない場合にのみつかうべき。LWP の存在が保証されていないような環境に配布したい場合に bundle して配布するとかが主用途。 (実際に HTTP::Lite は cpanminus に bundle されている) LWPデファクトスタンダード。連鯖でもたいがいはインストール済だし、とりあえず LWP つかっておくべき。 どれつかうか迷ってる人はとりあえず LWP つかっておけばよい。 WWW::Curl速度がクリティカルな場合には WWW::Curl つかうとよいんだけど、相当数のリクエストをなげるよほど大規模なクローラでもないかぎりは、LWP で十分。 どうしてもどうにもならないときにだけつかうよう
Kazuho@Cybozu Labs: Parallel::Scoreboard でワーカープロセスをモニタリングする方法
cho45 さんの Plack::Middleware::ServerStatus (Starman や Starlet で Apache の mod_status 相当の情報を得られるようにする - 冬通りに消え行く制服ガールは、夢物語にリアルを求めない。 - subtech) に続き、昨日 kazeburo さんが「StarmanやStarletでmod_statusっぽい情報を得る簡易版Plack::Middleware::ServerStatus - blog.nomadscafe.jp」というエントリを書かれていらっしゃいましたが、ウェブアプリケーションサーバに限らず、複数のワーカープロセスが動作するシステムにおいて、それらの状況をモニタリングするためのスコアボードがほしい、というケースはよくあることだと思います。 また、プロセス名を使う方法は、他の監視ツールとの相性が悪い、プロ
Re: LLごとの標準的なHTTPクライアントで100リクエスト投げた時のベンチマーク - tokuhirom's blog
http://subtech.g.hatena.ne.jp/mala/20100531/1275322139 mala のベンチマークにおいて、気になる点がある。それは、「HTTP プロトコルにたいするベタなライブラリ」と「HTTP プロトコルをつかうための高レベルなライブラリ」のベンチマークがまじっているという点。 前者は ruby/Net::HTTPpython/httplibperl/Net::HTTPにあたるものであり 後者は ruby/open-uripython/urllib(urllib2)perl/LWP::Simpleにあたるものである。 で、ruby/Net::HTTP と perl/LWP::Simple をならべて、LWP が遅いといわれてもなんだろうから、かけている部分のベンチマークスクリプトをおいておく。 しかし、それにしても curl はやいね。 Python
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Kazuho@Cybozu Labs: REST におけるトランザクションについて (Re: Web を支える技術)
といいつつ、ひとつだけ理解できないというか、納得できないところが。トランザクションのところがなんだかRESTっぽくないのがすごく気になる Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ)(山本 陽平) - ただのにっき(2010-04-23) 「Web を支える技術」は自分もとてもいい本だと思う (教科書としてすばらしいし復習用としても読みやすいのでイイ) のですが、トランザクションの所だけは分かりづらいなと感じました。その原因は、atomic transaction で解決できる課題を例として使っているという点と、トランザクションと更新クエリのレイヤ分割がされていない、という２つの点によるものではないでしょうか。 HTTP 上でトランザクションを表現する必要があるケースのほとんどは、atomic transaction ではなく
yohei-y:weblog: Webを支える技術ジュンク堂トークセッション（第4回卓人の部屋）総括
ブログを書くまでがトークセッションです、と自分で言ってしまった手前書かないわけにはいかなくなってしまったわけです。 第4回卓人の部屋でしゃべってきました。 池袋のジュンク堂に行くのは2回目です。前回はRWSのPOPを置きに行ってきました。 ジュンク堂の6Fでは高橋会長の本を全力で応援するフェアというのをやっていた。 Webを支える技術 ── HTTP、URI、HTML、そしてREST山本 陽平技術評論社 2010-04-08 とりあえずKPTで振り返ってみました。 Keep トークセッションを満員御礼にできた taiさんが来てくれてた 高橋会長にたくさん話をふった いろいろな人と名刺交換した shuyoさんと久々に会った なんばさんに超久々に会った（そして××な話を聞いた） yojikさんやshot6さんと初めて会えた 私服の長田さんに会えた 発売日に増刷がかかった Problem 和田さ
WebMemcacheというWebサービスを作った - hitode909の日記
MemcachedみたいにキャッシュしてくれるWebサービスがあれば便利そうだと思ったので，作ってみた． おもむろにHTTPアクセスすると，JSONをくれる． set, get, delete, statsのAPIがある．使い方は上のリンク先に書いた．リンク先のコードをクリックするとその場でXHRして試せる． キャッシュなので，Webページから使って便利みたいな感じじゃなくて，何かキャッシュを利用したいプログラムから使う． Rubyから値を複数setして同じ値をgetする例．このように，複数同時に操作できる． require 'net/http' require 'open-uri' http = Net::HTTP.new('webmemcache.appspot.com') response = http.post('/set', 'pi=3.14&e=2.7&namespace=te
2010年代には Apache の mpm_prefork とか流行らない (もしくは HTTP keep-alive のメリットとデメリット) - kazuhoのメモ置き場
HTTP の持続的接続の功罪について はじめに、HTTP の持続的接続 (keep-alive) のメリットについて。持続的接続を使うメリットは、以下の２点。 TCP 接続の確立にかかる時間の節約*1 TCP の接続と切断に必要な資源 (CPUとネットワーク) の節約 ウェブブラウザ〜データセンタ間の通信で、持続的接続を使う理由は、このうちの前者。特に太平洋を超えるようなケースだと、TCP 接続に0.2秒とかかかるので、メリットが大きい。 一方、持続的接続のデメリットは、 接続が切断されるまでの間、その接続を維持するためにコストがかかる (主としてメモリが無駄になる) という点になる。特に、１プロセス１コネクションを前提とするアーキテクチャ (例: mod_perl) だと、メモリの無駄使いが、とてもひどいことになる。 そこで、ブラウザからの接続を受ける HTTP サーバとアプリケーション
URLとURIの違いとは？ パーツの構造・名称・意味も大解説！ | 初代編集長ブログ―安田英久
URL（Uniform Resource Locator）とURI（Uniform Resource Identifier）の構造の違いはご存知ですか？ Webページのアドレスを指す場合はどちらを使うべきなのでしょう。URLを分解して「https:（スキーム）」「#（フラグメント）」「?（クエリ）」「パス（path）」などの名称・意味についても解説します。 今日は、ノウハウというよりは、豆知識を。「URL」という呼び方と「URI」という呼び方がありますが、どう違うのか、あなたはご存じですか？ Webページのアドレスを指す場合は、どちらを使うべきなのでしょうか。 URLとURIは何が違うのか結論から言うと、URIとURLは同じものではありません。「URI」のほうが広い概念で、「URL」はURIの部分集合です。同様の仕組みに「URN」というものがあります。 その3つを別のものにたとえてわかりや
HTTPリクエスト/レスポンスとは? HTTPヘッダーを理解しよう | 初代編集長ブログ―安田英久
今日は、少し技術的な話ですが、Web担当者も知っておくといい知識を。テーマは「HTTPヘッダー」です。知らなくてもWebサイトは作れますが、知っておくとサイト上での仕組み作りの視野が広がるかもしれません。 ブラウザでWebページを表示するときに、ブラウザはWebサーバーと通信しています。そのときに使われるのが「HTTP」というルールです。 HTTPは「HTTPリクエスト」と「HTTPレスポンス」に分けて考えます。ブラウザがサーバーに「このページを見たい」と頼む通信が「HTTPリクエスト」で、そのリクエストに応えてサーバーがブラウザに返す通信が「HTTPレスポンス」です。 まず、ブラウザ → サーバーの「HTTPリクエスト」から説明しましょう。 HTTPリクエストはブラウザが送るものですから、HTTPリクエストを作るのはブラウザです。サーバーは、受け取ったHTTPリクエストの内容からどんな情
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.machu.jp/posts/20100416/p01/
Studying HTTP