08/01/10 21:15:02 H6DpH7yaO
>>771
あなたが使っているサーバはあなた専用のサーバですか？
774:ss ◆Luxlnwkk4c
08/01/10 21:24:47 inaQtdqs0
>>772
鳥忘れてるしorz
775:携帯電話情報通知しません
08/01/10 21:31:05 hTwaWmjA0
>>773
だからそういう意味ではない。日本語の理解力乏しいな。
では逆に聞くが、2回に分割して5Mずつ、というのと
10Mが1回になった場合の負荷の違いはどれぐらいどう違うの？
リソースについて言うならその違いを言えるはず。
776:携帯電話情報通知しません
08/01/10 21:33:41 inaQtdqs0
一応立てておきました
URLﾘﾝｸ(www.skullysoft.com)
777:携帯電話情報通知しません
08/01/10 21:33:53 KSl24mLhO
俺は5M×2の方がリソース食うに100ペソ
778:携帯電話情報通知しません
08/01/10 21:34:12 S0MsdsfyO
>>771
一回の分割にかかる時間が長くなるのが問題。
鯖が一人の相手をする時間が長くなれば当然負荷があがる。
779:ss ◆EpS6tov5vE
08/01/10 21:40:14 inaQtdqs0
>>776
また、鳥忘れのageてるしorz
もうだめポ
780:携帯電話情報通知しません
08/01/10 21:41:09 H6DpH7yaO
>>775
公開サーバはあなた一人を相手にしている訳ではありません。
動画の取得、エンコードには通常の2chブラウジングに比べて非常に多くのネットワーク・メモリ・CPUリソースを消費します。
もし、あなたのPCにはHDDしか付いていないなら謝ります。
781:ss ◆Luxlnwkk4c
08/01/10 21:41:09 inaQtdqs0
>>779
鳥間違ってるしorz ホントｽﾏｿ
782:携帯電話情報通知しません
08/01/10 21:43:20 WT4XB8QA0
パケホ(フルブラウザ非対応のコース)ならこのアプリでyoutubeが無料で見れるんだね！感動した～
783:携帯電話情報通知しません
08/01/10 21:48:20 TNWt6jXF0
>>771
まあ、HDDの占有については確かにそのとおりなんだが、
例えばDLする時間が、10秒×2になるか、20秒×1になるかじゃ
10秒×2のほうが鯖には優しい。負荷が分散されるから。
784:携帯電話情報通知しません
08/01/10 21:50:11 S+4GCWrfO
javaだとレンサバ高いんだよな
かと言ってPC持ってないしなぁ
785:携帯電話情報通知しません
08/01/10 21:54:05 hTwaWmjA0
>>778
だとしたら5M*2より10M*1のが負荷は少なくなるはずだが。
>>780
あのね。5M*2の動画を取得するのと10M*1の動画を取得するの、
またそのエンコードに使われるメモリやCPUのリソース。
これの違いについて言ってるわけだ。
ネットワークとしてみたらセッションが二つに分かれた方が
当然だが負荷があがると普通は見るものだが。
この意味が理解できないなら生兵法はやめておいた方がいい。
786:携帯電話情報通知しません
08/01/10 21:56:24 hTwaWmjA0
>>783
負荷が分散・・・はされないんじゃないか？
CPUとしてみた時にスレッドをマルチスレッドにできるって意味でなら
確かに分散される可能性はあるけど・・・
確かロードバランサーを入れている鯖管がいたから
そこでならセッションを分割する意味はあるかもしれないけど、
結局同時にセッションを張れるわけではないしなぁ。
単純に回数を分けたところで、負荷は変わらないと思うのだが。
787:携帯電話情報通知しません
08/01/10 21:57:17 KSl24mLhO
糞細かい画像をDLするのと
一つにまとめたのをDLするのでは
糞細かい方が負荷かかるよな？
788:携帯電話情報通知しません
08/01/10 21:59:04 hnNpvZW0O
あーウゼェ
邪魔だから議論スレにでも行けよ！そしてそこで好きなだけ話せよ糞共！
789:携帯電話情報通知しません
08/01/10 22:00:26 H6DpH7yaO
>>785
あなたのPCはメモリの解放もできないのですか？もしくは、あなたの携帯でのダウンロードは、メモリの解放やCPUに別スレッドを振る間もないほど一瞬で終わるのですか？
もう一度伺いますが、あなたが利用しているサーバはあなた一人専用のサーバで他の端末からのリクエストは一切ないのですか？
790:携帯電話情報通知しません
08/01/10 22:01:29 hTwaWmjA0
>>787
普通であればね。マルチコア環境においてマルチスレッドでセッションを張れれば
分散効果が期待できる、という考え方もあるから環境次第なところもあるが、
ことこのアプリにおいてはセッションを同時に複数張れない以上は、
セッションのオープンクローズの分、負荷は上がると考えておかしくはないと思う。
791:携帯電話情報通知しません
08/01/10 22:03:58 hTwaWmjA0
>>789
だから生兵法は怪我の元。
携帯でのアクセスにマルチスレッド化する機能はないんだよ。
そのぐらいは調べてから喋れ。
あと他の端末からのリクエストは鯖自体は複数スレッドで処理をするが、
それが例えば5Mが2回くるリクエストの最中に割り込まれたから、
ってのと10Mが1回のリクエストの最中に割り込まれたから、ってので
負荷が変わることはない。
792:携帯電話情報通知しません
08/01/10 22:06:32 16BY2EVE0
ffmpeg起動にオーバーヘッドがある以上、分割数は少ないほうが負荷も少ない気がする
793:ＮなＡおＯ ◆NnAaOo/rh2
08/01/10 22:07:55 Imv2t4Ke0
とりあえずまだマシンはボトルネックにはなっていません。
２割もCPU使っていませんし。
HDDも速度はまだまだ余裕埋まる方が早い。のでしょっちゅう消す。
自分が重いと感じたら並列配置で負荷分散します。
794:携帯電話情報通知しません
08/01/10 22:29:00 TNWt6jXF0
>>786
確かに、連続再生で分割ファイルを連続DLするんだったら、一回のほうが負荷が小さいか。
俺はいつも一つずつDLしては見て、を繰り返すから、見てる間は鯖が自分以外のリクエストの処理ができるかな、
と思った。
795:携帯電話情報通知しません
08/01/10 22:36:08 hTwaWmjA0
>>794
自分以外のリクエストがいつ来るか来てるかがわからない以上、
そこはどうともいえなくない？
例えば5Mを2個の分割として、1個目をダウンロードしてる時に
別のリクエストが来ていたり、たまたま自分が動画を再生している時には、
リクエストが来てなかったのに、2個目を落とし始めた時に来てたら、
結局同じ事になってしまうからなぁ。
796:携帯電話情報通知しません
08/01/10 22:43:50 S0MsdsfyO
>>785
自鯖立ててログを見てみればわかるが、分割するためには複数回のffmpegを起動している。
当然分割サイズを大きくして1回で変換した方が、
その返還処理の効率が良くなるのはあなたの言うとおり。
ただしそのはあなたの投入した変換処理だけだったらという条件付き。
W2Chはffmpegが終了すると、変換処理の経過時間を計り、
一定時間を過ぎていたら返還を打ち切る処理が入っているようだ。
長い動画では転送が完了していても、一回で返還できないことが、あるのが証拠になる思う。
このタイミングでHTTPの通信がいったん切れ、再度変換の依頼を出すには数十秒の待たなければならなくなる。
この間鯖は重たい動画返還から解放されその他のサービスを効率よく行うことができる。
ここで分割サイズを大きくすると1回のffmpegの終了までの時間が長くなり、
変換打ち切りをするタイミングが少なくなってしまうのが問題になる。
数人が同時に動画変換依頼を出すと加速度的にLAが上がってしまうことになる。
797:携帯電話情報通知しません
08/01/10 23:04:17 Ncr7Doma0
ID:hTwaWmjA0 はグダグダ言ってないでてめえで作れよボケナス
798:携帯電話情報通知しません
08/01/10 23:07:18 Sh7AgNT/O
>>789
お前、一度も他人の質問にまともに答えてないよね
自分が間違ってると思うんなら、話そらしたり屁理屈言ったりしないで素直に謝ったほうがいいよ
799:携帯電話情報通知しません
08/01/10 23:08:57 hTwaWmjA0
>>796
その理屈だと逆におかしくならないか？
＞一定時間を過ぎていたら返還を打ち切る処理が入っているようだ。
＞長い動画では転送が完了していても、一回で返還できないことが、あるのが証拠になる思う。
これが本当なら逆に10Mにしようが5Mにしようが長かった場合は
いったん打ち切って変換処理を再度リクエストする事になる。
だとしたらサイズ関係なく「長い動画」とあなたが言ってる扱いに
ffmpegが扱った時は同じように打ち切るのではないだろうか。
800:携帯電話情報通知しません
08/01/10 23:32:39 S0MsdsfyO
>>799
逆コンパイルしてみたらわかるがffmpegの終了を待ってから、経過時間を計測し打ち切の判定をしている。
したがって一回の変換が長くなれば、打ち切の機会が減る。