ネットワーク越しリトライ考 - その手の平は尻もつかめるさ
ここ最近では何らかのインターネットサービスを構築・運用するにあたって、ネットワーク越しのリトライを考えることは避けられなくなりつつあります。 micro services のようなアーキテクチャを採用している場合はサービス間のメッセージのやり取りはまず失敗する前提 (つまりリトライをする前提) で組む必要がありますし、たくさんのクライアントがいてそのクライアントが定期的に何かを処理してセントラルにデータを送ってくる IoT のようなシステムを構築する時もその処理のリトライをよく考える必要があります。 というわけで「ネットワーク越しのリトライ」についてここ最近考えていることをざっくりと書き留めるものであります。 前提 リトライをする側をクライアント、リトライを試みられる側をサーバと呼称します リトライにおいて、サーバおよびネットワークはクライアントよりも弱者です クライアントはリトライをコン
HP ProLiantサーバーのBIOSの時間を短縮する - 仮想化通信
ここ最近（G6世代以降）のHP ProLiantサーバーでは、各種テストや初期化などのいわゆるPOST時間がかかるようになり、2分前後になっています。G5世代（DL380 G5のデフォルト設定で計測）が1分前後で完了していたことを考えると、約2倍というのはちょっと辛いです。本番環境など、基本的に動かしっぱなしの環境では問題になりませんが、検証環境では再起動が多く発生する場合があるため、待つのが退屈になります。 そこで、RBSU（BIOSメニューのHPサーバーでの呼称）などの設定を変更して、起動時間の短縮ができるか試してみることにしました。サーバーにはHP ProLiant MicroServer Gen8サーバーを使用しました。 素の状態 素の状態のBIOS起動時間は2分3秒ほどでした。長いです、長い。 Power On Logoオプションを無効化 まずはグラフィカルなBIOS画面を表示す
なぜあなたがウェブサイトをHTTPS化するとサイトが遅くなってユーザーが逃げていくのか - 射撃しつつ前転 改
完全に釣りタイトルですけど中身は真面目に書くよ。 近年、ウェブサイトのHTTPS化が流行のようになっている。私の知る限り、Googleの各種サービスやTwitter、Facebookなどが完全にHTTPSで通信を行うようになっている。HTTPS、つまりSSLによる通信の暗号化によって、ユーザにこれまでよりも安全なウェブサイトを提供できる。 しかし、あなたが作っているサイトをふと思いつきでHTTPS化してしまうと、たぶん、これまでよりもサイトが遅くなる。ここでは、HTTPSで通信する場合の問題を解説する。 なぜ遅くなるのか HTTPで通信する場合、クライアントがサーバへと接続するためにはTCP/IPの3ウェイハンドシェイクという手順が必要になる。めんどくさいのでここでは詳しくは説明しないが、要するにクライアントがリクエストを投げる前にパケットを１往復させないといけないのである。パケットの往復
ローカルタイムの設定
ローカルタイムの設定 [サーバの実験室 Slackware] 作成 : 2002/12/31 "サーバの実験室"の検索 システム時間がヘン date を実行すると、"Tue Dec 31 17:30:00 ifLocal time zone must be set -- see zic manual page2002" と表示される。 ログインしたときに表示される Last login メッセージも、"Last login: Tue Dec 31 17:30:00 +0000 2002 on tty1" だし。 日本時間に合わせたシステムだと、"Tue Dec 31 17:30:00 JST page2002" とか "Last login: Tue Dec 31 17:30:00 +0900 2002 on tty1" になっている。 ローカルタイムを設定しないといけないのかな。 どこで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://developers.google.com/web/tools/setup/workspace/setup-devtools
