タグ

2011年10月31日のブックマーク (11件)

  • DNS設定の確認方法

    そもそもDNSの設定がうまく変更できたかどうかをうまく確認できていない人をよくみかけます。設定の確認には、DNSの仕組みを知り、「再帰検索要求」と「非再帰検索要求」をうまく使い分ける必要があります。 コンテンツサーバの設定確認 「非再帰検索要求」でNSとなっているサーバの設定を個別に確認しましょう。こんな感じ、、、 委譲元の確認(djbdnsのツール推奨) % dnsq ns e-ontap.com a.gtld-servers.net(できるだけIPアドレスで) 2 e-ontap.com: 130 bytes, 1+0+3+3 records, response, noerror query: 2 e-ontap.com authority: e-ontap.com 172800 NS ns.e-ontap.com authority: e-ontap.com 172800 NS ns

  • Amazon Route 53とELBでAlias Resource Record Setを設定してZone Apexを実現 | DevelopersIO

    Amazon Route 53とは? Amazon Route 53とは、アマゾンが提供する分散管理DNSサーバーです。応答が早いとか、反映が早いとか、APIで設定できるとか、障害に強いとか、いろいろ特徴があるのですが、今回はRoute 53とElastic Load Balancingを使って独自ドメインのサブドメイン無しでも接続できるようにします。このサブドメイン無しの指定をZone Apexと言います(「mydomain.com」などの指定)。これを実現するには、Route 53のAレコードでAlias Resource Record SetとしてELBのドメイン名を指定します。このZone Apexは、最近できた機能でして、今までEC2のみでドメイン名を指定するときはZone Apexで指定することができませんでした。ですから、ブラウザから「www.mydomain.com」のよう

    takeshiyako
    takeshiyako 2011/10/31
    リファレンス
  • 始めてみよう、Amazon Route 53(1/2) - @IT

    設定ファイルと格闘せずにDNSを運用管理 始めてみよう、Amazon Route 53 並河 祐貴 株式会社サイバーエージェント 2011/6/23 Amazon Web Services(AWS)の「Amazon Route 53」は、API経由でDNSの運用管理を可能にするサービスです。Firefoxのアドオン「R53 Fox」を使って、その導入、設定を行う方法を紹介します(編集部) Webサイト運用に欠かせないDNS 今日、一般に公開されているWebサイトでは、IPアドレスを直接公開するケースはほとんどありません。多くのケースでは、ドメイン名(「google.co.jp」や「yahoo.co.jp」など)を公開し、ユーザーはそのドメイン名を基にブラウザでURLを入力したり、検索したりしてアクセスすることとなります。 そのためWebサイトの運用に当たり、ドメイン名とIPアドレスをひも付

    takeshiyako
    takeshiyako 2011/10/31
    リファレンス
  • Chrome、HTTPパイプラインに対応 | エンタープライズ | マイコミジャーナル

    Google Chrome runs web pages and applications with lightning speed. Chromeの最新開発版にHTTPパイプライン (HTTP pipelining)の機能が追加された。デフォルトでは無効化されている。「about:flags」を表示させると一番下に「HTTP Pipelining」の項目が表示されるため、試用する場合にはここから機能を有効にすれば良い。 HTTPパイプラインはHTTP/1.1で導入された機能。リクエストに対するレスポンスを待つ前に、複数のレスポンスを送信できる。うまく利用すると通信の高速化を実現できる。GET、HEAD、PUT、DELETEなど独立したリクエストに活用できる機能で、ひとつのTCP/IPパケットに複数のHTTPリクエストをまとめて詰め込んだ場合など、TCP/IPパケット数の削減にもつながる。

  • モバイルウェブ環境のHTTPSのチューニング « NAVER Engineers' Blog

    こんにちは検索サービス開発4チームの崔珉秀と申します。 インフラやシステムとの連携や統計のバックエンドを担当しております。 モバイルのウェブ環境はPCのウェブ使用環境とは色々な違いが有ります。 ネットワークの速度だけではなくバッテリーの効率を考えた仕組みなど、PCに比べリソースが十分ではないためモバイルブラウザの動作が異なっていることも有ります。 今回はモバイルのウェブApplicationにおけるSSL関係の性能に関する工夫の内容をQ&A形式で解説していきます。 Q. 何が問題でしたか? A. モバイルクライアント(iPhone, Android)のアプリケーションからのHTTPリクエストの応答時間に遅延の問題が有ります。 最初はweb access logからのslow response(1秒以上)のHTTPリクエストが結構ありました。 そのHTTPリクエストをprotoc

  • Our Mobile Planet

    Measuring Global Smartphone Impact Our Mobile Planet provides insights into smartphone usage and mobile attitudes. Use it to create custom charts that will deepen your understanding of the mobile consumer and support data driven decisions in your mobile strategy.

    takeshiyako
    takeshiyako 2011/10/31
    Google
  • memcachedのように使えるBloomFilter - walf443's blog

    YAPCでmalaさんの話を聞いていて、memcachedのようにお手軽に使えるbloom filterがあるとひょっとすると便利かもしれない、とふと思ったのでAnyEventつかって、Bloom::Fasterのwrapperを書いてみました。 https://github.com/walf443/p5-bloomd-server 以下のようなプログラムを書いてサーバーを起動します use strict; use warnings; use EV; use AnyEvent; use Bloomd::Server my $cv = AnyEvent->condvar; my $server = Bloomd::Server->new( capacity => 100_000_000, backupdir => '.', ulog => 'ulog', ); $server->run $c

    memcachedのように使えるBloomFilter - walf443's blog
  • Deploying Plack Web Applications: OSCON 2011

    Building a desktop app with HTTP::Engine, SQLite and jQueryTatsuhiko Miyagawa

    Deploying Plack Web Applications: OSCON 2011
  • Twitter 社採用面接受験記 - elm200 の日記(旧はてなダイアリー)

    1ヶ月ほどまえに、私はシリコンバレーを訪れたのだが、そのときサンフランシスコの社で Twitter の採用面接を受けてきた。結果は残念、ということだったのだが、その経緯について書いてみようと思う。 なぜ Twitter 社の面接を受けたのか。7月の終わりころ、私はシリコンバレーで働くにはどうすべきなのか、ということについて頭を悩ませていた。考えながらぼうっと Twitter のタイムラインを眺めていたのだが、Twitter が日エンジニアを求人しているという情報が飛び込んできた。おお〜、と思って軽い気持ちで職務経歴書を Twitter に送ってみたのだ。 相当数の人たちが職務経歴書を送ったはずだし、私は書類選考で落とされると高をくくっていた。ところが、数日してTwitter の人事担当者からメールがあり、電話面接をやるからいつがいいか?という。まさかの展開に私はやや慌てた。電話面接を

    Twitter 社採用面接受験記 - elm200 の日記(旧はてなダイアリー)
  • MySQL :: Oracle MySQL Developer Day Tokyo の模様をオンデマンド配信

    takeshiyako
    takeshiyako 2011/10/31
    当日のプレゼン資料
  • なぜ「DNSの浸透」は問題視されるのか:Geekなぺーじ

    DNSの浸透」という表現が結構よく使われています。 DNSに設定された情報を更新したけれど、その結果がなかなか反映されずに誰かに相談すると「DNSの浸透には時間がかかります」と説明されて納得してしまうという事例が多いようです。 しかし、うまく準備を行えば、実際の切り替え処理は、いつ完了するのかが不明な「DNSの浸透」を待つのではなく、事前に計画した時間通りに完了させることが可能です。 さらに、来であればDNS情報の設定者(ゾーン情報の設定者)は、いつまでに世界中のキャッシュが更新されるかを知ることができる環境にあり、それ以降も更新がされていなければ「何かがおかしい」とわかるはずです。 DNSにおける設定内容(DNSのリソースレコード)には、その情報をキャッシュとして保持し続けても良い期間であるTTL(Time To Live)という要素がありますが、TTLはDNS情報設定者が自分で設定