皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

私もここ最近で気づかされたことがあります。

Webサーバーの『Apache』が『Apache 2.4』からアクセス制御の記述方法が大きく変わっていることを。

Apache2.4におけるアクセス制御

『.htaccess』などに記述するアクセス制御ですが、『Apache 2.2』と『Apache 2.4』では記述方法が異なります。

例えば、すべての要求を拒否する場合に『Apache 2.2』では

Order deny,allow
Deny from all

と記述していましたが、『Apache 2.4』では

Require all denied

と記述します。

ただし、多くのホスティング会社では従来の『Apache 2.2』の記述方法でアクセス制御が可能となるよう、『Apache』に『モジュール』を追加して対応していると思われます。

それならば問題はないのでは？

となるところですが、

サーバーの高負荷などが原因でその『モジュール』が正常に動作しないことが発生すれば別です。

『500 Internal Server Error』となりWebサイトが表示されなくなります。

つまり、そういったエラーの要因を一つでも減らしておくには『Apache 2.4』の記述に変更すべきと言えるわけです。

明日に続く。。。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

さて、今日は数日前にご紹介したPHP5.6系のパフォーマンス改善の続きです。

前回はPHPのコア部分に関するチューニングでしたが、今日は拡張機能部分に関してご紹介します。

PHP5.6系のパフォーマンスチューニング２

前回のコア部分では、以下の3つのことに関して触れました。

１．『output_buffering』

２．『memory_limit』

３．『replath_cache_size』

これにプラスαで、『OPcache』や『APCu』が使える（編集可能）のであれば、それも使ってみると良いです。

では、『OPcache』から。

『OPcache』が使える（編集可能）場合、以下のようにphp.ini（.user.ini）を編集してみてください。

※　他のシステムに影響を与えないようにしたい場合、可能な限り『.user.ini』を作成し、そこに記述することで全体への適用を避けられます。ただし、『PHP_INI_SYSTEM』項目はphp.iniでしか変更できません。また、サーバシステム側で制御されている場合には変更できません。

zend_extension = /path/opcache.so（例です）

opcache.enable = 1

opcache.enable_cli = 1

opcache.memory_consumption = 128

opcache.interned_strings_buffer = 8

opcache.max_accelerated_files = 4000

opcache.revalidate_freq = 60

opcache.fast_shutdown = 1

次に、『APCu』が使える（編集可能）場合、以下のようにphp.ini（.user.ini）を編集してみてください。

extension = /path/apcu.so（例です）

apc.enabled = 1

apc.enable_cli = 1

apc.shm_size = 64M

以上のような感じになります。

ただし、これらはCGI版（FastCGI版）での書き方になりますが、サーバがモジュール版PHPを採用しているのであれば『PHP_INI_SYSTEM』項目が大半ですので、.htaccessでの対応は不可となります。

つまり、モジュール版PHPが採用されている場合、サーバシステム側での設定のままということになります。

＜参考＞

『OPcache』は高性能なPHPアクセラレータで、パフォーマンスを向上させます。

『APCu』はユーザーキャッシュ機能を持ち、翻訳処理などの最適化処理に役立ちます。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

少し前に、『PHP7.2系のパフォーマンス他』という記事ではPHP7.2系のパフォーマンスなどに触れ、『EC-CUBE2.13系のPHP7対応』という記事ではEC-CUBE2.13系のPHP7対応が未だ開発者向けのαバージョン状態であることに触れました。

では、PHP5.6系ではパフォーマンス面を諦めるしかないのでしょうか？

PHP5.6系のパフォーマンスチューニング

PHP5.6系とは言え、まだ諦める必要はありません。

それなりにチューニングしてあげることによってある程度パフォーマンスは向上します。

まず、php.ini（.user.ini）を以下のようにしてみてください。

※　他のシステムに影響を与えないようにしたい場合、可能な限り『.user.ini』を作成し、そこに記述することで全体への適用を避けられます。ただし、『PHP_INI_SYSTEM』項目はphp.iniでしか変更できません。また、サーバシステム側で制御されている場合には変更できません。

１．『output_buffering』の値を『On』もしくは『4096』としてみてください。

例：output_buffering = On（output_buffering = 4096）

２．『memory_limit』の値をデフォルトの『128M』より大きくしてみてください。

例：memory_limit = 1280M

３．『replath_cache_size』の値をデフォルトの『16K』より大きくしてみてください。

例：replath_cache_size = 4096K

これらはCGI版（FastCGI版）での書き方になりますが、サーバがモジュール版PHPを採用しているのであれば、.htaccessに記述することで対応可能です。

ただし、『PHP_INI_SYSTEM』の場合は.htaccessでの対応はできません。

