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).=20

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



charset=3Diso-8859-1">

RE: Best architecture for CGI scripts accessing dbm file

From: activeperl-bounces@listserv.ActiveState.com
[mailto:activeperl-bounces@listserv.ActiveState.com] On Behalf Of Mark
Knoop
Sent: 27 November 2007 10:36
To: activeperl@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=
================
Atos Euronext Market Solutions Disclaimer
==================== =====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=
================

_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

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@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs