△▲　WebProg 初心者の質問 Part19　▼▽

>>951
ブラウザ組み込みのインタプリタに対してという意味なら、
プロセス起動や構文解釈の分当然遅くなる。

>>952
ありがと。じゃあ止めておくかな。
遅くなるって、どれぐらい遅くなる？
１秒以上は掛かる？

ごく小さいPerlなら300msecは遅くなるんじゃねーの？

>>952
ブラウザ組み込み・・・？

質問です

↓見たいなhtmlで、
----
<input type='button' onclick='hogehoge();'>
----

↓みたいなjavascriptで、
----
hogehoge () {
alert("test");
　document.frm.submit();
}
----

複数ページで何箇所か同じような事をしているんですが、
一箇所だけ、何故かfirefox限定でsubmitが動いてくれません。
alertのtestは出るので、hogehogeは実行されていると思うのですが。。
あと、エラーコンソールには何も出ていませんでした。

formタグとか、nameがfrmになっているかとか、ケアレスミス系は全て確認しました。
というかIEとoperaで確認すると、普通に動きます…orz

この状態で、何か思い当たる原因って考えられますでしょうか？
アドバイス宜しくお願いしますm(_ _)m

全部載せないとエスパーにしかわからんよ

>>952
>>951 は CGI とかサーバーサイドの話かと思うよ

>>956 よい子はローカルルールを読んでね

>>956
submitボタンがあるとsubmit()が利かなかった気がする
まぁ試してないけど

質問です。perlとアパッチで掲示板のようなものをつくりたいのですが、

サーバー負荷を考えて、テキストデータと画像のデータを２つのサーバーに
わけて保存する仕様にしたいと思っています。

それを実現する方法は、どういったものがありますでしょうか？
できれば、テキストを登録するcgi部分（仮にAとする）を窓口として画像登録も済ませることが
できる構造にしたいのです。記事番号をAからうけとって画像をアップロードを受け持つ
cgi部分は別サーバーにCGIをおいて、画像送信完了画面で、Aの部分に飛ぶという
ことしかないでしょうか？

そうした場合は、（不正な）画像だけ登録して、掲示板の閲覧cgiを参照せずに
ダイレクトに画像だけをみるということも可能ですが、これを投稿が完了しない
かぎり画像は有効にならず一定時間後に破棄されるといったギミックを仕組みた
いのですが、テキスト保存（掲示板表示）サーバーと画像保存サーバーとの
連携など、なにかアイデアがないでしょうか？

Aの処理の最後でBにコミット飛ばすようにするしかないんじゃね。
プロトコルはてきとーに。

でも普通はテキストと画像を分けるんじゃなくて
同じ処理をするサーバーを複数用意するんじゃないかねー。

普通にサーバ1のスクリプトA内でサーバ2に画像をコピーしてやればいいんじゃないの

>>961
投稿時に、画像と記事を一緒のHTTPでアップしてもらうようにすれば何でもできるでしょ。

Aサーバーは、受信完了したら、まずBサーバーに画像を転送して、それが成功したら記事
を登録すればいい。記事と画像の関連づけは、書き込み内容のデータファイルを作って、
それでやればいいじゃん。例えばタブ区切りで、URLエンコード(でも何でもいいけど)した
記事とBサーバーでの画像のパスを入れておくとかしてさ。

AからBへの画像転送は何でもいい。FTPでもSCPでも、フル権限設定できるサーバーなら、
NFSでマウントしたディレクトリに直接コピーしてもいいと思う。もしくは、BサーバーにHTTP
で画像を受信できるスクリプトを入れておいて、そのスクリプトが、Aサーバーからの送信し
か受け付けないようにしてもいいわけだし。

>>961
全てをSSL配下に置くのでも無い限り、
サーバ負荷を気にして、テキストと画像を別サーバに置く必然性は無いと思う。
回線も全く別と言うのならば、帯域分散にはなるけど。

>>963
>>964
それって負荷分散どころか負荷増えてるだろ。

>>961がどの処理の負荷を分散させたいのかがわからん。
漏れは、画像ファイルのContent-TypeをIEが無視することによって起こるXSSを排除するために、
画像ファイルの正当性を検証する処理かなと思ったのだが。

なんで？投稿より閲覧のほうが頻度高いんだから投稿時に適当に処理してやればいいじゃん
それとも投稿時の負荷低減が目的なの？

普通に考えたら投稿より閲覧の回数が圧倒的に多いだろうが、
正確なところは>>961じゃないとわからんな。

>>966
何の負荷が増えていると思う？
いまの情報内で。

画像の転送負荷のことなら、A⇒Bがそれほど遠くないサーバーなら
特に問題ないのかと思ったけど。

こんなこと言い出したらキリがない。
画像って言ってるのが例えば医療用工業用の画像とかだったりして
実は数百MBあったりするのかもしれん。

>>961の質問の仕方が悪いでFA

Yahoo のように画像を置くサーバーを別にしたいんだろうね

サーバー A (CGI)
サーバー B (IMG)

