アフィリエイト広告を利用しています

PHP fatalって0だったんですか? 'fatal' == 0が成立しました。

if( $sts == 'fatal' ){
エラー処理
}
とか、よくあるソースコードかと思います。

$stsは正常系(数値)と異常系(fatal)を混在させていました。

これ、実は、以下ソースコードだとエラー処理が成立します。
$sts = 0;
if( $sts == 'fatal' ){
エラー処理  <=ここに来ます。
}

まじですか?文字列と数値ですよ?==が成立するなんて思いもつきませんが?本当です。実環境で相当悩みました。ソースコードレビューではわからない不具合ですね・・

FreeBSD 9.1のPHP 7.4.19 で確認しました。

$sts = 1;echo ($sts == 'fatal'); <= 不成立です。
echo (0 == 'fatal'); <= 不成立ですが・・・
$sts = 0;echo ($sts == 'fatal');
1 <= 成立です。
これってPHPの仕様なんでしょうかね?

久しぶりにドキドキました。謎の動作でどハマりしましたよ・・
ソースは以下のように修正したところ、仕様通りの動作となりました。
if( is_numeric($sts) == false && $sts == 'fatal' ){
エラー処理
}


posted by scripts at 18:00 | Comment(0) | TrackBack(0) | php

SQLite3で同時書き込みしたい

SQLite3で同時書き込みしたい、同時接続、同時読み込みをサポートしているから当然同時書き込みもできると思いがちですが、SQLite3は同時書き込みできない仕様になっています。
SQLite supports multiple simultaneous read transactions coming from separate database connections, possibly in separate threads or processes, but only one simultaneous write transaction.

SQLiteは、場合によっては別々のスレッドまたはプロセスで、別々のデータベース接続からの複数の同時読み取りトランザクションをサポートしますが、同時書き込みトランザクションは1つだけです。
sqlite.org 2.1. Read transactions versus write transactions


SQLite3のトランザクションとロックのおさらい


トランザクションは明示的、暗黙的の2種類です。
明示的トランザクションの開始は、以下の3つのコマンドです。確定(COMMIT)、元に戻す(ROLLBACK)制御がでいます。
明示的 BEGIN/BEGIN DEFERRED 最初のR/I/U/Dアクセスで読み込み・書き込みトランザクションを開始
明示的 BEGIN IMMEDIATE 宣言で書き込みトランザクションを開始、他からリードできる
明示的 BEGIN DEFERRED 宣言で書き込みトランザクションを開始、他からリードできない

暗黙的トランザクションは、自動的に開始されたトランザクションです。BEGINやCOMMITを使わなくてもトランザクションが働く仕組みになっています。BEGIN命令は自動的コミットを停止する役割になっています。

トランザクション開始、コミット等で「SQLITE_BUSY:別のプロセスで使用されているデータベース」エラーが発生します。sqlite.orgのトランザクションドキュメントを読むとこのあたりこのことが明確になります。