１の例：php_flag output_buffering On（php_flag output_buffering 4096）

２の例：php_value memory_limit 1280M

３：.htaccessでの対応不可

これ以外に『OPcache』、『APCu』が使え、その設定が変更可能なサーバを使われているのであればまだプラスαがありますので、後日改めてご紹介したいと思います。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

先日、あるセキュリティ企業がAndroidデバイスに関してこんなことを発表しました。

安価なAndroid搭載機種のファームウェアで新しいTrojan Android.Triada.231を発見しました。
この検出以降、感染したデバイスのリストは絶えず増加しています。
現時点では、リストには40以上のモデルが含まれています。

Androidの出荷時点における危険性

このセキュリティ企業が確認した『Android.Triada.231』は俗にいう『トロイの木馬』の一種で、公表された記事には以下のように書かれています。

重要なAndroidシステムコンポーネント、Zygoteのプロセスに感染します。このプロセスは、すべてのアプリケーションを起動するために使用されます。トロイの木馬がこのモジュールに注入されると、実行中の他のアプリケーションに侵入します。そうすることで、彼らはユーザーの介入なしに様々な悪意のある活動を実行する能力を得ます。つまり、彼らはひそかにソフトウェアをダウンロードして起動します。 Android.Triada.231の主な機能は、サイバー犯罪者がこのトロイの木馬をlibandroid_runtime.soシステムライブラリに注入することです。彼らは別のプログラムとしてトロイの木馬を配布しません。その結果、悪意のあるアプリケーションは製造時にデバイスファームウェアに侵入します。ユーザーはすでにボックスから感染したデバイスを受信します。

この『トロイの木馬』を確認したことはデバイスメーカーに通知されたようですが、メーカーが対応をしないまま新しいモデルにも感染拡大したとされています。

さて、そこで冒頭の質問に戻ります。

モバイルデバイスを選択する際、私の場合は確率的にどちらが安全かを考慮します。

結局のところ、iOSデバイスを選択するか、Androidデバイスを選択するかになるため、現時点においてはiOSデバイスを選択し続けています。

安全性の比較論だけで選択しているわけでもありませんが、リスクの少ない方を選択することは非常に重要です。

参考：Doctor Web: over 40 models of Android devices delivered already infected from the manufacturers

皆さん、こんにちは。

業務改善を行う業務コンサルタント、高橋です。

ウェブサイトを構築する上で、時には表示の高速化を図るためにファイルを圧縮したり、Apacheのモジュールを使ってサーバからブラウザに転送されるデータをコンパクトにしたりすることがあります。

しかしこれが、ケースによっては思わぬものをもたらす場合があったりもします。

.htaccessなどへの記述

gzip圧縮をさせるためには.htaccessなどに対して『mod_deflate』というモジュールを使った記述をします。

細かい説明は省きますがこのような感じです。

↓

<IfModule mod_deflate.c>
SetOutputFilter DEFLATE
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|ico)$ no-gzip dont-vary
SetEnvIfNoCase Request_URI _\.utxt$ no-gzip
Header append Vary Accept-Encoding env=!dont-vary
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/javascirpt
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/atom_xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/x-httpd-php
</IfModule>

↑

ファイルを圧縮するとは

前述のこととは別にファイルそのものを圧縮するというのは、htmlファイルなどにおいて改行する度にできるムダな空白を削除してしまい、1Lineにしてしまうといったことです。

これはツールを使えば一瞬でできてしまいます。

例えば、通常は

<html>
<head>
</head>
<body>
<div>
</div>
</body>
</html>

と順番に改行しながら記述しますが、これが

<html><head></head><body><div></div></body></html>

といったような感じになり、ファイル容量的には小さくなります。

gzip圧縮と圧縮ファイルでの問題

このgzip圧縮とファイルの圧縮の両方を行った場合でも通常は問題は起きないはずですが、ファイルの圧縮を行ったツール、もしくはホスティングサービスなどの仕様などによっては文字化けしてしまうケースがあります。

その場合、

１．ファイルの圧縮を別のツールで行ってみる

２．.htaccessなどに記述したgzip圧縮の設定を無効にする

３．htmlファイルなどを圧縮ファイルから非圧縮ファイルの状態に戻す

このような対処になります。

圧縮されたファイルと非圧縮のファイル、それぞれをgzip圧縮した場合のサイズは若干圧縮されたファイルの方が小さくなりますが、ページスピードポイントとしてはおそらく同じです。

従って、gzip圧縮、もしくはファイルの圧縮のどちらかを行っていれば圧縮的には十分と言えますので、無理に両方行う必要はないでしょう。