MovableTypeでレスポンシブWEBデザインでSEOに強いテーマを無料配布します
一時期は絶大な人気を博していた MovableType も、今となっては完全に WordPress 一人勝ち状態。今導入するならどっち？と聞かれれば迷わず WP をおすすめするところ。しかしながら10年近く MT でブログを運営してきて、いろいろ独自patchを当てて運用しているので、今更MT以外に乗り換えがきかないところまで来てるのが、当ブログの実態。 自分のブログのアクセスも PC 以外のアクセスがほぼ半数になってる状況もあり、そろそろモバイル対応でもするかなと思い立ったのが 2013年12月ほど。年末年始の空き時間を見つけて一気に作りこんでレスポンシブWEBデザイン対応させました。 モバイルデバイス対応も WP なら豊富に見つかるのですが、MT は全然イケてるテーマが見当たりません。一言で言うと『MT にも STINGER3 みたいなテーマが欲しいんです！』 そう思って探しまくってみ
TokyoCabinet のデータサイズは 64GB 付近で性能劣化
当ブログでサービスを提供している AmazonSearch ですが、子ども部屋の確保が最大の理由で、自宅サーバから sakura VPS 2G へ一ヶ月ほど前に移行を行いました。移行手順は以前もご紹介した、ブログをさくら VPS へ移行手順に準じて行いました。 AmazonSearch は内部計算が複雑なため、さくら VPS では QPS（queries per second）が 5-6 程度しかでません。したがって、高速化を図るためレスポンス結果を TokyoTyrant（TokyoCabinet）にキャッシュする仕様で実装を行っています。先日まで安定運用できていたのですが、RDB（casket-a.tch） のデータサイズが 64GB 付近に近づいた時点で性能が急激に劣化して高負荷でレスポンスが返せない事象が発生しました。ちょうど 2012/6/2 15:30 付近からです。 [tts
そろそろ Xperia arc と iPhone4 について語っておくか・・・
xperia arcを手に入れてから約一ヶ月が経ちました。手に入れた直後に感想を書くのも相当量の偏見が入りそうだったので、まずは一ヶ月使い続けてみました。もうそろそろ語っておいても良かろうと思いエントリとして書き綴ってみます。 iphone4 と Xperia arc の評価は評価者の属性によって大きく変わると考えているの で、まずは僕の属性をちょっとだけ書いておきます。 38歳男性 docomo ガラケーユーザ歴10数年。 iphone4 歴約8ヶ月。現在は Xperia arc, N905is, iphone4 のケータイ三台持ち 新しい物好き、デジタル家電好き、PC 歴 20 年、超絶面倒くさがり屋 iPhone4 と Xperia arc をともに使ってみて感じた差などを独断と偏見で語ってみたいと思います。 まず結論から。 比ぶべくもなく圧倒的な差で iPhone4 の勝ちです。
メール送信者認証技術 SPF/Sender ID についてお勉強
お勉強の背景に関しては 「迷惑メール対策 OP25B（Outbound Port25 Blocking）についてお勉強」 に書いたとおりですが、迷惑メール対策としての SPF/Sender ID についてもいろいろ勉強したのでそのまとめです。（DomainKeys については思いのほかエントリが長くなったのでまた別の機会で・・・）まずは参考になったサイトの紹介から。 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 Sender ID: Authenticating E-Mail DNS関連技術の最新動向 - SPF/DomainKeysとは Sendmail 社 - 送信者認証技術の導入におけるレコメンデーション メール送信者認証の仕組みを探る(2/2):スペシャル - ZD
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 を高速なものに交換する以外ありません。 というわけで
ワードサラダ技術について
後半部分が重要で、未来の挙動が現在の値だけで決定され、過去の挙動と無関係である ということです。 さて、実例です。たとえば次の文章を考えてみます。 「通信販売大手セシールは９日、生命保険の販売に本格参入する方針を明らかにした。」 まず形態素解析するとこんな感じになります。 通信 名詞,サ変接続,*,*,*,*,通信,ツウシン,ツーシン 販売 名詞,サ変接続,*,*,*,*,販売,ハンバイ,ハンバイ 大手 名詞,一般,*,*,*,*,大手,オオテ,オーテ セシール 名詞,固有名詞,組織,*,*,*,セシール,セシール,セシール は 助詞,係助詞,*,*,*,*,は,ハ,ワ ９ 名詞,数,*,*,*,*,９,キュウ,キュー 日 名詞,接尾,助数詞,*,*,*,日,ニチ,ニチ 、 記号,読点,*,*,*,*,、,、,、 生命 名詞,一般,*,*,*,*,生命,セイメイ,セイメイ 保険 名詞,一般
/dev/shm に参照系ＤＢを持っていくと I/O 負荷が激減した件（当たり前だけど）
前エントリーから一部の内容を分離して追加記事にしてみました。以下実施したメモリ増設の効果について。 ここ数ヶ月、自宅サーバの負荷がだんだんと上昇してきていて、そろそろ１台で高速にさばききる限界に近づいてきた感があったり。ここ数週間のロードアベレージはこんな感じ。グラフは× 100 の値になってます。CPU のコアが２個なんで、200 までは OK ということでまだ処理しきれているわけではあります。ちなみに mrtg グラフは瞬間値を示しているわけではなく平均値なので瞬間的にはもっと負荷が高いときとかあります。 でも月次処理が走るともっさり感満点。 ※緑：１分平均 ／ 青：１５分平均 実は CPU の処理速度が追いついていないと言うより I/O 周りがボトルネックになっています。 ※緑：読取ブロック数 ／ 青：書込ブロック数 ということで、メモリを２GBプラスして、合計 4GB にして参照系
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
syslog は I/O 負荷が高い → daemontool に移行しよう！ :: Drk7jp
qmail のログを daemontool 経由にする方法 まずは、qmail 1.03 内の FAQ テキストの 7.7 項をみる。ちょろっと情報が記載されています。 7.7. How do I avoid syslog? It chews up a lot of CPU time and isn't reliable. Answer: Install daemontools (http://pobox.com/~djb/daemontools.html). Make a /var/log/qmail directory, owned by qmaill, mode 2700. Do qmail-start ./Mailbox /usr/local/bin/accustamp \ | setuser qmaill /usr/local/bin/cyclog /var/log/qmail
ワンランク上の負荷対策を Web アプリに実装するには・・・(Sledge編)
最近、お仕事で悩ましいのがデータベース負荷。結局のところ、Web サービスでボトルネックになるのは、バックグラウンドの ＤＢ 処理。特にどうしようもないのが、更新系リクエスト。つまりはマスターＤＢ。 既に多くのところが採用している構成と思いますが、MySQL とかでよくやる手段といえば、 参照系は、レプリケーション機能を使って参照系ＤＢを用意して負荷分散。マシンを増やせば負荷に対応可能。 更新系のクエリーだけは、できる限り高スペックなマシンを用意してマスターＤＢを構築して一手に引き受ける。増設困難で悩ましい。 もうちょい頭をひねれば、機能毎にマスターＤＢを分散させたり、ユーザ ID とかでパーティショニングしたりと、アプリ層で振り分ける。MySQL に限らず、Oracle とかでも同じようなことが言えます。 で、マシン負荷を監視という運用業務が必須な日々を送っていた（いや、実際にはPJのメ
lighttpd + FastCGI 上で MT3.2 を動作させる方法
「Drk7.jp を lighttpd へ完全移行」に書いたとおり、当サイトは lighttpd で運用しているのですが、lighttpd は mod_perl ではなく、FastCGI でスクリプトの高速化をしなくてはなりません。 以前は MovableType を Apache + mod_perl で動作させていましたが、lighttpd では FastCGI で動作させるためにいろいろと小細工が必要でメンドウって事で普通の CGI として動作させていましたが、最近になって管理画面や検索のモッサリ感が耐えきれなくなってきて lighttpd + FastCGI + MT3.2 をやってみました。 もともと MT は FastCGI を前提とした作りにはなっていないので、ディスパッテャーを作成してやる必要があります。mod_perl + MT に比べて極端に情報が少ないのですが、ネット
ベンチマーク対決！ MySQL 4.1.15 vs 5.0.15 どっちが速い？
「MySQL 新バージョン 5.0.15 （5.0.x系正式版）がリリース！」で予告しましたが、ver 4.1 系から大幅に進化した MySQL 5.0系ですが、そのパフォーマンスが非常に気になるところ。早速、mysqlbench を使ってベンチマークしてみました。 結果は MySQL 4.1 系の勝利。それでは、ベンチマーク結果をどうぞ。 ベンチマークツール mysqlbench の準備 まず始めに、MySQL 用のベンチマークツールである mysqlbench をインストールします。mysqlbench 自体は PostGuserQL 用に開発された pgbenchを MySQL 用に移植したツールで、TPC（Transaction Processing Performance Council) が規定している性能ベンチマークの指標のうち、TRC-B に準じたベンチマークとなっています
lighttpd でスパムボットを排除する方法
「mod_setenvif を使って Apache のログを軽量化」で Apache のログの軽量化の一つとして robot.txt とかを無視してすごい勢いでアクセスしてくるロボットつまりは spambot を排除する方法をお知らせしましたが、「lighttpd + FastCGI は mod_perl + Apache1.3 より１割ほど高速」で書いたように、lighttpd へ移行してからそこら辺の設定がメンドウでサボってました。 昨晩、とあるエラーが大量に出力されていたので気になって調べてみると、Ask.jp のロボットが秒間 ５ リクエストくらいの勢いでクロールしに来てました。ちなみに、下記のような UserAgent で到来します。
Google AdSense の広告表示精度を高める方法 :: Drk7jp
セクション ターゲットを使用すると、サイトのコンテンツと広告を照合する場合に、強調または無視すべきテキストや HTML コンテンツのセクションを Google に知らせて、広告表示の精度をより向上させることができます。 セクション ターゲットの実装は、HTML を熟知したお客様にのみお勧めしています。 <!-- google_ad_section_start(weight=) --> 記事のタイトル<$MTEntryTitle$>や記事本文<$MTCommentBody$> <!-- google_ad_section_end --> <!-- google_ad_section_start(weight=ignore) --> バナー広告やリンク集を貼り付けているサイドバーやトップバー部分やコメントやトラックバック部分 <!-- google_ad_section_end --> です。
リバースプロキシを導入する際はmod_rpaf
僕の自宅サーバには２つの Apache がインストールされていて、用途により使い分けています。 * Apache 1.3系 + mod_perl → Amazon Search / Google Similar といった高速性を求めるサービス * Apache 2.0系 → その他の静的コンテンツや 通常用途の CGI 等の動的コンテンツ なぜ使い分けるかというと、mod_perl はメモリー喰いなので、静的画像のためにプロセスがもったいない訳です。本当に必要なリクエストにのみ mod_perl をかませば良いですから。 （参考ページ：リバースプロキシ Pound を導入しました。 : NDO::Weblog） で、２つの Apache を透過的に見せてあげるために、リバースプロキシの Pound を使っています。負荷分散も実装できて優れものですが、欠点が一つ。 リクエストをリバースプロキ
lighttpd + FastCGI は mod_perl + Apache1.3 より１割ほど高速 :: Drk7jp
巷で超高速 Web サーバとして話題になっている lighttpd を試してみました。lighttpd に関する日本語ドキュメントは非常に少なく、ちょっと込み入った設定ファイルの記述方法とかの解析に手間取りました。 lighttpd のコンセプトは、「セキュアで省メモリで高速に動作し、柔軟性もある」なのですが、「lighttpd 公式サイトのベンチマーク結果」や「UnknownPlace. - Catalyst ベンチ」で簡単な Catalyst - Hello.cgi のベンチマークが公開されているとおり、Apache 1系、Apache 2系よりも高速に動作するようです。特に static なページの処理は Apache の 2〜3 倍程度は高速に処理できるみたいです。 また注目すべき点として、Apache + mod_perl よりも lighttpd + FastCGI の方が１割
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