ロックと並行性(ttps://sqlite.org/lockingv3.html)も合わせて熟読すると内部構造がなんとなく理解できます。

トランザクションの開始でファイルがロックされる仕組みではないことがわかります。

SQLite3のロックは?SQLite3がファイルロックするタイミングは極力少なくするように設計されています。ただロックの失敗はSQLITE_BUSYエラーに集約されます。

ロックの状態は5種類あります。
UNLOCKEDデフォルトの状態。オープン直後またはアクセスがない状態
SHAREDSELECT、BEGINコマンド後のSELECTで取得、この状態は複数プロセスを許可
RESERVED最初のINSERT、UPDATE、またはDELETEの実行で取得。この状態は唯一、獲得可能は1プロセス
PENDING自分以外のSHAREDがある状態、EXCLUSIVE待ち。獲得可能は1プロセス
EXCLUSIVE排他ロック。書き込み中。獲得可能は1プロセス

書き込みが発生する暗黙的トランザクションも同様のロックが発生します。

ロック中の読み取りは、EXCLUSIVEロック中だけ他プロセスもリードアクセスができなくなります。これ以外のUNLOCKED 、SHARED 、RESERVED中はリードアクセス可能です。
PENDINGはSHAREDロック所有プロセスはリードアクセス可能です。新たなSHAREDロックは獲得できません。
同時読み込みをサポートする仕組みであることがわかります。ただEXCLUSIVEロック中は読み込みも失敗することに注意が必要です。

プログラム(PHP SQLIte3)に落とし込んで考えると以下のようなことがわかりました。
・querySingle("select")、query("select")、prepare("select")等でSHAREDロックが発生する
・exec("insert")等でSHARED、RESERVED、EXCLUSIVEロックが発生する
・exec("begin")発行では、ロックは発生しない。
・exec("begin IMMEDIATE")はRESERVEDロックを獲得しようとする
・exec("begin EXCLUSIVE")はEXCLUSIVEロックを獲得しようとする
・sqlite3内部のロック状態は発行の失敗で判断するしかない

同時書き込みトランザクションは1つだけの範囲は?テーブル?全体?検証してみました


検証の結果、同時書き込みトランザクションは1つだけの範囲は、データベース全体です
同一テーブルに対しての同時書き込みは、100%「Unable to execute statement: database is locked」が発生します。
異なるデーブルに対しての同時書き込みは、100%「Unable to execute statement: database is locked」が発生します。

添付のPHPソースコードで検証しています。2つのプロセスから同時に1000件書き込む単純なコードです。
sqlite3のバージョンは「3.32.3 2020-06-18 14:16:19」です。macOSで実行しています。
同一テーブル検証ソース(test1-w.php)
<?php
class test {
public function run($table, $name){
$db = new SQLite3(__DIR__ . "/test.db");
$db->enableExceptions(true);
try{
$db->exec('begin');
$stmt = $db->prepare("insert into {$table} (time, value ) values (:time,:value)");
for( $i = 0; $i < 1000; $i++ ){
$stmt->bindValue(':time', time() );
$stmt->bindValue(':value', $name ."-". $i );
$stmt->execute();
}
$db->exec('commit');

}catch(Exception $e){
$db->exec('rollback');
print_r($e);echo "{$table}:{$name}:{$i}:".PHP_EOL;
}
}
}
if( isset($argv) && isset($argv[0]) && isset($argv[1]) == false ){
if( file_exists(__DIR__ . "/log.log") ){unlink(__DIR__ . "/log.log");}
if( file_exists(__DIR__ . "/test.db") ){unlink(__DIR__ . "/test.db");}
$db = new SQLite3(__DIR__ . "/test.db");
$db->exec('create table tbl (pk INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, time, value )');
$db->close();
unset($db);
$cmdlist = [];
for( $i=0; $i< 2; $i++ ){
$cmdlist[] = "php test1-w.php tbl name{$i} > ./log.log 2>&1 &";
}
exec( implode( '', $cmdlist ) );
}
else{
$test = new test();
$test->run( $argv[1], $argv[2] );
}
  • ○ test1-w.phpとして保存してください。
  • ○ 実行:php test1-w.php
  • ○ database is locked等が発生するとすぐに終了します。
  • ○ test.dbファイルがテストに利用したSQLiteデータベースファイルです。
  • ○ log.logファイルに実行結果が残っています。cat、less等で内容を確認できます。

異なるデーブル検証ソース(test2-w.php)
<?php
class test {
public function run($table, $name){
$db = new SQLite3(__DIR__ . "/test.db");
$db->enableExceptions(true);
try{
$db->exec('begin');
$stmt = $db->prepare("insert into {$table} (time, value ) values (:time,:value)");
for( $i = 0; $i < 1000; $i++ ){
$stmt->bindValue(':time', time() );
$stmt->bindValue(':value', $name ."-". $i );
$stmt->execute();
}
$db->exec('commit');

}catch(Exception $e){
$db->exec('rollback');
print_r($e);echo "{$table}:{$name}:{$i}:".PHP_EOL;
}
}
}
if( isset($argv) && isset($argv[0]) && isset($argv[1]) == false ){
if( file_exists(__DIR__ . "/log.log") ){unlink(__DIR__ . "/log.log");}
if( file_exists(__DIR__ . "/test.db") ){unlink(__DIR__ . "/test.db");}
$db = new SQLite3(__DIR__ . "/test.db");
$cmdlist = [];
for( $i=0; $i< 2; $i++ ){
$db->exec('create table tbl'.$i.' (pk INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, time, value )');
$cmdlist[] = "php test2-w.php tbl{$i} name{$i} > ./log.log 2>&1 &";
}
$db->close(); unset($db);
exec( implode( '', $cmdlist ) );
}
else{
$test = new test();
$test->run( $argv[1], $argv[2] );
}
  • ○ test2-w.phpとして保存してください。
  • ○ 実行:php test2-w.php
  • ○ database is locked等が発生するとすぐに終了します。
  • ○ test.dbファイルがテストに利用したSQLiteデータベースファイルです。
  • ○ log.logファイルに実行結果が残っています。cat、less等で内容を確認できます。


同時書き込みトランザクションは1つだけのSQLite3で同時書き込み


こちらで説明した通り、SQLite3は同時書き込みをサポートしていません。これはファイル型データベースの宿命かもしれませんね。Access(mdb)でも同じような感じだったと記憶しています。

同時書き込みをサポートしているSQLServer、Oracle、MySQLといったサーバー方式のデータベースと同じような概念では対応できないってことですね。

SQLite3で同時書き込みをサポートすることはSQLite3をSQLServer、Oracle、MySQLに昇格させるような困難が待ち受けている可能性があります。同時書き込みをさせない設計にしておくことが良いかと思います。

できないのではなく、できるようにする考え方


ここではレンタルサーバー利用で良くあるWebのコメント欄や掲示板にSQLite3を利用した場合を想定し、同時書き込みするにはどうすればいいのかを考えています。複数のユーザーがブラウザでアクセス、書き込み等することでほぼ同時の書き込みが発生する可能性があります。
SQLite3では同時書き込みはサポートされていませんが、複数の要求をシーケンシャルに順次書き込みすることで問題は発生しないはずです。

不確実なことがあり得るリトライ方式


Exceptionを検出して、リトライする方式です。Exceptionやエラーが検出できる言語なら、少量のソースコードの変更で対応できる方法です。
書き込みの順番性は失われることがあります。
リトライの上限を決めておくのも大切です。リトライ満了で失敗した場合を考慮する必要があります
環境によっては同時書き込みの影響でデータベースが壊れてしまう可能性を秘めています(ファルロックシステムコールが正しく動作するストレージをお使いください)。

Mutexやセマフォを利用することで上記のようなエラーを抑止することができます(Mutexやセマフォが使える環境の場合)。

登録する順番をあまり考慮していませんが、以下のような方法があります。こちらのトライロックを実現する方法を利用した同期処理を利用します。
1)try-lock 獲得できない false/NG 
1−1)dbに対してinsert/update/deleteする内容をユニークなファイル名で所定ディレクトリに保存します。
2)try-lock 獲得できた true/OK 獲得できても稀に競合が発生します。
2−1)dbに対してbegin;create table;commitを発行します。稀に発生する競合はここで除外します。
 例外が発生した場合は、1ー1)と同じようにファイルに保存します。
 ここで除外できないパターンもあるかもしれません。
  2−2)、2−3)でもcatchし、ファイル化するロジック組み込んでおくのが安心です。
2−2)所定ディレクトリをスキャンし、ファイルがある場合はinsert/update/delete処理を行います。
 処理できた場合は、対象ファイルを削除します。
2−3)通常処理 

  • ・所定ディレクトリは設計で定めてください。
  • ・dbはenableExceptions(true)で例外発生を許可しておきます。
  • ・try catch構文でdatabase is lockが発生した際、catch可能です。
  • ・ディレクトリからファイルを探す処理になるため、ファイル名をうまく設計しておかないと順番制が担保できません。
  • try-lockの方法で、競合発生するはずないでしょ。って思うかもしれません。とてもシンプルで頑強に思います。事実、稀に発生します。どうして発生するのか想像もつかないぐらいナイスなタイミングが発生しているんだと思います。競合をなくすことはかなり難しいので発生に備えた方が簡単だと思っています。


後からまとめ書き込み方式


この方法は、要求で即時に書き込む代わりに、要求を所定のディレクトリ等にファイル化します。
スケジュール(クーロン等)でディレクトリをスキャンし、まとめて書き込む方式です。

順序性は秒レベルです。工夫することでミリ秒レベルまで落とし込むことが可能です。

リクエストしたデータの反映は、スケジュール間隔に依存します。リアルタイム性がありません
スケジュールの最小実行間隔は通常1分です。これ以下での間隔での処理はできません。

定期実行されるプログラムでは、所定ディレクトリをスキャンし、古い順(ファイル更新時刻等で並び替え)に処理していきます。処理済みの要求ファイルを削除します。

EXCLUSIVEロック中は読み取りアクセスも失敗します。わずかなタイミングですがこの隙間に読み取りアクセスが発生しない保証がないのでオンライン用データベースとオフライン用データベース(更新用)、2つのデータベースを持つことも検討してみてください。

オフライン用データベースがマスターデータベースです。オフライン用に書き込み処理を実施し、
完了後オフライン用データベースをオンライン用データベースに上書きコピーします。

「後からまとめ書き込み方式」は、システムが出来上がると安定した運用が可能です。

