プロセスが多くてはメモリ浪費がひどい

朝にBlogにアクセスすると異常に重くて、状況を確認しようとするとSSHアクセスも重い。

MySQLなど一時停止して、再起動すると立て直せたが、いろいろ重くて、

始業前にいろいろ対策をしていた。


これまでBlogではデータベースシステムを使ってなかったんだな。

ところがWordPressを使うのは不可避だとMySQLを導入したら、これがリソースを食ってた。

ただ、MySQLについては負荷軽減のための対策はこれといってなく、

対策をしたのはそれ以外の部分である。


結論から言えば、メモリの消費がひどかったんだよね。

# free

RAMはほぼ全部を食い潰し(メモリの余裕はavailableの数字をみるとよい)、スワップすら半分以上使ってた。

このVPSの契約がメモリ1GBというケチな契約なのがそもそも悪いのだが、

簡単に増量できなさそうだし、少ないメモリ消費でもパフォーマンスを維持できる仕組みを考えることに。

まずは現状分析のためにプロセス毎のリソース消費量を調べた。

# ps aux --sort=-%mem

これでメモリ消費量順に並ぶのだけど、筆頭はmysqldでしたね。

でもmysqldは1つだけなんですよ。

複数のプロセスに分断されてるものを合計して考えると一番ひどかったのはphp-fpmだったんですよね。

あと使ってないのに消費してたという点ではsssdというのがあって、認証関係のデーモンらしいが使ってないのは確実なので無効化した。


php-fpmとはなにかという話だが、これはPHPを使ったことあるひとでもなじみがない人は多いかも。

このサーバーでは以前よりPHPをfastcgiを使って動かしてきた。

FastCGIは本当に速いけど…それだけ?

それがいつしかphp-fpmというもので管理されるのが標準になったらしい。

なんとなく旧来のApacheプラグインとして動くPHPと似てきた気もするけど、あくまでも違うものなのかな。

とはいえ、これが一番良さそうなのは確かなのでphp-fpmを採用している。

ユーザーディレクトリに限ってはこのとき書いたのと同じFCGIWrapperを使う方法にしてるけど。


で、php-fpmは標準設定だと最大50個までプロセスを動的に増やせるらしく、多すぎるプロセスにメモリが食い潰されていたらしい。

というわけで適度な個数に制限することで、メモリの浪費を防ぎパフォーマンスを保てるわけである。

/etc/php-fpm.d/www.conf にて、下記の通り設定した。

pm = static
pm.max_children = 4

これが一番効いたかな。


他にもこういうものはある。ApacheもDovecotもそうである。

Apacheだとこんな感じで

StartServers 2
MaxClients 2
MaxRequestsPerChild 128

プロセス数2は少なすぎるかなぁ。

Dovecotについては、imap-loginが標準設定ではログイン要求毎に作られるのが問題で、

これは多くのログイン要求(総当たり攻撃も含む)でプロセス数が際限なく増えてしまうということである。

ただし、imap-loginをログイン用要求毎にプロセスを作るのはセキュリティ強化のための方法らしく、

下記の設定はパフォーマンス重視の設定であることに注意が必要である。

/etc/dovecot/conf.d/10-master.confにて、

