フォーラム:アクセスカウンタの無効化

出典: 謎の百科事典もどき『エンペディア(Enpedia)』
ナビゲーションに移動 検索に移動
フォーラム:メインページ > アクセスカウンタの無効化 終了
このフォーラムは既に終了しています。返信や話題の追加はご遠慮ください。
  • 題名通りですが、アクセスカウンタの無効化を行いたいと考えております。理由は次の通りです。
  1. アクセス毎の SQL 文が発行され、その分記事に関係のない形で無駄にデータベースサーバーへ負荷をかけることになります。
    • Yahoo のニュースからリンクされた際、読み込みだけでなく更新の SQL が実行されていたことにより、アクセス不能に陥りやすい状態となっていたように推察されます。
  2. ページのキャッシングができない、もしくは効果が薄くなる。 これの上述の大量アクセス対策が講じずらい原因になります。
  3. ページ閲覧速度低下の可能性。 わずかですが、読み込みと同時に毎回 SQL を発行する以上、遅くなっている可能性は否定できません。
  4. データベース障害発生時の原因特定に大きな支障を来す。…ページアクセスごとにアクセスカウンタを更新するための SQL が実行されることによって、データベースサーバーに不具合を生じた際、原因の特定と復旧が困難になる可能性があります。

要約すると、サーバー管理者の立場としては、ページの編集を行うわけでもないのに毎回更新 SQL を発行されると、問題発生時に余計な SQL 実行履歴が増えて特定作業に無効化状態以上の手間と時間を要することになるわけです。

まずはコメントを募りたいと思いますが、特に投票実施に対する反対意見が 1 週間以上にわたってないようであれば、投票へ移りたいと思います。--Rxy (トーク) 2014年5月11日 (日) 19:07 (JST)

投票資格[編集]

Enpedia:方針#投票権の方針 に準ずる。

投票[編集]

賛成
反対

コメント[編集]

念のため確認しておきたいのですが、アクセスカウンタが無効化されると一般利用者にとっては画面下の"このページは○回アクセスされました。"がなくなったり特別:人気ページがなくなったり特別:統計の閲覧に関する部分がなくなったり、ということでよろしいですか。--庵濁 (対話|履歴|勘定|資料) 2014年5月11日 (日) 19:30 (JST)