上書きによるエラー(オンラインで参照している側)は記憶の限りありません。
ボトルネックの少ない、SSD採用のレンタルサーバーを利用しています。

メッセージキュー方式


レンタルサーバーでの利用は厳しいかもしれない方法です。VPS等ご利用中の方が使える方法です。お使いの環境でメッセージキュー関数が使えるかどうかを事前に確認する必要があります。

要求の順序性を保ちつつ、ほぼリアルタイムに処理できる方式です。
AJAX等でコールされたプログラムからメッセージキューへ送信します。
メッセージキューを受信する専用のプロセスが必要です。このプロセスは、SQLite3書き込み用プロセスで順次くる要求に従ってデータベースを更新します。

キューを利用することで並列でくる要求をシーケンシャルにすることが可能です。

メッセージキューに格納できるデータサイズの上限等の制限(環境依存)もあり得ます。この場合中間ファイル等を利用することで回避できます。

同時書き込み単位にファイルを分割




まとめ


SQLite3で同時書き込みすると「database is locked」エラーが発生します。同時読み込みをサポートしているから当然同時書き込みもできると思いがちですが、SQLite3は同時書き込みできないことが分かったかと思います。

SQLite3で同時書き込みを防ぎつつ、システム利用するのにはどうすべきかをご紹介してきました。

SQLite3の更新系は「同期」が必須になります。そのための設計が必要ってことですね。

今回ご紹介したように同期をプログラムからサポートする方法もあります。
ただこれがいいってわけではありません。

同時書き込みする場合のおすすめはデータベースサーバーです

「database is locked」エラーで悩むのは、SQLite3の用途を超えた設計になっているかも。

WordPress 管理画面 [Error] TypeError: undefined is not an object (evaluating 'wp.i18n.setLocaleData')の解決方法

WordPressの管理画面でウィジェットの内容を変更するために外観→ウィジェットで表示されるサイドバーウィジェットのテキスト、カスタムHTMLを展開しようとするとこんな感じでタイトルや内容の記載が表示できない状態になっていました。解決方法はこちらです。
wordpress-widget-sidebar-not-working-1.jpg


WordPress管理画面でTypeError: undefined is not an objectが発生したらやるべき事


google page insightsやSearch Consoleの指摘でなんとか解決しなきゃとググって、見つけた設定方法でWordPressのテーマへ設定を反映しています。手早く解決できますよね。

これがいけませんでした。ちょっと考えてから適用しておけば防げました。

以下のような設定をfunctions.phpに記載している場合、管理画面、通常表示どちらでも有効になります。

/*wp-emoji-releaseの無効化*/
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
/*link rel='shortlink'の無効化 */
remove_action('wp_head', 'wp_shortlink_wp_head');
/*link oEmbedの無効化 */
remove_action('wp_head','wp_oembed_add_discovery_links');
/*jqueryの無効化 */
wp_deregister_script('jquery');
/*プラグインの無効化*/
function dequeue_plugins_style() {
wp_dequeue_style('wp-block-library');
wp_dequeue_style('colorbox');wp_dequeue_style('colorbox');
wp_dequeue_style('wordpress-popular-posts');
}
add_action( 'wp_enqueue_scripts', 'dequeue_plugins_style', 9999);

管理画面では有効にしたい場合、以下のように変更します。ワードプレス標準関数is_admin()で管理画面かどうかを判断することができます。

if( is_admin() ){ /* 管理画面 */ }
else{ /* 管理画面以外 */
/*wp-emoji-releaseの無効化*/
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );



add_action( 'wp_enqueue_scripts', 'dequeue_plugins_style', 9999);
}/* else end */

管理画面では何もしない、それ以外の場合に処理するコード例です。管理画面がおかしい、そういえばコード修正したかもって方の参考になれば幸いです。

解決までの流れ Can't find variable: wp、TypeError: undefined is not an object (evaluating 'wp.i18n.setLocaleData')


本来の「テキストウィジェット」の表示
wordpress-widget-sidebar-not-working-goal.jpg