service imap-login {
  (略)
  service_count = 0

これでもimapプロセスは接続毎にできるけど、これは実際使われている分なので仕方ないということで。


こんな対策でとりあえずメモリの空きは確保できるようになった。

ただ、やっぱりきついですね。RAM 1GBのVPSは無謀だったかなぁ。

いろいろあるかもしれないけど、パフォーマンスは犠牲にしても、

なにかあっても身動きが取れなくなるほど悪化することは避けられるようにカスタマイズしていきたい。


あとSSHのログインが遅い件については、こういうカスタマイズもした。

ログイン時の処理で使っていないもの、あまり意味のないものを切ったという話。

UseDNS no
GSSAPIAuthentication no

もちろんGSSAPIを使っている人は有効にしないといけませんが。

プッシュ通知が使えてなかったのは設定ミス

今さらなんですけど、AndroidタブレットでIMAPのプッシュ通知が有効にできた。

Androidのメーラーとしては「K-9 Mail」を使っている。

おそらくAndroidでは唯一のSSL/TLS証明書認証を使えるメーラーで、

これがあるから証明書認証を使えているというところはある。

マイナーな認証方式ではある

まぁそれ抜きにしてもAndroidでIMAPのメーラーといえばこれだと思いますが。


で、今までもIMAPのプッシュ通知は有効にしていて、スマートフォンの方はそれで即時通知が来ていたのだが、

タブレットの方はプッシュ通知は飛ばないし、数分に1回の自動更新も期待通りに動かない。

どうなってんだと思ってたら、電池の設定のせいだったらしい。

電池→アプリ起動で、K-9 Mailの「自動的に管理」を無効にすれば、メールが届いた瞬間にプッシュ通知が届くようになった。

実はスマートフォンでは同じ設定をちゃんとやっていたというだけの話で、

とはいえ、なぜそのことをあまり意識してなかったのかというと、

こちらでは同設定はアプリの権限設定などと並んであるので、非常に気づきやすかったんですね。

MediaPad M5を使うようになって2年間、このことに気づいてなかったのがアホらしい。


もう今どき、メールサーバーを設定して……なんてE-mailの使い方をする人も減っただろうなぁ。

スマートフォン・タブレットならGmailアプリなど入れて、PCならWebメーラーを使ってと。

IMAPというプロトコルも、これを意識して使う人はそう多くないかも。

ただ、内部的にはIMAPを使っているようなメールアプリもありそうな気はしますが。(Yahoo!メールとかそんな感じがするけど)

IMAPの特色として、基本的にはメールサーバーにメールを置きっぱなしにして使う(POP3だと受信後に削除するのが通常だった)、

なんていうのはよく言われる話だけど、その次ぐらいの特色がプッシュ通知ではないかと思う。

IMAP IDLEという機能らしいのだけど、コネクションを維持しておくと、

メールボックスにメールが届いたらサーバーから教えてもらえるわけですね。

これにより、ポーリング間隔を数分と長めにとっても、メールが届いたら即時に通知が入るというわけである。

短い間隔でポーリングを繰り返されるよりもメールサーバーの負荷軽減にもつながるとされている。


今どき、そこを意識してE-mailを使う人は減ったと想うけど、うちは自分でメールサーバー動かしてるからね。

どうしてもここら辺の設定は意識して使うことになる。

ただ、IMAPとしてはこの機能があって、アプリが対応していても、

それがAndroidの電池マネージメントでつぶされるというのは難しいね。

K-9 Mailはこれ切っても大した電池消費はしないけど、アプリによってはこういう対策は必要なんですよね。

マジックコード、ただしバイト順が逆

今日は出勤して作業していた。

作業自体はわりと短時間で終わる話だが、実機を使うとなると出勤してやらないとね。

無事に完了して、作業完了後にハードウェアを他の担当者に引き渡して、

なんともなければこれでいけるはず。


今回はプログラムに簡単なチェック機能を組み込むものである。

コマンドを送ると、チェックして、判定結果を格納するというもの。

判定結果は0と1でもいいのかもしれないが、偶然OKに見えてしまうと嫌だなと思い、

OKの場合は0x900DDA7Aという値を格納することにした。

“gOOD DATA”ってことですね。Tはちょっと無理がある気がするけど。

NGの場合は明確に別の値を格納するし、チェック結果の格納前に読んでしまっても偶然OKになる確率は極めて低い。

(手順を守ってやればそんなこともないはずだけど、視覚的にわかりやすいのはよいことである)


それで実行したら、なんか変な値が格納されていて、初期化ミスでもしたか?

と思って、よく結果を見たら “7A DA 0D 90” というデータ列で、

これリトルエンディアンで見れば 0x900DDA7A ってちゃんと格納できてるなと。

そうだ、マイコンは4byteのところにリトルエンディアンで代入しているけど、

判定する側はビックエンディアンで見ている(他の部分も大半そうなっている)から、こうなるのか。


というわけで、これ自体はわりとあるあるなので、バイト順を入れ換える処理を追加しようかと思ったのだが、

よく考えたら代入する値は定数なんだから、

0x900DDA7Aのバイト順を入れ換えて代入する処理を書くのも、0x7ADA0D90という値を代入するのも意味は変わらない。

というわけで代入する定数の定義を 0x7ADA0D90 に書き換えて、

「ビックエンディアンでの0x900DDA7A」というような注釈を入れておいた。

こうして期待値通りの結果が得られるようになってめでたしめでたし。


しかし、本来は視覚的にわかりやすいという理由でこういうマジックコードを使っているのに、

そのマジックコードのバイト順を入れ換えた、一見よくわからない値を代入するのはちょっと納得感のないところはある。

そういうもんなんですかね?


というわけで実にしょうもない話でしたとさ。

チェック処理も過去に作った処理の転用で非常にシンプル。

ただ、これを作り込むことで製造上のメリットがあるということでやることにした。

姑息というのはこのことだが、製造時にしか使わない機能なので姑息でもいいかなと。

PCとスマートフォンの切り分け方

新しいBlogになって、あんまり見た目が変わらないと思った人もいると思うが、

一方でスマートフォン・タブレットで見ている人は、サイドバーがサイドになくなったことに気づいたかも。

画面幅の小さな端末ではサイドバーを下に持っていくようにしたんですね。

PCでも画面幅を狭めていくと、この表示を体験することができる。

あるところで、サイドバーが消えて、右上に▼が表示され、これをクリックするとサイドバー相当の内容に飛ぶ。


これは画面幅に応じてCSSの動作を切り分けているからである。

@media (min-width: 900px) {
  .absolute-sidebar {
      float:left;
      width:30%;
  }
  .site-content {
      float:left;
      width:70%;
  }
  .secondary-link{
      display: none;
  }
}

900pxよりも画面幅が大きい場合は、サイドバーを画面幅の30%、コンテンツ本体を70%として、左右に並べると。

その上でサイドバーへ飛ぶための▼も必要ないということで表示から消している。

900px未満の場合はこの部分が適用されないので、▼は表示されるし、

コンテンツ・サイドバー共々幅100%で、通常通り上から下にコンテンツが並ぶという形になる。


このような形になったのは参考にしたテーマがこういうものだったから。

  • サイドバー相当は通常は表示されていない
  • ボタンをクリックしたときだけ表示される
  • 画面幅が広い場合は画面の右一部を割いて、狭い場合は画面全体に覆い被さる

これは複雑すぎたが、画面幅が狭いスマートフォンなどで常にサイドバーを表示する不都合はあるわけで、

画面幅によって表示方法を切り分ける部分は採用したということである。

こういうサイドバーが常に表示されるデザインはスマートフォン時代にとっては古風だが、

PCではこのスタイルはやはり使いやすいわけで、使えるところは使ってスマートフォンでも見やすいようにしたと。

(もっとも、こんな文字だらけのBlogはそもそもスマートフォン向きではないのだが)


ただ、これをやるためにはもう1つ仕込みがいるんですよね。

<meta name="viewport" content="width=device-width, initial-scale=1">

これをHTMLの冒頭に書いておく必要がある。

これはスマートフォン・タブレットだけに適用されるものだと思うのだが、

この書き方をすると、デバイスごとに決められたピクセル数を画面幅とみなして表示することになる。

手持ちのスマートフォンだと425px、タブレットだと630px(いずれもAndroid)になってるみたい。

viewport について (Just another memorandum) : Viewport 確認用

width=360とか書くと、どんなサイズのスマートフォン・タブレットでも360px幅とみなして表示される。

デザインを固定できる一方で、画面の大きなタブレットでは不適かなということで、device-widthということで端末お任せにしている。

ちなみに端末を横向きにすると、タブレットでは900px超となりPCと同様の表示になる。

これもwidth=device-widthとするメリットである。


さっきの425pxとか630pxというのは実際の画面サイズとは違う値である。

昔はiPhoneが320px、Androidが360pxが典型的な値だったが、画面の大型化により少し拡大する傾向にある。

width=320とかwidth=360とか指定することが多いのは、この頃の数字を引きずってるということか。

結局、その頃との相対値でいろいろ言ってるので、現状とはいろいろ合わないんですよね。


これをAndroidのChromeで「PC版サイト」にすると、画面サイズによらず980pxを基準にして表示することになるようだ。

典型的PCが980pxなんですかね。

さっき900pxが閾値だと書いたので、PC版にすればスマートフォンでもサイドバーが右側に出る。

viewportが指定されていない場合(すなわちスマートフォン用ではないページ)も同様とみられる。

なので、こうやって見ると、旧Blogをスマートフォンで見た場合とそんなに変わらないと思う。


PCとスマートフォンで大きく見た目が違うページも、

意外にこういう画面幅の切り分けで実現されていることがあるんですね。

だからPCでもズリズリと幅を変えていくと、スマートフォン同様の表示になることがあると。

なかなかどのデバイスでも見やすいというのは難しいところはあるのだが、

自分自身が、PC・タブレット・スマートフォンをどれも使うので、

それぞれの性質によって見やすくなるように工夫しているつもりである。

PCはWindows、スマートフォン・タブレットはAndroidということで、他OSでは事情が違ったりするとは思うが、

それでも大崩れしないようにはしているつもり。(どうにもまずかったら教えてくれるとありがたい)

OSもPHPも新しくなりました

前々から話題にはしてましたが、OSのバージョンアップが完了しました。

OSバージョンアップの障壁はPHP

移行後のOSは「CentOS Stream 8」ですね。

CentOSに対する方針の変更はいろいろ言われたが、長く使うことを考えればこれがいいんじゃないかと。

VPSサーバーに備え付けのインストールメディアには当然無いので、

ネットワーク版のインストールイメージをダウンロードして、VPSにアップロードしてという手順を踏むことに。

でも、これで正真正銘、最新のOSになったのでしばらくは安心。


いろいろ戸惑いはあって、serviceもchkconfigもなくて、systemctlコマンドになってたり、

iptablesがなくなってて、firewalldになってたり、慣れるまではいろいろありましたが。

そういうのを乗り越えても最大の問題はPHPのバージョン移行であり、

特にBlogのシステムが全然使えないと、WordPressへの移行を決断し、

過去のBlog記事を全移行してはURLの一貫性を保つという、まぁいろいろめんどくさい話もありました。

WordPressに古いBlogを集約

それもなんとかメドが立ったので、よっこいしょと移行したわけですね。


WordPressになって、いろいろ検討した結果、トラックバックは廃止することにしました。

もともとスパム対策としてトラックバックURLの発行にワンクッション入れたりしてたが、

そもそも使う人なんていないだろと全廃を決断した。

WordPress独自のPingBack機能を含めて使わないということである。

あとは、旧システムのコメントも移行しなかったが、DISQUSの分は旧Blogで付いたものもちゃんと見られるようになってる。

URLの一貫性が保たれているので、こういうことも問題なかったんですね。


実はいろいろな工夫はあるのだけど、それは追って。

でもとりあえずこれでOSが古いという課題は解決できたので一安心。

WordPressに古いBlogを集約

先日、サーバーOS移行の最大の難関はPHPのバージョン移行であるという話を書いた。

OSバージョンアップの障壁はPHP

移行先はWordPress以外にないだろうということで、格闘していたが、

とりあえず今のBlogと似たような見た目を作ることができ、記事移行もなんとかいきそうなところまで来た。


方針はこうだろうというのはすでにあって、

あと、URLの一貫性もできれば保ちたいので、そういう観点でもどうするかなと考えている。

なにしろ、今のBlogのプログラムを移行するというのはもうできないわけですから、

静的なHTMLを現行システムで吐き出して、これを何らかの方法で表示するというのが有力なところ。

現在のBlognPlusと、その前の掲示板ベースのシステムと、そしてWordPressで新規に書く記事、

いずれもWordPressで管理するという形にせざるを得ないが、ここでの課題は3つあると考えた。

  1. 現システムでレンダリングしたデータを取り出す
  2. 取り出したデータをWordPressに取り込む
  3. URLの一貫性を維持する

ただ、調べたら1.は以前にそういうプログラムを(なぜかPerlで)作っていたので、これを流用すればよさそう。


2についてはWordPress同士のデータ移行をXMLで行う仕組みがあるので、

WordPressになりすまして同形式のXMLを作成することで移行することにした。

意外となんとかなったが、一部の記事の移行に失敗するので何故なのかと悩んでたら、どうもこういうことがあるらしい。

WordPressのインポート処理を改良 (AT-CENTRAL)

まさにこれが問題でしたとさ。なんで1行8192bytes制限なんだか。


そして、最後のURLの一貫性を維持する部分だが、まだ作り込み途中だがだいたい方針は決まった。

WordPressにはslugというのがあって、まぁページ名だね。

標準ではタイトルから生成される。例えば”Hello world”というタイトルなら”helllo-world”のように。

ただ、これは日本語だと不都合ですからね。タイトルの日本語がURLに入ったBlogがあって違和感があるけど。

で、このslugというのは一応は各投稿に好きなものを設定することができる。

そして、ページへのアクセス手段として /wordpress/slug のように使うことができる。


これを利用して作成時期の違う記事にそれぞれ下記のようなslugを付けることを考えた。

  • 旧システム(掲示板ベース): read-xxxxxxxx (read.php/xxxxxxxxに対応)
  • 現システム(BlognPlus): blogn-xxxx (index.php?e=xxxxに対応)
  • 新システム(WordPress)新規記事 : wp-xxxx (xxxxは記事のID)

新規記事はwp_unique_post_slugの処理に噛ませて、強制的に付け直す方法が紹介されている。

本来は同じslugが重複するのを回避するための処理だけど、

ここで日本語を含むslugが付いてしまう可能性を回避する処理を入れるのはわりと一般的らしい。

“read-xxxxxxxx”・”blogn-xxxx”・”wp-xxxx”のいずれの形式にも該当しない記事のslugは強制的にwp-xxxx形式に書き換えてしまうわけだ。


その上でApacheのmod_rewriteで、URLの形式を変換してやる。

/d/read.php/xxxxxxxx は /d/index.php?name=read-xxxxxxxx という具合に。(このURL書換はユーザーには見えない)

こういう形にすれば、従来からのURLの一貫性を維持することができる。

さらにページへのリンクもこの形で作り直す処理を入れれば、

slugがread-xxxxxxxxの記事へのリンクは/d/read.php/xxxxxxxx という形にすることすらできる。

というわけでURLは全く変わらないわけですね。


まだいくつかやるべきことはあるけど、PHPのバージョン移行のためにBlogのシステムを乗り換えるという、

最も大がかりなことはとりあえずなんとかなりそうな気がしてきた。

なんやかんや言っても多機能なシステムなので、いろいろ工夫はできるわけですね。

今月中か来月頭に移行すれば、現在のVPNの更新前には移行できるので目論見通りですね。

AndroidでもiOSでもWindowsでも

今日から「ウマ娘 プリティーダービー」のDMM版の配信が始まった。

DMM版っていうが、まぁWindows版ですね。

スマートフォンとセーブデータを共有できるということで、家ではPC、外ではスマートフォンという遊び方ができる。


そういう遊び方ができるゲームというと、同じCygames製のゲームだと「グランブルーファンタジー」とかそうだけど、

ただ、あれはブラウザゲームなんで、根本的にブラウザでの表示さえできればOKなんですよね。

DeNAのAndAppで提供されてるけど、結局はChromeなんじゃないかという気がする。

UserAgentさえごまかせば、普通にPCのブラウザでプレイできるからな。


一方のウマ娘は3D描画をガンガン使うゲームですから、ブラウザゲームとは全く事情が違うわけである。

とりあえずDMM GAMESのアプリをダウンロードして、そこからウマ娘をダウンロード、

さらにウマ娘のゲームを立ち上げてから数GBのデータダウンロードを経て動くようになった。

ダウンロード保存先として指定したフォルダを見てみると「umamusume.exe」というのがあるので、

DMM GAMESのアプリでは、このWindowsアプリケーションを呼び出しているようだ。

同フォルダに「Unity」なんとかというものがあって、おそらくUnityというゲームエンジンを使ってるんだろう。


ここで気づいたのだが、スマートフォン版と言うけど、実際にはAndroid版とiOS版が両方ある。

これに加えてWindows版を加えたというだけなんですね。

実はこのウマ娘というゲーム、スマートフォンの縦画面を想定したゲームで、PCでも基本的には縦画面で表示して使うんですね。

こんなところからも、PC版としてのカスタマイズは少なく、単純にWindowsで動くようにしただけだと。

もちろん、有料アイテムの購入方法が、AndroidだとGoogle Play経由、PCだとDMM経由という違いはあり、

そういう部分のカスタマイズはあるわけだけど、おそらくそんなもんなんじゃないか。


ウマ娘のゲームは育成モードのプレイ時間は長くなりがちで、3D描画を多く使うのでスマートフォンの電力消費が激しい。

電池消耗もさることながら、発熱により性能が制限されカクついたりすると。

残念ながらAQUOS sense3は本ゲームで想定しているよりは非力なスマートフォンとみられ、

それ相応ということで画質を下げる設定をしているが、それでさえ発熱と性能不足は課題である。

じゃあPCだとよいのかというと、これも残念ながら5年前のAMD APU(A8-7670K)では性能をフルに使っても不足している。

タスクマネージャー見たらCPUとGPUの3G描画がほぼ100%に貼り付いてるのを見たときには恐ろしいゲームだと思ったね。

とはいえ、スマートフォンでやるのに比べれば性能は安定しており、大画面に表示して使えるなどPCでプレイするメリットは多い。


もちろんスマートフォンゲームとしての良さはあるが、こうしてDMM版が出て思うのは、

これは家でスマートフォンを発熱させながらプレイするゲームではないということである。

ただ、PCの要求スペックも高いので、PCだから快適とも断言できないところは難しい。

ある程度、性能が高いものが用意できるならメリットはあるけど……って感じですね。


なんてわけで、このPCも性能の衰えを感じたのだった。

ケチケチ構成ではないけど、もともとそんなに高性能じゃなかったのが5年経つとさすがにねぇ。

この間にRyzen APUもできたわけだし、組み替え時かなという思いはあったが、積極的に動く理由も乏しかった。

なにしろ今まで高性能が要求されるゲームをすることはなかったからね。

強いて言えば4K対応ですけど、これもゲームしないならあんまり関係ない話だし。(cf. 4K HDRだとHDMIの限界が見える)

まぁちょっと検討し始めようかなとは思った。というかもう5年経ってたんですね。

OSバージョンアップの障壁はPHP

実は最近、VPSを追加で1つ借りていて、これはOSバージョンアップのため。

OSのバージョンアップは大変ですから、注文すれば1時間で用意されるVPSの良さを生かして、

新しく借りたVPSで環境を構築して、完了したら移行して、今使っているVPSは解約すると。

契約期間の関係で、3ヶ月もオーバーラップがあるので、ちょっともったいない気もするけど余裕があるのはいいことか。

なんて着手前には思っていた。


いろいろ操作方法にも変化が多く(このあたりはまた改めて)、慣れるまではいろいろあったが、

なんやかんや言ってもRedHat系のLinuxではあり、慣れれば早いものである。

メールサーバーは現在とほぼ同じ構成で立ち上がるところまできて、

じゃあ次はWebサーバーだなと、Apacheを設定し、PHPを設定し、FastCGIとの組み合わせで使おうと思ったら、

やり方が変わってきて戸惑いつつも、なんとか立ち上がっただが……


ここで大きな問題が発覚して、実はこのBlogのPHPが動かないことが判明したのである。

というのも、新しいOSではPHP7.2を使うことになっているのだが、

このBlogのプログラムにはereg関数など、PHP5.3から非推奨で、PHP7.0で削除されたものがいくつもあったのである。

ちょっとなら手修正でなんとかと思ったが、さすがに量が多くて大変。

BlognPlusはとうの昔に配布が終了しているので、すでに修正されたものがあるわけでもない。


実のところ、PHP5.6だってもうサポート期限が切れているのである。(最近まで認識できてなかったけど)

なので、PHP7への移行は不可避であるものの、ここのところの影響は小さくなく、わりと困った問題らしい。

実際、ごまかしてPHP5.6を使い続けた方がはるかに楽だが……よくはないよね。

いろいろ検討したものの、もはやBlognplusを使い続けることに無理があるので、

他のエンジンへの乗換を検討している。といっても選択肢なんてほとんどないんですよね。

WordPressになると思います。王道ですけど、もうそれしかないですね。


ただ、WordPressはできることが多い分だけ複雑なので、どうしてカスタマイズしたもんかなと。

あと、URLの一貫性もできれば保ちたいので、そういう観点でもどうするかなと考えている。

なにしろ、今のBlogのプログラムを移行するというのはもうできないわけですから、

静的なHTMLを現行システムで吐き出して、これを何らかの方法で表示するというのが有力なところ。

ただ、どうするのかというのは難しくて、いくつか案を考えている。


というわけで、余裕があると思ってたけど、本当に3ヶ月かかってしまうかも。

いやー、まさかPHPのバージョンが変わるとそこまでのことになるとは……

まぁBlog以外のPHPはおそらく大丈夫だと思う。大した物はないけどね。

IMが好みかメールが好みか電話が好みか

職場の委員の仕事でセキュリティパッチの適用状況を確認しているという話を書いた。

セキュリティパッチ適用できてるの?

それで適用状況の確認を全員に対してE-mailで依頼して、不明点があれば問い合わせてとしたら、

ちょっとしたコールセンターみたいな感じになってた。それは大げさだけど。


IM(インスタントメッセージ)での問い合わせを推奨したところだが、なかなかそうもならないもので。

結局、問い合わせが全部IMで済んだのは1/3ぐらいかなぁ。

なんやかんやとE-mailで飛んできた問い合わせが1/3ぐらい。返信はIMで飛ばした分はあるけど。


残り1/3ぐらいは、電話ですかね……

いろいろなパターンがあって、相手からIMで「今いいですか」なんて投げてきて、

そこからテレビ電話に移行するというパターンですね。

PCの画面を見せながら説明したいという理由でこれをやった人はわからなくもないが、

それIMでもよかったんじゃないのかなぁというのはある。


逆に自分から記入事項の確認をするのに電話を使った人が何人かいる。

確認したいことがあって、IMを投げてみたが、一向に既読にならないので、

こりゃダメだなと内線電話をかけてみるわけである。

IMにしても電話にしてもそうだけど、相手が会議中のステータスのときに掛けても仕方ないわけで、

そこを様子を見て、今ならすぐ反応できるはずというところを狙ってIM投げるが、それでもIMがさっぱり効かない人はいる。

そういうときには内線電話が確実なわけである。

ところが、今日はそれで内線電話を掛けたら、電話を持ちだしてないのか通じなくて「おいーーー」ってなって、

テレビ電話をかけて見たら、これは取ってくれて、IMには反応しないのにこれは取れるのか……と困惑したのだった。

(IMもテレビ電話もどっちも同じアプリなんですがね!)


以前より在宅勤務のお供といえばIMという思いはあったが、このあたりの普及度は微妙ですね。

IMはリアルタイム性が高くて、文字でのコミュニケーションということで融通が利きやすいんですが、

どうも一定程度、IMに全く反応しない人ってのはいるんだよね。

E-mailを送ってもすぐ反応しないわけだから、こうすると電話しかないわけである。

それなら電話でいいといえばいいのだけど、めんどくさい。


一方で、1対1でIMを使うのはいいんだけど、多人数でIMを使うのは慣れない。

確かに何人にも同報でメールの行き来が繰り返されるのは、それはそれでおかしいような気がするが、

その代わりに何人も同じIMに参加するのは違うんじゃないかなという気はする。

この辺もいろいろな考え方があるとは思うんですけどね。

楽だがファイル転送が遅い

最近、タブレットに画像データを転送をあれこれとやっている。

PCとタブレットでデータをやりとりする方法は2つあって、

1つはmicroSDカードを取り外してカードリーダで読み書きする方法。

もう1つはUSBケーブルでつないで、タブレット側で「ファイルを転送」を選んで接続する方法。


普通はUSB接続じゃないの? と言われそうだけど、microSDを介する方が転送速いですからね。

データ量が多いときはそっちの方が便利ではある。

このあたりは端末にもよるが、HUAWEI MediaPad M5はSDカードの取り出しにピンは必要だが、

そうしてトレイを取り出したとしても、動作の継続には特に問題はない。

このあたりは携帯電話回線に接続されないタブレットPCゆえというのはある。

これをスマートフォン(SHARP AQUOS sense3)でやると、構造自体は似ている(トレイ取り出しにピンが必要ないが)、

こっちはトレイにUSIMカードが混載されているので、抜くと携帯電話として使えなくなるんだよね。

なので、スマートフォンで大量データ転送をやるときは一回電源を切って抜いて転送している。


とはいえ、ピンが必要だとか、スマートフォンだと電源を切る必要があるというのはめんどくさいんだよね。

そこでUSB接続で転送する方が便利じゃないかという話である。

ところで、このスマートフォン・タブレットのUSB接続、一般的なUSBストレージとは挙動が違う。

MTP(Media Transfer Protocol)という方式を使っているからなんだけど。

もとはカメラ用のデータ転送方式だったのを拡張した物らしい。


USBストレージではなくMTPという方式を使うのは、ファイルシステムに依存しない方式だからというのと、

もう1つはハードディスクなどと違って、機器自身と接続先からのファイルアクセスが競合する可能性があるので、

そこで競合が発生したら待たせる仕組みを持たせられるというのが理由らしい。

そういう仕組みゆえに安全に転送できるわけですね。ファイルシステムを壊す危険性は低いと。

しかし、ハードディスクへのアクセスと比べれば複雑なもので、スピードは遅い。

データ転送自体が遅いというよりは、ファイル操作のオーバーヘッドが大きいんだろうと思う。

ここは不満を持っている人もいるんじゃないか。


あと、実は無線LAN経由でデータ転送するというのも答えとしてはある。

Samba(Windowsの共有)に対応したファイルエクスプローラーを使えば、タブレット側からやりとりできるわけだし。

案外そっちの方が速かったりするんだよね。あんまりやらないけどね。


正味のファイル転送の速度だけ言えば、多分microSDを取り外してやる方が速いのだが、

実用上は難しい面もあるので、やっぱりUSB転送じゃないかと思うが、それは遅いと。

そんなわけで悩みはあったが、時間がかかるのは待てば終わるというわけで、

しばらく放ったらかしにしてゆっくり転送させている。

大急ぎでやりたい理由がなければ楽な方でよい。そう考える方が楽ですね。