WordPressの記事一覧 6ページ目

W3 Total Cache日本語版作成中

WordPressの動作を軽くする、キャッシュ生成プラグイン「W3 Total Cache」(W3TC)の日本語化作業を始めました。

w3tcjp_image

まだ一部ページの翻訳が終わっただけな状況ですが、同様な作業を行う方が現れて不要なバッティングなど起きぬよう、この場を借りまして「翻訳中」宣言を致します。

W3TC日本語化に到る背景や、現在の作業状況などは以下の通りです。

【この記事の続きを読む →】

WordPress: facebookの「いいね」に使われる画像を指定するコード書いた

facebookの「いいね!」ボタンを押したとき、サムネイル画像として使われる画像を指定するWordPress用コードを書いたよ。

「いいね!」ボタン実装の詳細は他を当たってもらうとして、ここではサムネイル画像を指定するプロパティ「og:image」に限って説明します。

コードは個別記事(post)で記述することを前提としているので、インデックスやアーカイブで使用する際は、自分で一工夫して下さい。

【この記事の続きを読む →】

WordPress: コード整形プラグイン SyntaxHighlighter Evolved 導入

基本からしっかりわかる WordPress 3カスタマイズブック (Web Designing Books)

WordPressの記事中に表示するソースコードを、整形して見やすく表示するプラグイン「SyntaxHighlighter Evolved」を導入しました。

これまでは「iG:Syntax Hiliter 日本語版」を使っていたんだけど、まれにコードの整形に失敗する場合があり、これに嫌気が差して乗り換えることにしました。

「SyntaxHighlighter Evolved」を選択した理由は、ベースに使っているjsが「Google syntaxhighlighter」とメジャーな仕組みなコト、また整形後の見た目の綺麗さ、あとは他ブログでの使用数などを鑑み、「本流」と思われる「SyntaxHighlighter Evolved」を選択しました。

プラグインの導入に難しいことはなく、いつものようにダウンロードして、プラグインフォルダに展開して、有効化するだけ。

使い方も簡単で、コードの前後を[html]~[/html]なんて感じに囲うだけ。

で、実際の表示はこんな感じになります。

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
	<title>PHP Code Example</title>
</head>
<body>
	<h1>PHP Code Example</h1>

	<p><?php echo 'Hello World!'; ?></p>

	<p>This line is highlighted.</p>

	<div class="foobar">
		This	is	an
		example	of	smart
		tabs.
	</div>

	<p><a href="http://wordpress.org/">WordPress</a></p>
</body>
</html>

PRE表示にJSでCSSを被せるので、一瞬だけ素のコードが見えるけど、その後は非常に見やすいコードになっていると思います。

当たり前のようにHTML関連文字列は正規化してくれてるし、URLもクリッカブルだし、各種予約後は色つき表示だし、コード上にマウスをポイントするとソースコピペなんかのコマンドアイコンが出てきます。

各種言語にも広く対応しているし、行番号の有り無し、任意行数からのカウント、特定行のハイライト、行折り返しの有無なども簡単に指定可能な優れものです。

もしWordPressを使っていて、コードを綺麗に表示したいなら「SyntaxHighlighter Evolved」をオススメしておきますよ :-P

WordPress: W3 Total Cache(W3TC)の高速化効果がスゴイ

WordPress 3 サイト構築スタイルブック

WordPressを最適化するプラグイン「W3 Total Cache」(W3TC)の高速化効果がスゴイ。

これまでは「WP Super Cache」と言うキャッシュプラグインを使ってたけど、「W3 Total Cache」の先進さに惚れて一発で乗り換えを決めました。

W3Tのスゴさを三行で説明

W3Tのスゴさを三行で説明します。

  • 色々とキャッシュできる
  • コードの最適化も出来る
  • CDNの設定や、ブラウザキャッシュ制御まで出来る

以下ザックリと説明していきます。

色々とキャッシュできる

W3TCでは、一般的な「ページキャッシュ」以外にも、「データベースキャッシュ」や「オブジェクトキャッシュ」にも対応しています。

「データベースキャッシュ」を有効化すると、記事(post)やページ(page)、フィード(feed)の作成時間が短縮されます。

「オブジェクトキャッシュ」を有効化すると、その他の一般的な操作実行時間が短縮されます。

これらを全て有効化することにより、見ているヒトが快適になるだけではなく、サーバのCPU資源やメモリ資源の節約にもなります。

コードの最適化も出来る

コードの最適化(Minify)と言う機能が付いており、WordPressが生成するHTMLコードの最適化や、使用しているJavaScriptファイルの最適化、またブログテーマで使用しているCSSファイルの最適化まで可能になっています。