比較すると以下のようなことがわかりました。
  1. タイトルのラベル、入力エリア(input type=text")がない
  2. 「メディアを追加」ボタンが消えている
  3. ビジュアル、テキストのタブが消えている
  4. 入力エリア(textarea)がない
  5. 削除、完了リンクはある
  6. 「保存しました」ボタンが「Saved」ボタンとして未翻訳の状態である


本来表示されるべき内容が消えてしまっている?あります。通常のコンテンツにアクセスしてウィジェットのエリアは普通に表示されていました。

一体いつから消えていたのか?ウィジェット系の更新頻度は低いです。そのため、どれくらい前から消えていたのか判断できませんでした。

解決方法は?「Wordpress サイドバーウィジェット 不具合」等でググりました。該当しそうな情報が見つかりません。

原因となりそうなキーワードを集めるためにブラウザーのデバッガー(Safari:右クリック→要素の詳細を表示、Chrome:右クリック→検証)を起動したところ、エラーが多数発生していたことがわかりました。
wordpress-widget-sidebar-not-working-2.jpg

  1. 15箇所 ReferenceError: Can't find variable: wp
  2. 1箇所 TypeError: undefined is not an object (evaluating 'window.wp.editor')
  3. 1箇所 ReferenceError: Can't find variable: tinymce

このエラーを見て、ぴん!っと閃きました?

そういえば、通常サイト側の対応で、jqueryのURLをテーマ(header.php)に直書きしたことを思い出しました。
wordpressでのjquery呼び出しを削除するため、functions.phpに以下を追加しました



wp_deregister_script('jquery');



よく良く考えると上記のような指定では管理画面、通常サイトを含めて全てjQueryが無効になってしまいますね。↓管理画面の場合は対象外!という処置をしました

if( is_admin() ){ }else {
wp_deregister_script('jquery');
}

修正したらエラーの内容が変わっていました(アップロードして検証ツールのログを確認したところ)。
wordpress-widget-sidebar-not-working-3.jpg

Can't find variable: wpエラーは解消しました。
  1. 15箇所 ReferenceError: Can't find variable: wp
  2. 1箇所 TypeError: undefined is not an object (evaluating 'window.wp.editor')
  3. 7箇所 TypeError: undefined is not an object (evaluating 'wp.i18n.setLocaleData')
  4. 1箇所 TypeError: undefined is not an object (evaluating 'wp.mediaWidgets.init')
  5. 4箇所 TypeError: undefined is not an object (evaluating 'wp.mediaWidgets.modelConstructors')
  6. 1箇所 TypeError: undefined is not an object (evaluating 'wp.textWidgets.idBases')
  7. 1箇所 TypeError: undefined is not an object (evaluating 'wp.codeEditor.defaultSettings')
  8. 1箇所 TypeError: undefined is not an object (evaluating 'wp.customHtmlWidgets.idBases')
  9. ReferenceError: Can't find variable: tinymce


これらエラーは、jQueryを除去した方法と同じようなremove_action、wp_dequeue_style、wp_deregister_scriptなどを対策で追加した影響で発生しています。

同じようにis_admin()関数で判断することで対処しました。

エラーはなくなり、サイドバーウィジェットのテキストは展開されるようになりました!

まとめ


ワードプレスの管理画面 外観、サイドバーウィジェットの内容を編集できない!っていうところからの解決するまでの流れが分かったかと思います。ちょっとしたfunctions.phpへの修正でこんな影響が出るとは・・・ワードプレスの修正って、簡単だけど難しいって思いましたよ。

WordPress管理画面でTypeError: undefined is not an objectが発生したら、修正したテーマのfunctions.phpを見直すことでエラーをなくすことが分かったかと思います。

functions.phpへの修正はできる限り、影響範囲を抑えるため条件分岐タグis_adminを使った方がいいですね。
is_admin()ダッシュボードまたは管理画面の表示中かどうか

これ以外にもたくさんありますが、管理画面かどうかで判断するのが一番確実だと思います。

初めはWordPressのバグかと疑ってフォーラムとか検索しまくりました。でも結局は自分で設定した変更による影響でがっくりきましたよ・・・


この記事の投稿時点のワードプレスのバージョンは「WordPress 5.6.2 」です。

Wordpress5.6 Classicエディタでプレビューできない問題の原因は非推奨でした。このツールでわかりましたよ

Wordpress 5.x系のサイトを複数運営している中で、あるサイトだけ投稿、固定ページの記事内容を変更し、「プレビュー」ボタンで確認しても、変更前の内容がプレビューされる問題に悩まされていました。新規投稿時はちゃんとプレビュー効きます。一旦投稿してしまうとプレビューできなくなっています。

ぐぐるとこういう問題の場合、「プラグインを全部無効にして、検証すれば特定できる」というような内容ばかりで、運営中のサイトにダメージを与えそうで実施できずに対応を引き伸ばしていました。

Webサーバーで動くPHPのバージョンは自動的にバージョンアップするようにしています(なっていました)。そのため問題のあったサイトはPHP7.4で動いています(この記事書いている時点です)。

原因は「非推奨」でした。


結果的にwordpressの問題ではなく、プラグイン、テーマで使われているPHP関数が原因でした。
具体的には「create_function」、「allow_url_include」この2つがPHPの非推奨項目でした。

create_functionはPHP7.2で非推奨になりました(create_functionはphpの関数です)。
allow_url_includeはPHP 7.4で非推奨になっていました(この項目はphp.iniの設定値です)。

古いプラグインをバージョンアップも特に通知がないので長く使っています。こういった更新の滞っているプラグインやテーマはこの非推奨にぶち当たりやすいですね。

非推奨になっていてもワードプレスの管理画面や表示画面は通常です。一切異常は見当たりません。Gutenbergエディタではプレビューも普通に動いていました。

問題は局所的に現れるんですね。

この2つの非推奨を除去(ソースコードの修正、php.iniの修正)したところ、「プレビュー」が機能しました。


「Query Monitor」プラグインが教えてくれました


Query Monitor

このプラグインを有効にしたところ、「非推奨」の項目を利用中ってことが分りました。


格安(千円未満)のSSDプランがあるVPS一覧とプラン【さくらVPS・ConoHa VPS・mixhost VPS】比較

SSDを採用しているVPSを契約しようと検討しています。その最中に集めている情報をまとめています。ここでは2020年7月時点のSSDを採用した国内VPSの一覧がわかります。利用予定のOSはUnixであれば何でもいいと考えているのでWindowsサーバー対応の有無は詳しく調べていません。Windows Serverが使えるVPSはこちらにまとめています。



【続きはこちら】
posted by scripts at 15:26 | Comment(0) | TrackBack(0) | VPS

wordpress 迷惑なアクセスを除去している方法

レンタルサーバーでWordpressのサイトを運営していると500エラーの頻度が多いことに気がつきます。
そんなにたくさんのアクセスがあって嬉しい!って思っていたんですが、ログを工夫して見てみたら上位アクセスの多くはbotだったり、amazonawsだったりと普通にアクセスしてくれるユーザーではなさそうで、ガッカリ。

リソースを増量したり、もっとアクセス過多に対応できるサーバーへ以降すべき?って思っていたこともありましたが全くの無駄ってことに気づきました。


サイトを運営する目的を考えると集客してくれる検索サイト(GoogleやBingなど)のアクセスは歓迎したいです。誰かがSNS上で紹介した結果エビデンスを調べるために訪れる「Facebot Twitterbot/1.0」や「Linespider/1.1」なども嬉しいアクセスだと思っています。

一方、集客に貢献してくれるわけでも無いbot(例えば「SemrushBot」、「360Spider」、「MauiBot」)は、レンタルサーバーのリソースを食いつぶす厄介なアクセスです。

またアクセスログファイルに記録されたIPアドレスからドメインを逆引き(nslookupやdigコマンド)してみると、amazonawsやロシア、ウクライナ、イギリス、ポーランドなど迷惑アクセスで有名なドメインやIPアドレスだったりとがっかりする内容でした。

こういった迷惑なアクセスを除去すると、500円〜の低価格なレンタルサーバーでもそこそこ稼げる環境へと導けることとができます。
低価格レンタルサーバーのワードプレス運営で気をつけているポイント
  • 【ポイント1】公式からダウンロードできるプラグインは極力インストールしない、必要最低限にしています。

    HTMLファイルで作られたサイトにアクセスした場合、ほぼサーバーのスペックで応答できます。
    ワードプレスはPHPプログラムです。そのためメモリ上(またはスワップファイル)にプログラムがコンパイルされ、MySQLから必要な情報を取得し、HTML整形して応答しています。多少なりともサーバーへ負荷を与えます



  • 【ポイント2】 サイトを立ち上げ、ワードプレスをインストール、テーマを決定した段階で「PageSpeed Insights - Google Developers」のスコア100を目指しています。

    運営中には、影響を与えてしまうかもしれないので消極的な手段を選びがちです。そのため、初期の段階でガッツリ対策しています。

    指摘の中で、サーバーの応答時間はサーバー変えるしか無いので無視しています。

    キャッシュ系のプラグインは記事内容をほとんど変えない場合絶大な効果があります。

    テーマ自体もPHPプログラムです。凝ったテーマはそれだけでスコアを悪くすることもあるので、なるべくシンプルなテーマに切り替えるようにしています。

    スコア90以上、可能なら100を目指しています。



  • 【ポイント3】 ワードプレスが動いたリアルタイムなアクセスログを収集する

    サーバーの負担を上げるワードプレスが動作するアクセスが異常に多くなっていないか?が知りたいと思っています。


    ほとんどのレンタルサーバーでアクセスログ、エラーログを提供しているかと思います。ログ(nginxやApacheのログ)は記事へのアクセスの他、画像ファイルへのアクセス、ファビコンへのアクセス、ワードプレスの特定の脆弱性を狙ったアクセスなどが記録されています。

    このログからは、記事に関するアクセス以外はワードプレスが動作しません。

    そのため、ワードプレスが動作したときだけ別のログファイルに記録する方法を採用しています。


  • 【ポイント4】 収集したログから異常なアクセスをあぶり出し、拒絶などの対策をします。

    一般ユーザーアクセスなのか、または迷惑なアクセスなのかを見極めて、迷惑なアクセスは極力除外するようにしています。

    除外は、.htaccessファイルで制御しています。
    Deny from IPアドレス・ドメイン で拒絶、
    SetEnvIf User-Agentでユーザーエージェント指定で拒絶、
    などです。

    こうすることで極力サイトを快適にして、アクセスしてくれた一般ユーザーの方が素早く表示できるいいサイトになるよう心がけています。



ワードプレスが動いたログを記録する


ワードプレスが動作した際、ログを記録するプラグインを自作し、有効化します。
ソースコードのファイル名、クラス名はかぶらない名前で適時変更してください。

またソースコード中、フルパスでログを格納するフォルダ(ディレクトリ)を指定しています。レンタルサーバーのディレクトリ構成がよくわからないって方は調べてみてください。
<?php
/*
Plugin Name: WordPress ログ記録
Plugin URI: http://サイトのURL/
Description: WordPress ログ記録
Author: scripts
Version: 1.0
Author URI:https://fanblogs.jp/scripts/
*/
class accesslog_74bee6e126ef2866d0d6ebaf38734088{
static $instance = null;
static public function getInstance(){
accesslog_74bee6e126ef2866d0d6ebaf38734088::$instance = new accesslog_74bee6e126ef2866d0d6ebaf38734088();
}
public $start = 0;
public $starttime = 0;
public $lapse = 0;
function __construct(){
$this->starttime = time()+ 9*60*60;// +9時間
$this->start = array_sum( explode(' ', microtime() ));
add_action('shutdown', array($this, 'logger'));
}
function __destruct(){
$logfile = "/フルパス/wp_access_log";
// $logfile = __DIR__ . "/../../wp_access_log"; // 相対パス ワードプレス直下

if( @file_exists($logfile) ){
$mtime = filemtime($logfile) + 9*60*60;
if( date('Ymd',$mtime) == date('Ymd', time() + 9*60*60 ) ){

}else{
$w = date('w',$mtime);
$dstfile = $logfile . "." . $w;
if( @file_exists($dstfile) ){ @unlink($dstfile); }
@rename( $logfile, $dstfile );
}
}
ob_start();
$line = "{$this->lapse} ".date("H:i:s", $this->_starttime);
$line .= " {$_SERVER['REMOTE_ADDR']} " ;
$line .= '"' . $_SERVER['REQUEST_METHOD'] .' ' . $_SERVER['REQUEST_URI'] .'"' ;
$line .= " ". $_SERVER['REDIRECT_STATUS'] ." ";
$line .= '"' . $_SERVER['HTTP_USER_AGENT'] .'"' ;
@file_put_contents( $logfile , $line.PHP_EOL, FILE_APPEND );
ob_end_clean();
}
function logger(){
$this->lapse = number_format( array_sum( explode(' ', microtime() )) - $this->_start, 3 );
}
}// class end
accesslog_74bee6e126ef2866d0d6ebaf38734088::getInstance();


例えばGoogleのボットアクセスの場合、このようなログを残すことができます。
0.299 00:00:13 66.249.79.250 "GET /" 200 "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.92 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

・いろいろとエラー処理は省いています。
・曜日ごとの最新ログファイルを残します。
・UTCで動作しているワードプレスで利用しています。日付が9時間ずれるようでしたら+9*60*60を削除することで正しい日付になります。

傾向と分析


全体のアクセスが少ない日は、7割ボット、3割ユーザーと言った感じの統計になっています。
対策を全くしていない場合、8割、9割がボットアクセスになることもあります。
日毎に傾向を捉えて、アクセスの傾向を分析していると発見があります。

同一IP、同一ボットからの激しいアクセスを見つけて、拒絶する


ボットの場合、大抵ユーザーエージェントを見ることで、わかるようになっています。

GoogleやBingなどメジャーなボット以外で激しいアクセスしているものは除外するようにしています。
Bingの場合、https://www.bing.com/toolbox/webmaster/?cc=jpにサイトを登録することでアクセスの頻度をコントロールすることができます。ただあくまで要望を伝える手段の一つでその通りに動作してくれるわけではありません。

同一IPからの激しいアクセスを見つけて、拒絶する


ボットでは無い、iPhone safariなどのユーザーエージェントを名乗ったアクセスがあったりします。
普通では違いが分かりませんが、時間を空けずにページを遷移が激しい場合スクレイピングと疑って除外するようにしています。

同一IPで複数のユーザーエージェントを名乗っているアクセスを見つける


同一IPでユーザーエージェントを変えながらアクセスし、別ユーザーを偽装するパターンがあります。
これを検出するためにはログファイルIPアドレスとユーザーエージェントの集計処理が必要です。
1つのIPで4つ以上のユーザーエージェントを名乗っている、そのIPをググってスパム等の検索結果があったら除外すると言った対応をしています。


その他:amazonawsは拒否、海外も注意が必要


amazonaws.comからのアクセスがあります。これはAmazon AWSサービスを利用しているユーザーからのアクセスで一般ユーザー扱いしなくていいと思っています。なので全拒否しています。

複数のホストから同時にアクセスすることで運営中のサイトは重くなりダメージを受けます。
海外の数10のIPアドレスから同時にアクセス(攻撃?)があったことがありました。
この時運営中のサイトは激しく重かったです。

ユーザーエージェントは偽装が可能なので絶対ではありません。ただスクレイピングのサンプルソースコードを元にアクセスしてくるパターンは簡単に分かります。ユーザーエージェントに「Python」、「Java」、「PHP」と言った利用中の言語のキーワードが入っています。


まとめ


ある程度ボットがサイトの情報を収集してくれないと集客が成り立ちません。1日1000アクセスぐらいなら7割ボットぐらいが丁度いいと思っています。

賢いボットは、サイトの負荷をなるべく上げないように分散して収集していると感じています。
賢く無いボットは、大体迷惑なアクセスですね。

「パンくずリスト」の問題が新たに検出されました。data-vocabulary.org schema deprecatedとは?


Google Search Console Teamから『サイト https://ドメイン/ で「パンくずリスト」の問題が新たに 検出されました』ってメールが届いていました。

対象のサイトはWordpressのサイトです。警告の内容は、
data-vocabulary.org schema deprecated
でした。

data-vocabulary.org schema deprecatedとは?


data-vocabulary.orgは、サイトのHTMLソースを確認するとパンくずリストに使っている箇所で利用していました。

<div id="breadcrumb">
<div itemscope="" itemtype="https://data-vocabulary.org/Breadcrumb">
<a href="https:/domain" itemprop="url"><span itemprop="title">ホーム</span></a>>
</div>
<div itemscope="" itemtype="https://data-vocabulary.org/Breadcrumb">
<a href="https://domain/category/" itemprop="url"><span itemprop="title">カテゴリ</span></a> >
</div>
</div>


Googleのwebmasterブログにdeprecatedの理由が書いてありました。
2020年4月6日より、data-vocabulary.orgマークアップは、Googleのリッチな結果機能の対象外となります。
https://webmasters.googleblog.com/2020/01/data-vocabulary.html?m=1

data-vocabularyは少数派で時代遅れ、メジャーなSchema.orgへ一本化すると記されています。

data-vocabulary.org schema deprecatedをなくす対策のHTMLとワードプレスの対応


data-vocabulary.orgマークアップをschema.orgに置き換えることで警告はなくなります。

schema.orgを利用したパンくずリストの書き方はGoogle(パンくずリスト)を参考にするのが確実です。

Google(https://search.google.com/test/rich-results)でライブテストすることができます。microdata形式に対応していました。

先ほどのソースをコード入力でテストするとリッチリザルト対象ですが、以下警告が表示されることが確認できます。
data-vocabulary.org schema deprecated(任意)と黄色で警告表記が確認できます。


元HTMLソースを
<div id="breadcrumb">
<div itemscope="" itemtype="https://data-vocabulary.org/Breadcrumb">
<a href="https:/domain" itemprop="url">
<span itemprop="title">ホーム</span>
</a> >
</div>
<div itemscope="" itemtype="https://data-vocabulary.org/Breadcrumb">
<a href="https://domain/category/" itemprop="url">
<span itemprop="title">カテゴリ</span>
</a> >
</div>
</div>

このように変更した結果、
<div id="breadcrumb" itemscope="" itemtype="https://schema.org/BreadcrumbList">
<div itemprop="itemListElement" itemscope="" itemtype="https://schema.org/ListItem">
<a itemprop="item" href="https://domain" itemprop="url">
<span itemprop="name">ホーム</span>
</a>
<meta itemprop="position" content="1" /> >
</div>
<div itemprop="itemListElement" itemscope="" itemtype="https://schema.org/ListItem">
<a itemprop="item" href="https://domain/category/" itemprop="url">
<span itemprop="name">カテゴリ</span>
</a>
<meta itemprop="position" content="2" /> >
</div>
</div>

警告がなくなりました。
data-vocabulary.org schema deprecated(任意)の警告がなくなていることが確認できます。


<meta itemprop="position" content="番号" />は必須パラメータで、省略するとエラーになります。

Wordpressの対応(stinger5)


このdata-vocabulary.org schema deprecated警告が発生しているサイトは、Stinger5テーマを利用しているサイトでした。ここではStinger5を例にしています。
変更が必要なファイルはwp-content/themes/stinger5/フォルダにあります。

Stinger5では、Breadcrumbコードが分散してソースとして埋め込まれています。
以下3つのファイルを修正します。
  1. 404.php
  2. archive.php
  3. singe.php


テーマをFTPツールでアップロードできる環境の方は、ローカルに保存したstinger5テーマからdata-vocabularyをキーワードにして対象となるファイルを特定することができます。

HTMLの修正自体はここまでご紹介している内容で対応できると思います。課題は<meta itemprop="position" content="番号" />の実現性かと思います。

このようにすることで対応できます。
・・・<span itemprop="name">ホーム</span> </a><?php $_content_no_=1;?><meta itemprop="position" content="<?php echo $_content_no_;$_content_no_++;?>" /> > </div>



<span itemprop="name"><?php echo get_cat_name($catid); ?></span> </a><meta itemprop="position" content="<?php echo $_content_no_;$_content_no_++;?>" /> > </div>

$_content_no_という変数を初期値1で定義して、出力したら+1するソースコードになります。1ファイルで2箇所修正する際の例として参考にしてください。

ホームのところはcontent="1"直書きでwhileでループしているところだけ初期値2から始める方法でも可能です。この場合、変数の宣言位置に注意してください。

変数名は何でもいいです。ただWodpressやテーマ、プラグインで利用中の変数と重複すると面倒な事態になるので分かりやすさより、被らないユニーク性を重視してくださいね。




まとめ


対応期限は、2020年4月5日までです。4月6日からエラー扱いになるかと思われます。
対策した後は、サーチコンソールで「修正を検証」お忘れなく。
検証はしばらく時間がかかります。また一度に全ての問題を警告してくれないのでGoogleのクロールするタイミングで新たに警告するURLが増えます。

「修正を検証」ボタンをクリックした1日後、合格していました。今回の修正方法で合格がもらえることが確認できました
合格したことが確認できる。(サーチコンソール>パンくずリスト>data-vocabulary.org schema deprecated>詳細を表示)



Google PageSpeed InsightsはWordpress テーマを変えるだけで100点取れる?

100点取れました。Google PageInsightsのパソコン100点の結果がわかる

取れました。ただ、Google PageSpeed Insightsのパソコン側の結果です。モバイルは99点です
Wordpressのバージョンは、5.2.1。
サーバは、エックスサーバー(X10)です。先日新サーバーに移行しました。
今回評価に使ったサイトは、2018年2月ごろからあるサイトで、テストに利用したURLは、2000文字ぐらいの規模です。

プラグインは、ページキャッシュ系プラグインなし、というかプラグインはすべて無効状態です。
100点取ったらテーマは、Wordpress標準のTwenty Nineteenです。
Twenty Nineteenです。


パソコン100点、モバイル99点獲得できた際のラボデータ(モバイル)は以下のような結果です。
パソコン100点、モバイル99点獲得できた際のラボデータのモバイル

現在レンタルしているサーバーの上限値となり得る値です。検索してサイトに訪れてきたユーザーが遅い・速いを感じる指標はコンテンツの初回イベント、速度インデックスかと思います。

グーグルの指標的には、クロールせずに見える範囲を1秒未満で表示できるのが望ましいです。
PageSpeed Insights は、ページを分析して、モバイル ネットワークでページを 1 秒未満で表示するための推奨事項にそのページが準拠しているかどうかを確認します。
developers.google.com:
PageSpeed Insights でのモバイル分析

また、上記モバイル分析ページに書いてありますが、モバイルは4G/3G回線でアクセスを前提とした速度で計測されます。そのためパソコンで90点台を取れても、モバイルは40点台という結果になったりします。

変える前のテーマでは、47点でした


当然サクサク90点台取れるかと思ったんですが・・・
高額講座で貰った高機能なテーマ

メディア作成向けの高額有料講座で貰った高機能なテーマを使っていたんですが、この通りの結果ですちなみにパソコンは91点でした。
ラボデータは意味のあるコンテツの初回イベント3.4秒、速度インデックス4.9秒でした。先ほどの結果から今レンタルしているエックサーバーだと速度インデックスは1.8秒程度はいけるはずなので、3.1秒ほど他の何かで遅くなっているってことです。
yuuryou-theme-1-labodata.jpg

レンタリングを妨げるリソースの除外で3.12sぐらい改善できるような感じでしたが、焼け石に水ですね。

これでもか!ってぐらい機能豊富なんですが、その分遅くなっている要因が複雑化していました。詳しくソースをチェックしていたところさらにがっかりしました。

有料講座で貰ったテーマの問題点
  • ソースを確認すると既知の技術を組み合わせているような感じのテーマでした。
     そのためか、scriptやstyleタグが長い傾向にある(ソースも長かったです)
  • 同じ機能のjavascriptやフォントを何度も呼び出しする傾向にある
  • 高機能な部分は、複雑な機構になっている
  • 手の施しようがない感じです。

      deferとか使ってなんとかしよう!って思わせてくれない感じでした。手強いです。

      有料テーマ 賢威8.0は、77点でした


      ワードプレスのテーマとして<a href=【賢威】8.0(ワードプレス版)を有効にしたイメージ" width=300>

      テーマを2019年5月30日にバージョンアップした【賢威】8.0(ワードプレス版)に変更し、確認するとモバイル77点とテーマを変更しただけで30点アップしました。パソコンは99点でした。
       賢威8.0のモバイル結果がわかる


      ラボデータは、意味のあるコンテツの初回イベント2.4秒、速度インデックス3.0秒でした。
      keni-labodata.jpg



      2万人を超えるユーザーが選んだSEOテンプレート【賢威】

      というフレーズが有名です。
      実際購入して感じたメリットは、長く使うほどお得感が増すっていうところです。今だと賢威を購入すると賢威6、賢威7、賢威8の3つのバージョン(ワードプレス版、HTML版)がダウンロードできます。毎年バージョンアップしているのでどんどんテーマが増えるって感じでお得に感じています。

      また、サポートがしっかりしている(ユーザーフォーラムがあります)ので、不具合とかにも真摯に対応してくれます。他の有料テンプレートに手を出したことがないので比較できませんが、新しく購入するテンプレートは、サポートフォーラムありっていうところを選びたいと思っています。


      Google PageSpeed Insightsで満点取れたけど、77点でいいんです


      Wordpress テーマを変えるだけでモバイル47点から99点、パソコン91点から満点にできることがわかったかと思います。またワードプレス標準テーマを利用するとレンタルしているサーバーの上限値を理解することができます。

      でも、満点のテーマは使いませんその理由は不便な思いをしたくないからです。
      一般的なワードプレスサイトなら標準テーマでも良いかと思いますが、47点のテーマでも、Webフォントの利用をやめたり、キャッシュ系プラグインを利用することで劇的な速度改善につながる可能性もありますね。

      また、速い結果のテーマでも、機能が足りないのでプラグインを追加しがちです。これは遅くなる要因に繋がりやすいので、初めから機能がそれなりに盛り込まれていて、そこそこ速いテーマでいいんじゃないかと思っています。

      テーマによっては、ランキング、関連ページ、ブログカード、吹き出しなど様々な便利な機能が用意されていますよね。やっぱりこれを使いたいです。

      頻繁に情報を更新するサイトだとキャッシュ系プラグインが使えないというかキャッシュすることに意味がないことがあります。このような場合は、キャッシュがない状態でもそこそこ速いテーマ(例えば賢威とか)にしたいですね。
      【賢威】



wordpress 5 記事が自動的にPublishから非公開になっていた件

どうも!Scriptsです。Wordpress5.1.1+Stinger5(かなり昔の無料版)利用中のサイトで404エラーが発生していることをGoogle Search Consoleで知りました。

該当の記事は、ブラウザでアクセスすると確かに404エラーになっています。
該当の記事をプレビューで確認したところ、「非公開:タイトル」になっていました。

でも、wordpressのデータベースに直接アクセス(mysqlコマンド)して確認しても、wp_postsは非公開になっていませんでした。
post_status は、 publishであることが確認できました。

データベース上、公開になっているのに、非公開になるパターンって一体どういう自体なんでしょうかね・・・

ググっても、試行錯誤した原因不明の対処方法ばかりで信頼できないって思いました。そこでどこでこれがpublishからprivate(非公開)に変化させているのか?原因を徹底的に調査しています。

・・・

徹底的に調査する前段階で原因ががわかりました。
mysqlに接続して、タイトルでマッチするレコードを調査したところ、投稿ページ、固定ページで同一のタイトル、urlのページがありました。

同じURLで公開、非公開のページが存在できるのがwordpressの仕様っぽいです。

公開日付1 固定ページ側 パーマリンク:サイト/パス1/ 非公開
公開日付2 投稿ページ側 パーマリンク:サイト/パス1/公開

というような感じで設定されていました。この場合、公開でなく、非公開が有効になるようです。


同じパス1になっていることが問題でした。非公開側のパス1をパス2、別のページ名に変更したところ、
投稿ページ側のサイトが非公開=>公開に変更できました。

同じような問題で困っている方は、投稿ページ、固定ページ両方のURLで一致しているものがないかを確認してみてくださいね。

mysqlコマンドが使える方は、wordpressのデータベースに接続した後、以下のようなSQLを打ち込むことで重複があるurl(post_name)を調べることができます。
mysql> select ID,post_title, post_status,post_name, post_type from wp_posts where post_name like '%キーワード%' and post_status in('private', 'publish');
キーワードは、調査したいページ名に置き換えて実行してください。





「応答速度が速い」がGoogle上位表示の秘訣!応答速度が速いサーバーは?

2018年7月からページ速度がより早い方がモバイル検索ランキング上位に表示される要素になるってご存知でしょうか?googleの公式ブログで2018/1/17に発表されているのでご存知の方も多いかと思います。
=>2018/7から「応答速度が速い」がGoogle上位表示の秘訣になるってことです。

人々はできるだけ早く質問に対する回答を見つけることができるようにしたいと考えています。研究によれば、人々はページのスピードを本当に気にしています。スピードはしばらくの間ランク付けに使用されていましたが、その信号はデスクトップ検索に集中していました。今日では、2018年7月からページ速度がモバイル検索のランキング要素となることを発表しています。
https://webmasters.googleblog.com/2018/01/using-page-speed-in-mobile-search.html


ユーザーがページを表示するまで速いのが一番ですが、サーバーが担うのは一部です。
1)【スマホ/PCの役割】URLからIPアドレスをLookup、サイトに要求する
2)【サーバーの役割】URLに該当するページを応答する
3)【スマホ/PCの役割】レスポンスで受け取っとページを描画する

