Best architecture for CGI scripts accessing dbm file

This is a multi-part message in MIME format.

--===============1661153730==
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0095_01C830E1.41118060"

This is a multi-part message in MIME format.

------=_NextPart_000_0095_01C830E1.41118060
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi

I have a CGI script which among other things ties to a dbm file in order =
to do look ups on certain CGI parameters. Performance is ok but I wonder =
whether it is efficient for each call to the script to open a tie to =
what is essentially the same data and whether it will suffer under load. =


I tried to find out more about how tie works but it is not clear to me =
whether or not it loads the whole dbm into memory. If it does then I =
would like to assess other ways of doing this.

I suspect implementing mod_perl or ISAPI when I have not used them in =
much before is too much work and unknowns for this urgent critical task =
(though if this sounds wrong let me know!)

So my question is whether there is a another way of sharing this data =
between many CGI calls which is as fast and light on memory as possible. =


One idea I had was to set up a SOAP or XML RPC server which has the tied =
dbm and responds to calls from the CGI scripts with the specific info =
required for each one. A round the houses way of doing it perhaps but =
one that I can get my head around (and give me a chance to play with =
writing a SOAP or XML RPC server).

But I thought I would run it past you in case you could point out any =
obvious things I had missed or had your own ideas about an elegant =
solution to this.

Or should I really look at mod_perl/ISAPI, CGI::Application or something =
else?

Or is it fine to keep doing it the way I am?

I do intend to try some benchmarking but some pointers as to which =
options are worth focusing on would be a huge help.

Thanks
Mark



------=_NextPart_000_0095_01C830E1.41118060
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I have a CGI script which among =
other things
ties to a dbm file in order to do look ups on certain CGI parameters.
Performance is ok but I wonder whether it is efficient for each =
call to the
script to open a tie to what is essentially the same data and whether it =
will
suffer under load. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I tried to find out more about how tie =
works but it
is not clear to me whether or not it loads the whole dbm into
memory. </FONT><FONT face=3DArial size=3D2>If it does then I would =
like to
assess other ways of doing this.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I =
suspect implementing mod_perl or ISAPI
when I have not used them in much before is too much work and
unknowns for this urgent critical task (though if this sounds =
wrong
let me know!)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>So my question is whether there is a =
another way of
sharing this data between many CGI calls which is as fast and light on =
memory as
possible. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>One idea I had was to set up a SOAP or =
XML RPC
server which has the tied dbm and responds to calls from the CGI scripts =
with
the specific info required for each one. A round the houses way of doing =
it
perhaps but one that I can get my head around (and give me a chance to =
play with
writing a SOAP or XML RPC server). </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>But I thought I would run it past you =
in case you
could point out any obvious things I had missed or had your own ideas =
about an
elegant solution to this.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Or should I really look at =
mod_perl/ISAPI,
CGI::Application or something else?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Or is it fine to keep doing it the way =
I
am?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I do intend to try some benchmarking =
but some
pointers as to which options are worth focusing on would be a huge
help.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Mark</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV></BODY></HTML>

------=_NextPart_000_0095_01C830E1.41118060--


