I know, seems promising, doesn't it, especially after the overview in
the DBI book. On the other hand, you can do most things another way -
SSH port forwarding for encrypted data transmission, straight DBI/DBD
available for most dbs, etc.
Bill McCabe wrote:
>
> That's a shame. I can see good use for it. Is it the RPC chunk that is slow
> and unreliable or the DBI part? Or has no one really pursued making a
> production-quality module out of it?
>
> Bill
>
> At 11:24 AM -0700 9/19/00, Tom Lancaster wrote:
> >My experience of using DBI::Proxy several months ago is that it's
> >terribly slow, and breaks all the time.
> >It's not meant to be used in a production environment ( and that's
> >according to the authors ).
> >
> >I managed to get it running, on linux and NT, but due to the lack of a
> >working fork() or threads support in perl on NT, I could only use a
> >single instance of the server at a time.
> >If you can get it working *nix to *nix, your mileage may be better.
> >
> >Regards.
> >
> >Bill McCabe wrote:
> >>
> >> Hi All
> >>
> >> I'm thinking of restructuring my setup so that I have my apache/mod_perl
> >> servers access database servers remotely using DBI::Proxy, rather than
> >> locally. Does anyone have a sense of what kind of performance degradation I
> >> should expect? Will it come chiefly from network latency (leaving
> >> encryption out for the moment)? Also, I've never managed to install
> >> DBI::Proxy successfully on any system (AIX 4.2.1/4.3.2/4.3.3, Red Hat
> >> 6.0/1/2; perl 5.005/5.6.0; apache 1.3.12/mod_perl 1.24). The tests always
> >> fails for the RPC piece. Is the RPC module typically this problematic?
> >>
> >> TIA
> >>
> >> Bill