2)の部分をできる限り速くするのがサーバーの役割です。これ以外の部分はユーザーの範疇です。例えば高性能なスマホなら速く表示できるし、ユーザーの使っている回線が速ければ素早く表示できます。

速いサーバーはレスポンスが早いということになります。レスポンスが遅いと離脱率が上がり、記事を見てもらえない可能性が高くなります。
サイト表示が2秒遅いだけで直帰率は50%増加!

操作開始時間が1秒のサイトと3秒のサイトを比較しても、3秒のサイトは1秒のサイトに比べ、ページビューが22%低下、コンバージョン率は38%低下、直帰率は50%上昇してしまう
Impress:Web担当者



応答速度が速いレンタルサーバーの定義


サーバー ハードウェアのスペックで注目したいのは、SSD採用かどうかです。VPSや専用サーバーならCPUコア数、メモリも重要ですね。多ければ多いほどピーク時に対応しやすいメリットがあります。反面価格も高くなるのでトレードオフです。

ポイント1)SSDを採用している


ファイルへのアクセスが高速になります。ページのキャッシュ(ファイル)、データベースクエリの結果キャッシュ(ファイル)、PHPコード(ファイル)、ファイルにアクセスするシーンは多いです。
ベースのRead/Writeスピードが高速なSSDは有利です。SSDを採用しているレンタルサーバー、VPSサーバー、専用サーバーは多いです。

