オーマイニュースに『サイトメンテナンスのお知らせ』が告知されていた。
遅れ兄さんのブログのエントリ『予防のすすめ』でも取り上げられている。
告知内容には「このたび、サイトのパフォーマンス改善のため、下記日程でシステムメンテナンスを行います。」と書かれているが、効果の程については俺自身は懐疑的。
って何をするつもりかわかってないので当てずっぽうだけどねw。
DBの再編成をするんじゃないかなというのが最も予想されることであるが、これは効果が全くないとは言わないがそれほど期待できないと思う。
過去に『オーマイニュースにおける工作活動対策を妄想してみる（３／３）』等で多少触れているが、データの増加に対してリニアに反応する（性能劣化が起こる）ような設計だと怖い。
DBの再編成をして画期的な速度向上が期待できるのは、削除レコードの取り扱い（←これはDBMSによる）とテーブルインデックスの改善のみだ。
だから、もしDBの再編成をするだけならあまり変わらないのではというのが俺の予想。
一般的にどうするのがセオリーかはわからないが、取り扱いデータ数の上限を有限なものにするというのがひとつの方法だ。たとえばオーマイニュースなら、年度毎に別DBにするとかかな。
話題が変わるが、高速化関連での別のアイデア。
少し古い話しになるが、毎日jpがオープンした時に観察したところ、Keep-Aliveを全く使わないように設定されたいた。2chも確か使ってないはず。
不特定多数のidleユーザーが予想される場合には、本来高速化目的の為の仕組みであるKeep-Aliveがかえって負荷になるらしい。
まっオーマイニュースには今のところ関係なさそうだが、何事もノウハウが大切なんだなという一例として。
今回のメンテナンスで最も気になるのは、ぶっつけ本番かどうかだ。
一般的には、調査してボトルネックを割り出し、施行しようと思っている方法でそれが解決できるかどうかを検証した後に本番となるのだが、何せ今までが今までだからどうなのかなと。
まあ大手でも失敗する例があった（ココログとかw）くらいだからそんなに厳密さを求めても仕方がないのかもしれないけどね。
とにもかくにもがんばってください♡
遅れ兄さんのブログのエントリ『予防のすすめ』でも取り上げられている。
告知内容には「このたび、サイトのパフォーマンス改善のため、下記日程でシステムメンテナンスを行います。」と書かれているが、効果の程については俺自身は懐疑的。
って何をするつもりかわかってないので当てずっぽうだけどねw。
DBの再編成をするんじゃないかなというのが最も予想されることであるが、これは効果が全くないとは言わないがそれほど期待できないと思う。
過去に『オーマイニュースにおける工作活動対策を妄想してみる（３／３）』等で多少触れているが、データの増加に対してリニアに反応する（性能劣化が起こる）ような設計だと怖い。
DBの再編成をして画期的な速度向上が期待できるのは、削除レコードの取り扱い（←これはDBMSによる）とテーブルインデックスの改善のみだ。
だから、もしDBの再編成をするだけならあまり変わらないのではというのが俺の予想。
一般的にどうするのがセオリーかはわからないが、取り扱いデータ数の上限を有限なものにするというのがひとつの方法だ。たとえばオーマイニュースなら、年度毎に別DBにするとかかな。
話題が変わるが、高速化関連での別のアイデア。
少し古い話しになるが、毎日jpがオープンした時に観察したところ、Keep-Aliveを全く使わないように設定されたいた。2chも確か使ってないはず。
不特定多数のidleユーザーが予想される場合には、本来高速化目的の為の仕組みであるKeep-Aliveがかえって負荷になるらしい。
まっオーマイニュースには今のところ関係なさそうだが、何事もノウハウが大切なんだなという一例として。
今回のメンテナンスで最も気になるのは、ぶっつけ本番かどうかだ。
一般的には、調査してボトルネックを割り出し、施行しようと思っている方法でそれが解決できるかどうかを検証した後に本番となるのだが、何せ今までが今までだからどうなのかなと。
まあ大手でも失敗する例があった（ココログとかw）くらいだからそんなに厳密さを求めても仕方がないのかもしれないけどね。
とにもかくにもがんばってください♡
アタシが「定期メンテやろうよ」って書いたのはまさにその部分で、最初から
日時が決まっていればそこから逆算してスケジューリングできるだろうと。
昨日の記事更新が妙に早く終わった(18:35が最後)のが、1週間後の
本番を見据えて何らかのテストをやる為だったらいいなと思ってます。
データベースが壊れちゃって戻せなくなっちゃうとか、そういうことだけはないようにお願いしたいものです。
システムのオペレーションって、ゼロ・スタート社が請け負っているのかな？
確かにルーチンワークにするのはストレスをなくすいい方法ですね。だが(ry
>>名無しヲチャーさん
× たんなる読者のネタ
○ たんなるヲチャーネタ
w
重くなるといわれている時間帯はひょっとしたらバックアップ中なのかもと思いました。
元木編集長が以前にモバイル投稿機能の開発について触れていたので、ベンダーさんとの縁は続いていると思いますが、管理はわかりませんねぇ。
>たとえばオーマイニュースなら、年度毎に別DBにするとかかな。
DBを一本化しておいて、「クエリ」データを「テーブル化」して利用するイメージでよいのだろうか？
年末年始を前にして、いろいろとあって…ｗ。
webとは全然関係無いのだけど。
このイメージがわからないのでおいらがイメージしている事を書くと、単位毎に別テーブルあるいは別DBにするということ。
論理的には1テーブルで済むしそちらのほうが楽（奇麗）だとしても、実行効率まで考えると分割したほうが安心。
その分プログラム側が煩雑になるけどね^^;
例えば会計処理なら会計年度別に分けるのは割りと自然なことかと。
高度なDBMSとか使っていればクラスター化するとかで上記のような泥臭いことをすなくても済むのかもしれないけど・・・。