A と B にそれぞれ 100Base NIC と 1000Base NIC が１枚ずつある
A と B はそれぞれ別回線 (100Base) である
A と B は Gigabit Ethernet で繋がっている (default gateway 設定無しのローカル通信のみ)
A に対して画像がアップされると B に即座にコピーされる

これなら負荷軽減出来るでしょうけど、画像系 あぷろだ でも無かったり、日あたり数十万 PV もなければ、
気にするだけ無駄ですよ。

みなさん、沢山のコメントありがとうございます。もう少し具体的に書きますので、
引き続きおつきあいください。

先ほどは掲示板として書きましたが、それは例の話であって、オークション商品登録
閲覧システム、ブログ、記事システム、ショッピングの商品登録システム にすべて
共通する処理ですので、簡単に掲示板としただけです。個人的には、商品登録システム
やマガジン（記事）システムを作っていまして、972さんの指摘の通りヤフオクのよう
に商品ページ（記事ページ）のサーバーと画像送信サーバーを別に起きたいと考えたからです。

負荷分散の狙いは、単に、ユーザー閲覧時にテキストデータ（商品ページ）と
画像は別サーバーにしておけば、アクセス数が増えた時でも、画像送出でもたつく
ことはないだろうと思ったからです。（帯域分散という意味もあります。）もちろん、
そんな心配しても無駄というなら、画像サーバーをわざわざ分ける必要もないと思いますが。

基本的に、普通に登録cgiで商品説明や画像も登録できて、閲覧ページのcgiでは
画像は別サーバーから送信されるってことができればいいのですが。もちろん、
登録完了されていない商品の画像は表示されない（一定期間の保守プログラムで
仮登録データは削除する）といったことができるのが理想です。

また、登録閲覧するサーバー自体を複数に拡張した場合は、検索などでどの商品が
どのサーバーに記録されているかインデックスファイルを持たないといけなくなりますが
そういった部分での手法など、perlとアパッチで構成は可能なのでしょうか？

やはり、ロードバランサーとかもっと別次元の話になってくるのでしょうか？
持っているスキルはperlとちょっとしたアパッチの基本知識くらいなので、なにか
アドバイスをいただけると幸いに存じます。

>>973
ロードバランサーはこの際関係ないだろ。

その規模で考えてるなら、別に商品登録時の
画像の転送の負荷なんて微々足るものだろ。
閲覧数に比べれば。

商品登録時に画像を画像用サーバーに転送
すればいい。その手法なんて山ほどある。
んで、どこにアップロードするかは、商品ごと
に画像URL情報を持ってもいいし、商品のID
に紐付けたディレクトリを画像用サーバーに
作って、ファイル名規則だけで関連付けさせ
てもいいと思う。

あと、負荷分散とか考えるなら、商品や記事
を登録・検索する処理をRDBMSにしてもいい
と思う。件数が多くなったところでDBを別サーバー
にできるから。

>>974
画像用サーバーに転送する手法について、少しヒントをいただけませんか？
たとえば、レンタルサーバー１で登録したデータのうち、画像のみを
レンタルサーバー２に転送し、登録成功していないデータをレンタルサーバー２
から削除する、ということも可能でしょうか？

それと、データですが、テキストファイルで構成を考えているのですが、
検索用のインデックスファイルを用意しておけば、実データファイルを
10万件ずつに区切っておけば、特に問題がないように思うのですが、いかがでしょうか？

ちなみに、10万件ずつ区切るというのは例でありまして、
インデックスファイルで検索候補を絞ったあとに、商才表示用に
実データをあさるときに、10万行程度のファイルなら瞬時に該当
行を抜けると思いますし、それが書く10万件ｘ10個の合計100万件のデータ
でも、それほど問題ないと思うからです。

また、SQLだとどうしても、インジェクションなどの問題で複雑になりがちで
メンテにも神経を使います。という理由でテキストファイルにこだわりたいです。

>>975
何を言っているのかわからないぞ。

登録に失敗した、というのは、どんな条件なわけ？

あと、DBについては、DBのインデックス管理よりも
効率的なインデクシングが自前でできるなら、いい
と思うけど。でも、それを実装するコストの方を考え
ると、RDBMSを使った方が早いと思うけどな。

レンタルサーバーでもMySQLが使えるところは最近
多くなってきているよ。

組めば何でも可能だし、それならやってみればとしか・・・・ｗ

>>975
「socket ftp」

FTP/SCP/NFS(後者二つはレンサバじゃ辛いかｗ)
あとは、画像鯖と本体鯖をHTTPでつないでもいいと思う。
HTTPでつなぐなら、本体側からみた画像のファイル名を
抽象化できるので楽な管理ができるかもよ。

サーバーは１台まるごと借りられるプランで、２つ借りるんだよね？
それとも共有サーバーを２つ？



FTP で put するのが一番簡単かと。

例が多い人だな

http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=21843&forum=12
このサイトを見て勉強しているんですが、この人と同じように１０件や２０件ずつと
件数を指定して表示し、オーバーしたらphpのpear:pagerのように次にいかせる
方法をとりたいのですが、なにかいい方法ありますか？

