VPN経由でサーバーに接続

会社のほとんどのPCは同一フロアで販売管理プログラムを使っているのだが、2台だけはVPN経由で17kmくらい離れた事務所（H事務所）で使っている。インターネットはNTTの「隼」、ルーターはヤマハRTX810を使っている。環境は整えている方だと思う。

販売管理ソフトはAccess2007。PostgreSQL7.4.4のテーブル、ビューをODBCでリンクしている。

H事務所の2台のPCはVPN経由でサーバーに接続しているのだが、この動作がまあ、遅い。画面によっては開くのに30秒かかってしまう場合もある。サーバーを入れ替えたら改善されるかと思ったが、それほどでもなかった。結局、プログラムを見直すことにした。

これまで、複雑なクエリーはサーバーでビューを作っておいてリンクする形にしていた。クエリーを１回飛ばせば必要なデータが全て得られる。細かいクエリーを何度も飛ばすのではなく、クエリーの回数を極力少なくするようにしていた。その方が高速かと思っていたが、今回、見直しの中でそうではないことがわかった。

サーバー内のビューの作成はサーバー内で行われる。それをテーブルとして参照するAccessには何ら負荷がかからないものと思っていた。データは多少、大きいかもしれないが、直リンクした商品テーブルほどでもないので、通信量を考えると「商品テーブルを開くほどには時間がかかるはずがない！」と思っていたのだった。しかし、結果は商品テーブルが２秒で開くところ、複雑なクエリーで定義したビューは30秒かかってしまう。

試しにビューをやめて、Access内のクエリーをソースしてみてもやはりフォームが開くのに相当時間がかかる。クエリーのjoinをやめると、直ぐ開く。基礎となるテーブルには担当者CDが保存されていて、その担当者名をリンクしたテーブルを開くのは遅いのだが、基礎テーブルは直ぐ開く。データ量はそれほど変わらない。通信速度は関係なさそう。

じゃ、フォーム内の担当者名のソースをAccessのDlookupでレコードごとに問い合わせる形にするとどうかというと、これは直ぐ開く。クエリーの回数はこの方が格段に多い。なんせ、レコードごとに担当者名を問い合わせしているのだから。

同じフロア内のPCでは実用上問題ない速度で開くフォームも、VPN経由だと非常に時間がかかってしまう場合がある。複雑なクエリーをソースとしたフォーム。そのクエリーをサーバー内でviewを定義してやっても改善しない。フォームのソースはできるだけjoinしない単一テーブルにして必要な項目はDlookupで検索した方が高速、、、、、ということに。