ポイント2)HTTP/2 or QUICに対応している


サイトのSSL対応はGoogleのページランキングの要素の一つです。HTTPS化のメリットの一つはHTTPより速くなることが期待できるHTTP/2、QUICを使えるようになることです。

HTTP/2は、HTTPS通信時にEdge/Chrome/Safari/Opera主要ブラウザが使えるプロトコルです。サーバー(HTTPデーモン)がHTTP/2に対応している必要があります。
HTTP/2のメリットは、クリティカルパスを短くできる可能性を秘めています。優先度制御や非同期でのリクエスト/レスポンス処理が可能です。ブラウザの進化によりHTTP/2に対応しているサイトは、Webページを表示する見かけ上のスピードを向上することが期待できます。

QUIC(Quick UDP Internet Connections)は、GoogleがHTTP/2より安全で高速なレスポンスを目指し、Chrome/Operaブラウザで使えるプロトコルです。サーバーがQUICに対応している必要があります。
chrome://net-internals/#quic
で動作状態を確認することができます。デフォルトではアクティブになっていました。

ポイント3)次世代HTTPサーバー(Nginx、LiteSpeed)とキャッシュ機能が使える


HTTPサーバーといえばApacheが有名ですね。2018年6月時点、同時アクセスのパフォーマンスに着目したNginx、さらに高速化を目指しているApacheと互換性のあるLiteSpeed、次世代HTTPサーバーがレンタルサーバーでも利用できるようになっています。