はい、その通りです。加えて、{{NUMBEROFVIEWS}}が使えなくなります。--Rxy (トーク) 2014年5月11日 (日) 19:47 (JST)
有難うございます。--庵濁 (対話|履歴|勘定|資料) 2014年5月11日 (日) 21:06 (JST)
  • まだ利用者が多くない過疎段階のこの時点から技術的な問題だという理由でMediaWiki標準で有効になっているビューカウンターを無効化してしまうのは、一般利用者には腑に落ちないですね。ウィキペディアと同じになるわけですが、アンサイクロペディアやChakuwikiなどの更新の多いMediaWikiサイトでは今現在もビューカウンターは有効になっていますし、それらのサイトよりも規則の緩いエンペディアがこれを無効化してしまうと何だか残念な気がします。サーバーの負担も一時的な程度であれば、そこまでする必要があるのかと疑問を掲げる人も少なからずいるかもしれませんが、、とりあえず他の方の意見も待つ。--Fievarsty (トーク) 2014年5月11日 (日) 21:01 (JST)
    • 自分もこのカウンタにはなくなってほしくはないです。特に、閲覧数が少ないEnpediaでは自分が作った記事が閲覧数1000とか10000とかの大台に乗った時には活動のモチベーションも上がりますし。--庵濁 (対話|履歴|勘定|資料) 2014年5月11日 (日) 21:06 (JST)
      • この提案に至ったのは、mw:Requests for comment/Removing hit counters from MediaWiki core というコメント依頼を見たことで、別にアクセスカウンタの機能であれば、態々負荷・コストの高い SQL 方式を使わなくても、Google Analytics や適当な PHP やその他 CGI でもデータベースを用いない方式を利用したアクセスカウンタは無数にあるわけで、それらを埋め込めば十分に代用できるはずですし(Google Analytics は既に埋め込んでいます)、目的も達成できるはずです。前回の復旧時に xml インポート方式を利用したのは、大量の「ゴミ」のごとくあふれかえったアクセスカウンタの更新を実行する SQL 履歴によって、止む終えず 5月5日 以降の編集を割り出し、スパムアカウントは復帰しないといった加工を施すことが困難となったためです。このゴミを取り除こうと正規表現に基づく置換を行おうとしたものの、この実行履歴を記録したファイルが重すぎて、まともに私のマシンスペック(オーバークロックをかけても)では処理できなかったのです(かろうじて、オーバークロック状態でアカウント状態の更新がなかったことを確認する単純な検索だけはできました)。アンサイクロペディア型でいいのならそれでも構いませんが、これが意味するところは、アンサイクロペディアで障害発生時に一部のデータが吹っ飛ぶことはよく知られていることと思います(俗にいう記憶喪失)が、エンペディアでも障害発生時にはそうなるということです。こちらとしては、ディザスタリカバリ(災害対策)として大阪と北海道のデータセンターにある2つのサーバー間でデータベースのデータをレプリケーション(複製)し、仮に片方のサーバーが完全にお亡くなりになってしまっても(そもそもVPSの本体サーバー自体が RAID 1 だったか RAID 10 を組んでいますが)もう片方から復旧できる体制はあるのですが、スタッフのオペレーションミス(誤操作)や データベースアカウント情報が洩れて外部からの攻撃を受けた場合、その他 MediaWiki 側で脆弱性が存在し、万一 SQL インジェクションなどの攻撃を受けた場合等でデータが吹っ飛ばされるなどの SQL コマンドが実行された場合、レプリケーションサーバーにもそのコマンドが伝達されてデータが吹っ飛びます。この場合、基本的にはデータベースをすべて真っ新な状態にして、バックアップからデータを読み込ませ、バックアップ以降に行われたデータは前述の SQL 実行記録より復旧を試みます。その際、アクセスカウンタの更新ログは、データ削除に至った SQL コマンドの特定と除去作業に大きな障害となります。簡潔にいうなれば、MediaWiki コアのアクセスカウンタ機能を停止する代わりに、障害発生時を考慮してアカウント情報や記事情報の保全と復旧を優先するか、アクセスカウンタを優先する代わりに、障害発生時のアカウント情報消失やページ情報の消失、もしくはバックアップ地点までのロールバック(巻き戻り)を容認するかの二者択一です。--Rxy (トーク) 2014年5月12日 (月) 03:10 (JST)
        • そうでしたか。確かにsql方式だと無駄なリソースの増加やデータベース容量の消費のおかげで、サーバーの負担が生じやすいか知れませんし、メンテナンス時は苦労を要するかもしれません。。閲覧数がとても多いウィキペディアでこれを停止をしている意味やアンサイクロペディアが重い理由が分かった様な気がします。--Fievarsty (トーク) 2014年5月20日 (火) 19:46 (JST)
  • アンサイじゃ数年前から閲覧数反映されてないしWikipediaじゃキリがないし、って感じですね。ゆくゆくは停止させてもいいと思うんですがこの規模じゃまだ停止させる必要はない気がします。--ルソペソ (トーク) 2014年6月27日 (金) 23:42 (JST)
    • アンサイクロペディアはビューカウンターは有効になっていますが、更新しても反映されていないんですかね(最近のアンサイは良く知らない)。私もサイトの規模的に考えれば無効化は必要ないとも思っていますが、rxyサーバーはエンペディア以外にも使われていますし、それに関連した全体メンテナンスの支障のことも考えれば、そうも行かないと思います。一応他のシステムによる代用のカウンターを設置するとも述べていますので、サーバーのことを考えれば、現在の負担がかかるようなSQL方式カウンターよりは、代用カウンターがいいようにも思えます。ただ特別ページやマジックワードが廃止されてしまったり、フッターの閲覧数表示や、これまでのカウンター数もどうなるか気になるところですが。--Fievarsty (トーク) 2014年6月28日 (土) 01:55 (JST)
      • サイトの規模なんて、アクセスカウンタに相関関係はあっても、直接的関係はありません。アクセスカウンタはアクセスされた分だけカウントを行うわけですから、たとえ記事数が 1 ページでも、100万/月アクセスあったと仮定すれば、大変なことになるわけです(いつぞやの Yahoo砲はその好例)。現在のところ 5万 PV/ 月 あるわけですが、そのカウントは 5万回分の SQL 分を毎月サーバーに対して発行していることになるわけです。するとアクセスが増大すれば最終的には Enpedia のアクセス速度も致命的に落ちることになり、管理者側としては最悪、サーバーからの追い出しを検討しなくてはならなくなります。-広告が導入できて、Enpedia 用にサーバーを用意できるほど収益が望めるなら別ですが。-Rxy (トーク) 2014年7月28日 (月) 08:00 (JST)
  • 代替アクセスカウンタの方式についてですが、今まで同じように各ページについてアクセス数を計測したり、一般利用者がアクセス数を確認したいときに自由に確認したりできるのでしょうか?---BadEditor 2014年7月3日 (木) 15:08 (JST)
    • それをやるとなると、ちょっと面倒くさそうですねぇ。。。標準名前空間だけに絞るとしても、記事数分の「カウンタファイル」が必要になるわけですが… (といっても、データベースを使っても最終的にファイルとして保存されるんですけどね!)--Rxy (トーク) 2014年7月28日 (月) 08:00 (JST)

結果[編集]

投票にて反対がなかったため、無効にしました。代替手段として、Google Analytics によるアクセス解析結果を一般利用者でも見れるようになる seethestats というサービスを利用した 日次更新アクセス解析 を公開することにしました。--Rxy (トーク) 2014年8月30日 (土) 22:02 (JST)