ORDER BY してLIMIT OFFSETで

>>983
これとかは？
ttp://www.phpbook.jp/pear/pear_pager/

ASP.NET MVC 1.0 (.NET Framework 3.5 sp1)
Visual Web Developer 2008(C#)
SQL Server 2005 Express

ブログのようなシステムを作成中です。
一つの記事に対して、3つの画像をアップロードできる
ようにしたいのですが、そのアップロードされた画像
をどのように管理すればよいのか分かりません。

１）特定フォルダに全部保存
この方法だと、画像が増えた場合にディスクアクセスが
遅くなりそうな気がしますし、精神衛生上よくない気がします。

２）適当な数（1000ファイルくらい？）でフォルダ分け
1番の問題を考えての方法。何となくこっちの方が良い
ような気がしてます。

どちらの場合でも、「ファイルの振り分けやナンバリング」
をどのようにやるのか？という疑問も残っています。

画像ファイルはどのように管理するのが適当なのでしょうか？
また、画像ファイルを管理するためのテーブルや、プログラム？
を作成するものでしょうか？

投稿した記事は（画像も）ディスクが一定量になるまでは
保存し続ける、という運用を想定しています。

よろしくお願いします。長文失礼しました。

フォルダの中にファイル増えたら遅くなんの？
それwindowsのGUIで開いた時の経験の話じゃねーの？

>>987
まさしくその経験の話です。
あれは、ファイル情報もろもろを取得しているから
遅いのであって、ただ単にパスとして指定するだけなら
特に問題ない感じなんですかね？
「体感的には全く問題なし」ということも十分考えられますが、
定石としてはどのような管理がなされているかをご教示
願いたい、という質問の趣旨だと思っていただければ幸いです。

ファイルを抽出してHTTPで送り出すだけなら、
一フォルダにたくさんあって遅くなるのは数十万
ファイルのオーダーだよ。

気になるなら、容量は食うけど、SQLSVにバイナリ
で突っ込んでもいいんじゃない。画像の固有IDに
だけ、インデックスを貼るようにしてさ。

ファイルのメタ情報を拾ってくる分重いというのはそのとおりだけど、
ディレクトリエントリはひとつずつ線形に列挙して探すしかないので、
ファイル数が多いと目的のファイル名を見付けるまでに相対的に余計に
時間がかかる可能性はあるかもしれない。

それとも、最近のFSは、ファイル名からO(1)で実データに到達できるよ
うになってたりするんかな?

>>987
ファイルシステムにもよるけど遅くなったり
ディレクトリあたり32768個以上のエントリを置けなかったりするよ。

毎日２つエントリが増えると仮定して、画像ファイルは一ヵ年で最大２１９０個
２０まんこ許容するなら９０年たったら次のフォルダを作るとかどうでもいいレベルなので単一ディレクトリに押し込むのが普通と思うが
ブログでは月ごと、年ごとのフォルダ分けくらいはできるものがある
規定数のフォルダに均等に分けるなら例えばアップロード時タイムスタンプの下一桁で分けるとかなんとか。しかしExplorer的一覧性は皆無

>>990 じじい乙

じーさまは低速モデムでFTP接続してlistしたのを
シリアルコンソールで見る可能性がある。

皆様ありがとうございます。
情報の小出しをするな、と書いてあるにも関わらず、
情報漏れがあったことをお詫びします。
・Windows Server 2008 + IIS7.0
・ファイルシステム:NTFS
・レンタルサーバーの条件で、SQL Server の容量は
　　少なめに設定されているので、SQL Server には格納しない
という情報が漏れていました。
お話によると、とりあえず一つのフォルダに押し込んでしまって
良いようなので、そのようにしたいと思います。
タイムスタンプ下一桁で振り分ける方法は思いもよりませんでした。
今後、何かに使えるかもしれません。ありがとうございます。

教えて頂いてばかりで恐縮なのですが、もう一つお願いいたします。
ファイル名はシステム側で割り振らなければいけないと思うのですが、
どのように管理するべきでしょうか？

ただの連番にするにも、じゃあ誰がカウントするの？という疑問があります。
参照カウンタのようなデータをどこかで持っておいて、その値に基づいて
ファイル名をつけるような感じになるのでしょうか？

それと、僕は今、次スレの心配をしています。
どなたかお願いします。（と、僕が言うことでもありませんが）

>>990
O(1)は絶対ムリだろう。
XFSとかJFSとか最近できたfsは木構造使っててO(log n)。
ntfsはどうなんだろ。

連番なんてあなたの好きなようにすればいいんじゃない？

ファイル名はバッティングしないかぎりユーザが決めていいんじゃないの
DBで管理するならDBが勝手に割り当てるファイルIDと、ユーザが決めるファイル名を分けることもできる
というかDBで管理しないとアップロードした画像の管理画面作るのが面倒な木がする

>>994
残り少ない寿命で数万のファイルリストが送られてくるのを待つわけか

バッティングしたときだけインクリメントするってのはよくある仕様だな

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。