Windows のフォントを綺麗に表示する MacType の最終設定値 - drk7jp
会社で MacBook Air（以下 MBA） をサブ PC として使うようになって感じるようになったのが Windows の使い勝手の悪さ。今までは Windows 最高と思い続けてきたのですが、その思いは脆くも崩れ去りました。かつて白い MacBook を会社で使っていた際には全然良いと思えなかったのですが、ハード面でもソフト面でも劇的に進化していたのと、自分自身の PC の使い方がウェブ中心に変わったことで、MBA 最高！って状態になりました。特にトラックパッドの使い勝手から離れられません。 今となっては会社では MBA がメイン PC で VAIO Z がサブ PC になりつつあります。 とは言えそれは会社での話。自宅ではデジカメ整理や杯勝つ環境などソフト面で過去の資産があるのと、ディスプレイの大きさゆえに、まだまだ VAIO AW71JB の方がメイン PC だったりします。トラ
ＩＰＡ式ウェブアプリケーション脆弱性チェックリスト
先日書いた業務用アプリに関連するんですけど、うちの会社ではサービスをリリースする前に脆弱性監査を通す必要があります。会社の仕組みとしてそのような監査チームがあることが凄く助かっています。 さて、会社の脆弱性監査の内容は守秘義務等で書くことが一切できないのですが、ＩＰＡ（独立行政法人 情報処理推進機構）にて脆弱性対策についてのまとめ資料が公開されています。 情報処理推進機構：情報セキュリティ：脆弱性対策：安全なウェブサイトの作り方 ココで公開されている 「安全なウェブサイトの作り方 改訂第3版」 は全７６ページからなる脆弱性対策マニュアルになっていて、どのような脆弱性に対してどうのように対処すべきかが記載されています。この第３版は行ってみれば、脆弱対策2009年度版みたいなもん。新しい攻撃手法がどんどんでてくるのでその都度対策が必要なのですが、このマニュアル本に記載されている内容で、現在の対
ブラウザキャッシュによる HTTP 高速化チューニング
かれこれ一年ほど前に実施した実サービスでの apache のチューニングネタを思い出したように書いています。 以前いた部署では少ないサーバ台数で大量のリクエストを如何に処理しきるかってことに燃えていたので、静的コンテンツなどをブラウザに支障のない範囲で最大限にキャッシュさせ、サーバとネットワークの負荷を最小化させていました。 当時参考にした情報源は以下の３つでした。 どのようなレスポンスヘッダを返しておけばブラウザキャッシュを最大化できるかのテクニックがまとめられています。 ブラウザキャッシュとレスポンスヘッダ - murankの日記 Kazuho@Cybozu Labs: キャッシュの上手な使い方 [Studying HTTP] HTTP Status Code チューニングにおいて重要なのは自分自身での検証。というわけで自前で検証した結果と検証するために用意したプログラムを公開します。
KDDI の CloudCore VPS の使用感および他社比較
まず結論からですが、ベンチマークの数値上では他の VPS に負けてしまってますが、物理コア、メモリ量、ディスク容量を考えると、今一番オススメできる VPS だと感じています。ただし CentOS をゼロベースで運用できるスキルが必須になります。セキュリティも設定も貴方次第。そんな感じのサービスです。そこが一番のハードルだと思います。 それぞれの VPS を調査したデータを記載しておきます。KDDI の物理コアが AMD Phenom(tm) 9550 だったことは、僕にとっては相当ショックだったのは内緒です。Intel 系であって欲しかったです。安さのポイントは AMD 系にあったってところでしょうか。まぁそれであっても物理コアなので、ホスト側で重たい処理を実行中だったり、同一ホストに収容されている他の VPS の影響を受けにくい（CPU的な観点では）ことは、サービス運営側にとっては大きな
IO Accounting 機能で I/O 負荷の高いプロセスを特定
随分久々の Linux ネタです。以前にロードアベレージに関する考察などの記事も書きましたが、多くのサーバーサイドエンジニアはサーバ負荷と日々戦っていることかと思います。過去多くの場合、負荷の原因特定はおおよそ下記のような手順で分析をしていたことかと思います。※詳しい手順は別エントリとして記載予定。 top をみて上位に張り付いているプロセスを確認しつつ CPU or I/O のどちらが原因か判別 ps を使ってプロセスの状態を確認して(T),(D)の状態から CPU or I/O のどちらが原因か判別 vmstat で procs の r, b の数、swap の si, so の状態、I/O の bi, bo の状態を確認 iostat を使って disk の read/write の状態をさらに詳しく確認 sar を使って os の状態をさらに詳しく確認 おおよその原因特定から設定を
Linux チューニング - Ext3 のパフォーマンスを最大化させる
じつは自宅サーバのロードアベレージが上がり続けています。分析の結果、ボトルネックは I/O 処理でした。CPU は Athlon64 X2 4400+ ですが、まだまだ当分この CPU で間に合いそうです。HDD は当時は 7200 回転で最速だった HITACHI Deskstar T7K250 SATA2 250GB を RAID1 構成にしたのですが、今思えば速度優先で RAID0 にしておけば良かったと少しだけ後悔。 I/O がボトルネックに成っている理由ですが、Drk7jp が公開しているサービスの全てがキャッシュファイルを利用した高速化手法を取っているのですが、単純にそれらファイルの write 処理が追いついていません。常に何らかのプロセスで I/O 待ち状態が発生しているような状況です。抜本的な解決方法としては disk を高速なものに交換する以外ありません。 というわけで
HTML - meta タグの仕様詳細まとめ :: Drk7jp
前エントリ - Internet Explorer のイメージツールバーを無効化する meta タグ で予告したとおり meta タグについて生まれて初めてまじめに調べてみました。改めて調べてみると知らなかったこと満載です。っていうか Web エンジニアたるもの一度は W3C勧告 くらいは一通り目を通しておかなくてはダメだなと思ったりしました。面倒なくらい分量があるけど。ひとまず meta タグ情報としての自分にとって永久保存版まとめという位置づけです。 まずは参考になったサイトの紹介から。 W3C勧告HTML4.01 :: The global structure of an HTML document W3C勧告HTML4.01 私的日本語訳 :: The global structure of an HTML document(ja) rfc2616.txt Another HTML
Lighttpd 1.5 系がスゴイらしい
はてブで lighty のブログがあることを知ってブログを見てみました。lighty の中の人が書いてます。 ナント、lighty 1.5 系が pre release されているではありませんか！ なんでも、1.5 系は いままでより 80% のスループット向上が見込めると書かれています。激速の lighty が更に高速になるってわけですよ。Σ(ﾟДﾟ； Using Async IO allows lighttpd it overlap file-operations. We send a IO-request for the file and get notified when it is ready. Instead of waiting for the file (as in the normal sendfile()) and blocking the server, we ca
SimpleAPI の仕組みについて考察してみる
最近気になっているサービスと言えば、一躍有名になった「SimpleAPI その1.ウェブサイトサムネイル作成API β版」っていうサービス。その１って書いてあるくらいだから、作者の方はその２、その３を考案中と思われるわけですが、サイトのサムネイルを生成するってのはいろいろなところで役に立ちそうな気がします。 で、できれば自社で同じような仕組みを作って自社で解決したいと思われている方も多くいるのでは？と思います。僕的には会社の仕事からすれば何ら関連のないジャンルのサービスですが、個人的には非常に興味がそそられるサービスなので、その仕組みについて考察してみました。勝手な考察なので、全然違う可能性もあるので、あしからず・・・。 どうやってサイトのサムネイルを生成しているのか？ 自前で位置からブラウザの描画を模倣するプログラムってのは作るには敷居が高すぎると直感。特に CSS や JavaScri
MySQL のパラメータチューニング
MySQL のチューニングに関する話題・・・ Movable Type とかみたく少量のデータならパフォーマンスの問題はあまり発生しませんが、業務データのように本格的に が多くなってくると、/etc/my.cnf で設定をチューニングする必要がでてきます。特に 100 万レコードのオーダーで検索処理を行う場合、パラメータ調整が結構きいてきます。主なチューニング向けパラメータは以下の通り。物理メモリ容量にあわせて swap しない程度に値を増やすとよさげです。 key_buffer 検索に使われるインデックスをバッファに保存する際のメモリサイズ。値を増やすと検索パフォーマンスが向上。 table_cache データのキャッシュサイズ。値を増やすとディスクのI/Oが減りパフォーマンスが向上。 max_allowed_packet 入力データ保持のための最大バッファサイズ。大きなデータ挿入をおこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