これにより転送ファイルのサイズや、転送すべきファイル数が削減できるので、WordPressの高速化に繋がります。

実際に当ページではJavaScriptファイルとCSSファイルが最適化された状態で提供されています。興味がある人は、HTMLソースを開いて先頭の3行目、4行目あたりを確認してみて下さい。

CDN設定、ブラウザキャッシュ制御

上記以外にもコンテンツデリバリネットワーク(CDN)の設定や、ブラウザキャッシュ制御のサポート機能まで備えています。

CDNは、大容量のアプリ・音楽・動画などを配信する際に利用する特別なネットワークのコトです。まだ余り一般的ではないと思いますが、Amazon.comが提供するCloudFrontを利用することが可能ですし、自前でCDNサーバを立てることにより、画像などを別サーバに振り分けるなんてコトが可能になります。

ブラウザキャッシュ制御では、Expires headerやSet pragma、Etag付与やgzip圧縮などの設定が可能です。

ktai styleやWP Touchと共存も可能

W3TCは「ktai style」や「WP Touch」などのプラグインと共存することも可能です。

ページキャッシュや最適化設定の詳細ページに「Rejected User Agents」と言う項目があります。

ここに携帯やiPhone/iPadのUAを設定すると、該当機器にはキャッシュしていない通常のページが表示されることになり、結果的に携帯用ページやiPhone用ページを表示することになります。

まとめ

色々と出来るワリに設定が簡単で、しかも高速化効果も抜群です。

一度、W3TCを使いはじめると、WP Super Cacheが過去の遺物に思えるほどで、全てのWordPressユーザーに積極的にオススメします。

現在は英語メニューしかないのが難点ですが、そんなに難しい英語でもないので、チョコチョコと翻訳しながら読めば意味は分かると思います。

ぜひ一度お試し下さい。

さくらのVPS、Apacheチューニング

Apacheクックブック 第2版 ―Webサーバ管理者のためのレシピ集

興味のないヒトにはくどいでしょうが、本日も「さくらのVPS|VPS(仮想専用サーバ)はさくらインターネット」にUbuntuでLAMP環境を構築し、その上でWordPressを動かすオハナシです。

なかなか安定運用に持って行けてませんが、http無応答時にコンソールを覗くと、Apacheさんが「Out of memory」を吐きまくっていることに気がつきました。

Out of memoryについて

まず「Out of memory」に付いて調べました。

linuxの初期設定では総メモリ容量(実メモリ+Swap)以上の実効メモリ容量を要求された場合、実際には足りないのに大らかな気持ちで要求を受入れてしまうそうです。

結果として必要なメモリが足りない事態が発生した場合、適当なプロセスをkillしてしまうそうで、これを行うのが「Out Of Memory Killer」ことOOM Killerさんのお仕事で、OOM Killerさんが吐くエラーが「Out of memory」として表示されていたようです。

OOM Killer概要:
Out Of Memory Killerのこと。Linuxのデフォルトの動作では、プロセスがメモリを要求した場合、総メモリ使用量が実メモリ+swap以上であっても、ある程度許可するようになっている。これは、各プロセスが要求したメモリをすべて使うわけではないという経験的な法則により、できるだけ多くのプロセスを起動するためにそのように動作になっているようである。そのため、あるプロセスが確保できたはずのメモリを使おうとし、実際にメモリが足りない場合カーネルが適当なプロセスを選択し、そのプロセスをkillしてしまうことをOut Of Memory Killerという。

引用元:http://yochecks.blogspot.com/2007/04/oom-killer.html

Apacheのチューニング

OOMエラーを理解することにより、Apacheの「なにか」がメモリを浪費しているのでは無いか?というアタリを付けました。

なぜApacheさんがメモリを食いまくっているか?と言う根本的な理由は分からないですが、取りあえずの対策としてApacheの設定をチューニング。

/etc/apache2/apache2.confを開き、mpm_prefork_moduleの設定を以下のように変更しました。

<ifmodule mpm_prefork_module>
    StartServers          5
    MinSpareServers       5
    MaxSpareServers      10
    MaxClients           34
    MaxRequestsPerChild  4000
</ifmodule>

一番大きく変更したのは「MaxClients」の値です。初期値では150になっていましたが、省メモリ環境での運用であることを踏まえ、34に制限してみました。これで良い変化があると良いんだけどな~。

Apacheのチューニングに付いては、『さくらのVPSのその後@2010-10-25 | それでも地球はまわっている』や、『[Slicehost] OOM Killer(Out Of Memory Killer)の対策 – delab』を参考にしています。貴重な情報ありがとうございます。

今日の人気記事