同じハードウェアでHTTPサーバーの処理能力が向上するものなの?疑問ですよね。LiteSpeedで検証データが公開されています。LiteSpeedはApahceの10倍処理能力があります。
LitespeedはApacheの10倍、NginxはApacheの4倍処理能力が高いことがわかるグラフ

出典:https://blog.litespeedtech.com/2018/03/05/compare-openlitespeed-to-nginx-and-apache/
このグラフは1秒間にリクエストをどの程度アクセスを受け入れられるかを示しています。グラフが高いほど優秀です。
このグラフからApache上のWordpressサイトでW3 Total cacheを有効にしたサイトを1とすると、Nginx+FastCGI Cacheは4.24倍、litespeed(オープンソース版)+LSCacheは10.24倍処理能力が向上できることがわかります。

これらの要件を満たすレンタルサーバーは?


XSERVER、mixhost、JETBOY、この3つのレンタルサーバーです。

XSERVERのポイント


ポイント1)全プランRAID10構成のSSD採用 200GB〜
ポイント2)次世代nginxサーバーを採用
ポイント3)FastCGI、HTTP/2が使える
ポイント4)最安X10プラン 初期費用3,000円+1年契約で月額1,000円相当です。
ホストサーバーは20コアCPU & 192GBメモリのハイスペックサーバーです。このスペックを複数人で共用し、利用します。

