自動生成のものを適当に投げて終わり。先月と全く同じグラフの8月分です。
\t\u\s[10]\h\s[5]国税調査はそんなに負荷は与えていないと思いますよ。\w9\nボトル負荷のほとんどは配信時の一斉送信だそうですし。\w9\w9\uそこ、\w9まだ汚れ消えてないぞ。\n\n\w9\w9\h\n\n\s[4]‥\w9‥\w9‥\w9‥\w9\w9\n\n\s[6]\_sごしごし‥‥\e
最大の負荷は過去ログダウンロードです。一斉送信も、ログ500KBとか大量にダウンロードされるのに比べれば大したことじゃないですし、偶にボトルサーバが応答しなくなるのも過去ログ検索でDBが長時間ロックされることが原因です…
MySQLを最新版にするとある程度改善されるのは分かってるんですけど作業停滞してます＞＜
とりあえず今回の実質の作業はほとんど、サーバ自体の管理者である猫家さんに行って頂きました。(で、自分はのんびりお知らせ作り)
今後はGracefulは出にくくなると祈りたいところですが、実際のところまだ理論上完璧ではないので、ちょっと応答が引っかかるような事態も出てくるかもしれません。
あと、過去ログダウンロードについては「条件による」ので、例えば今日1日のログを単純に見る、とかだと全く問題ありません。その点はご安心を。
今回の緩和では、
という方針で、各LUID別に制限バイト数を計算しました。ただし「100瓶区間賞」の方は、複数瓶流そうと毎回の争奪戦に参加してようと関係なく、最大1000バイト加算です(該当LUIDは53件)。従って、最高の人で1900+1000+2000+3000=7900バイト、ということに。
これらのボーナスですが、1万を超えるIDそれぞれについてリアルタイムに計算することはとてもできませんので、次回以降、これらの基準で定期メンテナンス時に計算し直し、定期メンテ後より新しい制限が反映される、という形になります。この1週間で300票獲得した新星ボトラーの貴方も、長瓶解禁までは月初めの定期メンテナンスをお待ちくださいませ。
ここからはやや余談。
…何よりまず、何故か7900バイト権利者が26人もいるというこの事実。どうなってますか。
70万、80万、90万からの区間賞については、前から言っていたものです(70万瓶の時点で決めてて、実現までどれだけかかってるんだか)。あ、キリがいいので100万瓶目から100名の方にも1000バイトボーナスはあると思いますが、110万瓶目以降の区間賞はない予定ですのでよろしくお願いします。
「300票」「2000票」の基準が結構厳しめのように思えるかもしれません。一応、前者は「累計で票を最も得た、ほぼ上位200IDとなるカットオフポイント」、後者は「同、ほぼ上位50IDとなるカットオフポイント」ということで設定しています。といっても今後この基準を大きく変える予定はありませんので、まぁゆっくり流していれば誰でもいつかは、と。
余談ですが累計票数1位の方は、8月4日メンテ時のバックアップで計算したところ、18035票となっておりました。ますます余談ですが某ボトル管理人は685票。案外多かった…
\t\u\s[10]\h\s[3]自分のバイト制限を確かめるにはどうしたら良いんだろう。\u\w9\w9‥\w9‥\w9流してみるしか無いんじゃないか？\e
とりあえず…流してみてください(笑) 10KBくらいの瓶を流すと、サーバに怒られるついでに制限バイト数も教えて貰えます(忘れてた
\t\u\s[10]\h\s[0]負荷かかりそうな処理やな。\u\w9泣く泣く削った経験があるやつってそんなにおるんやろか。\h\w9\n最近では２瓶に分ければエエわけやしな。\e
2瓶くらいならいいんですが、数十瓶に分けられてあまり短い間隔で投稿があると、投票やら投稿やらのCGIプロセス負荷が純粋に瓶の数の分かかってしまいますので、今回の件についてはある意味必然です。極端な話、100KB*1瓶の方が2KB*50瓶よりずっと負荷は低いわけで、分割が当たり前になってしまうのは普通に問題が。基準が厳しいので荒らしとかの問題も(多分)出にくいでしょう。
\u\s[11]\_sバイト数制限緩和っ！？\w9\w9\_s\w9\w9\h\s[4]\n\n\w9あと１日早ければ、\w920連瓶もせずに済んだのに…。\w9\w9\u\n\n…\w9ワイら、\w7いっつも何かとタイミングが…。
ごめんなさい、むしろ例の総集編XML読んでて「やっぱりこりゃ早急に緩和せねば今やらねばすぐやらねば」と思い立っちゃったので、タイミングは良かったということで。
過去に「1ヶ月間で2000票以上」得票することのあったボトラーは、LUIDベースで4人だけいました。そしてその4人が全員、2003年6月または2003年7月に達成してます。…一極集中?
\t\u\s[10]\h\s[0]瓶数は少ないが得票率の高い、真のネタボトラーを考慮してやな。\w9\w9\n各瓶の得票の二乗の合計を係数にして制限緩和かけるんはどうやろ？\w9\w9\u細かに得票するボトラーを蔑ろにする事にならんか？\e
というのに興味を持って計算してみたところ、Σ(votes2)ベースで計算した場合、2000ポイントで+2000バイト、10000ポイントで+3000バイト、と区切ると、今と人数構成的にはほとんど変わらなくなりそうです(ちなみにこの計算でのトップは20万ポイント超)。
…某煩悩超え瓶の人は一瞬でクリアですが、まあそれはそれで面白いのでアリかと。
一応机上の空論を示すと、「3票100瓶」スタイルで300票稼いだ人は、この新案で2000ポイントクリアするのは2倍大変。「8票40瓶」スタイルの人でほとんど変わらず。そして、「10票30瓶」スタイルの人にとっては2/3で2000ポイント到達でき、「30票10瓶」スタイルの人は5倍楽。
1万ポイント到達も、10票*100瓶、または、20票*25瓶なら比較的簡単(?)
単純なバイト数は出来るだけ考慮したくないです。長い瓶さえ書いていれば制限が伸びる、とかなるとシステム的な抑止力が働かなくなるので。
ちなみに、\w4データが計算できないらしく、\w4制限は５０００バイトだって。\w8\s[290]珍しい制限バイト数ゲッツ！\w8\w8\u\n\n‥‥\w8\w8\s[68]うれしいか？\w8\w8\h\n\n‥‥\w8\w8\s[401]いや、\w4あんまり。\w8\s[0]たまーにネタ瓶流してるから流石に３００票いってないってことはないと思うけど、\w4２０００票を超えてるかどうかわからなかったのは、\w4ちょっと残念だね。
区間賞該当かどうかまでは調べる気力なかったので、とりあえず該当、ということにしておいて、1900+1000+2000+おまけ100=5000、です。ええ、つまり、はい、そうです。
まぁ完全に趣味です。
\t\u\s[10]\h\s[3]実測する機能を付けたら、もっと正確にわかると思いますけど…\w9\u役に立たんわ。\w9\w9\e
精度を高めるために、頑張って重回帰分析(最小二乗法)を行って、SSPでいろんなスクリプトを再生・実測しまくって、再生時間を求める関数を得ています。その成果をクライアントにとりあえず組み込みました。このままリリースしてもそこそこ役に立ちますが、再生環境ごとにパラメータはいろいろ変わってくるので、その辺の対応考えてからリリースする予定。
…といっても毒子の瓶の再生速度は慢性的に絶対奈留より遅くなるでしょうし、そこまでは考えきれないんですが。
こんな感じです。AAアニメ系・超長文系・サーフィス切替え激しい系などの特徴的なボトルや、普通の会話系のボトルを取り出し、再生時間を実測して回帰分析してます(長文ボトルばっかりだったのでサンプル16本で限界…) 予測式の形についてはお察しください。単なる線形結合です。
サーフィス変更での負荷がほとんどかかってない(\sタグ1個辺り10ms未満)辺りがさすがSSPですね。半透明もONにしてあったにも関わらず。
この後でCharやDBCharはさらに細分化して処理しないといけない、と気づいたので実際は独立変数に7パラメータ切ってます。切片はまともな値が全然出てませんが、手作業による測定の誤差が全部ここに来てるみたいなので無視。あといろいろ考えた結果これ以上サンプル増やす意味もなさそうなので、ま、こんな感じ。
今までのところで気づいているのは、
といったところ。どこの世界にもこの辺言及した仕様はないので統一されてなくて当然なんですが、こういう微妙な癖を再現させるために7パラメータ切りました。3分近い瓶で±5秒の精度があれば十分でしょう。
とりあえずこういうプログラム作りました。
ダウンロード - Estimate.lzh
…1人であらゆる再生環境の数値整えるのは大変そうなので。あとはボランティア募集。
「自分が使っているプログラム用に最適化された再生時間予測が欲しい」、という方は、その環境で同梱のリファレンススクリプト全部を実際に再生・計測して、得られたCSVファイルを、サーバの名前・バージョン・環境・設定内容などとともに教えてください。多分作業時間は1時間くらいかかります。
とりあえずは代表的なSSTPサーバのデフォルト設定のまま再生したものは、クライアントに同封できるといいなーと。今のところ、SSPのノーマル速度と、S-Vのふつう速度で、概ねそれぞれ誤差5%以内を達成しました。materia & CROW & SSSBは手つかず状態です。
ちなみにこのプログラムのために書いたソースコードは180行。しかもそのうち50行はコンパイラが自動生成。あとの機能は全部、既に作ってある自作コンポーネント置いて配置しただけです。色分けエディタもFMO処理もDirectSSTPも、コーディングゼロ。そんな便利(?)なコンポーネントが沢山あるDelphiで、誰か開発しませんか～。オフラインのゴーストビルダーなんてすぐですよー。
アーカイブに同梱してないですが、再生時間予測プロファイル「SSTP-Viewr ふつう」
playtimeフォルダに放り込んでください。
2K以上の長文スクリプトでもない限りどっちもほとんど変わらないですが。長文スクリプトや特定の文字が多く含まれるようなスクリプトだと数秒くらい変わってきます。新S-Vは、なんだかクイックセクションの動作が遅い気がするので、3.6.1で最適化。
とりあえずここまでをまとめると、
| Player | 方式 | 1文字ウェイト | 半角 | ウェイト特殊文字 |
|---|---|---|---|---|
| materia | 逐次再生型 | 区点=多めにあり、読点=少なめにあり | ||
| SSP | 絶対時刻型 | 多段階、デフォルト50 | 全角と同一 | スペース=0、特定の記号=2倍 |
| CROW | 逐次再生型 | 多段階 | 全角と同一 | なし |
| SSSB | 逐次再生型? | 露わに設定、デフォルト40 | 全角の半分 | 区点=?倍、読点=なし |
| SSTP-Viewer | 逐次再生型 | 5段階、デフォルト50? | 全角の半分 | なし |
ある意味、見事に揃ってない(笑) 絶対時間での実装になっているのは現状SSPだけみたいです。