--===============1661153730==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ActivePerl mailing list
ActivePerl [at] listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
--===============1661153730==--
Mark Knoop [ Di, 27 November 2007 11:35 ] [ ID #1880283 ]

RE: Best architecture for CGI scripts accessing dbm file

From: activeperl-bounces [at] listserv.ActiveState.com
[mailto:activeperl-bounces [at] listserv.ActiveState.com] On Behalf Of Mark
Knoop
Sent: 27 November 2007 10:36
To: activeperl [at] listserv.ActiveState.com
Subject: Best architecture for CGI scripts accessing dbm file

> Hi
> =

> I have a CGI script which among other things ties to a dbm file in
order to do look ups on certain CGI =

> parameters. Performance is ok but I wonder whether it is efficient for
each call to the script to open a tie to > what is essentially the same
data and whether it will suffer under load. =

> =

> I tried to find out more about how tie works but it is not clear to me
whether or not it loads the whole dbm =

> into memory. If it does then I would like to assess other ways of
doing this.
> =

> I suspect implementing mod_perl or ISAPI when I have not used them in
much before is too much work and unknowns > for this urgent critical
task (though if this sounds wrong let me know!)
> =

> So my question is whether there is a another way of sharing this data
between many CGI calls which is as fast =

> and light on memory as possible. =

> =

> One idea I had was to set up a SOAP or XML RPC server which has the
tied dbm and responds to calls from the CGI > scripts with the specific
info required for each one. A round the houses way of doing it perhaps
but one that I > can get my head around (and give me a chance to play
with writing a SOAP or XML RPC server). =

> =

> But I thought I would run it past you in case you could point out any
obvious things I had missed or had your =

> own ideas about an elegant solution to this.
> =

> Or should I really look at mod_perl/ISAPI, CGI::Application or
something else?
> =

> Or is it fine to keep doing it the way I am?
> =

> I do intend to try some benchmarking but some pointers as to which
options are worth focusing on would be a =

> huge help.

Avoid premature optimisation. Do your benchmarking against your expected
load to see if you actually have a problem before trying to solve it. If
its not fast enough, then profile to locate where the bottleneck(s).

If, for example, your shared resource (i.e. dbm file) turns out to be a
bottleneck because access to it has to be serialised, then it unlikely
that any of the above ideas will help very much.

Remember, the first rule of optimisation is don't do it yet. :-)

HTH

-- =

Brian Raven =


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Atos Euronext Market Solutions Disclaimer
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The information contained in this e-mail is confidential and solely for the=
intended addressee(s). Unauthorised reproduction, disclosure, modification=
, and/or distribution of this email may be unlawful.
If you have received this email in error, please notify the sender immediat=
ely and delete it from your system. The views expressed in this message do =
not necessarily reflect those of Atos Euronext Market Solutions.

Atos Euronext Market Solutions Limited - Registered in England & Wales with=
registration no. 3962327. Registered office address at 25 Bank Street Lon=
don E14 5NQ United Kingdom. =

Atos Euronext Market Solutions SAS - Registered in France with registration=
no. 425 100 294. Registered office address at 6/8 Boulevard Haussmann 750=
09 Paris France.

L'information contenue dans cet e-mail est confidentielle et uniquement des=
tinee a la (aux) personnes a laquelle (auxquelle(s)) elle est adressee. Tou=
te copie, publication ou diffusion de cet email est interdite. Si cet e-mai=
l vous parvient par erreur, nous vous prions de bien vouloir prevenir l'exp=
editeur immediatement et d'effacer le e-mail et annexes jointes de votre sy=
steme. Le contenu de ce message electronique ne represente pas necessaireme=
nt la position ou le point de vue d'Atos Euronext Market Solutions.
Atos Euronext Market Solutions Limited Soci=E9t=E9 de droit anglais, enregi=
str=E9e au Royaume Uni sous le num=E9ro 3962327, dont le si=E8ge social se =
situe 25 Bank Street E14 5NQ Londres Royaume Uni.

Atos Euronext Market Solutions SAS, soci=E9t=E9 par actions simplifi=E9e, e=
nregistr=E9 au registre dui commerce et des soci=E9t=E9s sous le num=E9ro 4=
25 100 294 RCS Paris et dont le si=E8ge social se situe 6/8 Boulevard Hauss=
mann 75009 Paris France.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

_______________________________________________
ActivePerl mailing list
ActivePerl [at] listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Brian Raven [ Di, 27 November 2007 15:13 ] [ ID #1880285 ]

Re: Best architecture for CGI scripts accessing dbm file

>> Remember, the first rule of optimisation is don't do it yet. :-)

>> HTH

>> --
>> Brian Raven



Thanks Brian - good advice :)

Mark
_______________________________________________
ActivePerl mailing list
ActivePerl [at] listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Mark Knoop [ Di, 27 November 2007 17:22 ] [ ID #1880288 ]
Perl » gmane.comp.lang.perl.active-perl » Best architecture for CGI scripts accessing dbm file

Vorheriges Thema: ActivePerl 5.10 Build 1000 Beta release
Nächstes Thema: RE: Welcome to the "ActivePerl" mailing list