公式で詳しくチェック=>エックスサーバー



mixhostのポイント


ポイント1)全プランRAID10構成のSSD採用 50GB〜
ポイント2)次世代LiteSpeedサーバーを採用
ポイント3)HTTP/2&QUIC完全対応
ポイント4)最安スタンダードプラン 初期費用無料+1年契約で月額980円相当です。
ポイント5)VPSのようにユーザーごとメモリ、CPUなどのリソースが割り当てられます。(3vCPUs / 2GBメモリ〜)
ホストサーバーは24コアCPU & 256GBメモリのハイスペックサーバーです。

公式で詳しくチェック=>MixHost



JETBOYのポイント


ポイント1)RAID構成のSSDを採用しています。
ただし、SSDデータベース&HDDのハイブリットSSD構成のサーバーもあるようです。
ポイント2)次世代LiteSpeedサーバーを採用(LiteSpeedエンタープライズ版) 、LScacheプラグインも使えます
ポイント3)HTTP/2完全対応
ポイント4)最安ミニSSDプラン 初期費用1,000円+1年契約で月額290円相当です。
ポイント5)VPSのようにユーザーごとメモリ、CPUなどのリソースが割り当てられます。(1コア / 512MBメモリ〜)
ホストサーバーは24コアCPU & 256GBメモリのハイスペックサーバーです。

スタンダードプランは、ストレージ40GB、3コア、メモリ2GB構成で初期費用3,500円+1年契約で月額1,280円相当です。

公式で詳しくチェック=>JETBOY




まとめ


今回ご紹介したサーバーはいずれもお試し期間があります。ホストサーバーのスペックはほぼ横並びです。お試し期間でパフォーマンスをチェックし、Google上位表示しちゃいましょう!

最新記事
最新コメント
タグクラウド
カテゴリアーカイブ