Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Language choice for high-volume Oracle CGI interface?

Re: Language choice for high-volume Oracle CGI interface?

From: Wade Warrens <warrens_at_netcom.com>
Date: Sun, 20 Jun 1999 14:37:02 -0700
Message-ID: <376D5EFE.9C0B00C2@netcom.com>


Let's see, 1,000,000 tx per day, figure an 8 hour day, comes to 35 transactions per second. Are they omplex transactions? I'd do a quickie prototype (In pl/sql or C (oci?)) that does: open connection
for i = 1, 3500 {

   begin transaction
     insert, update, delete, whatever
   commit
}
close connection

Also, try that in perl and Java/JDBC.
See if all solutions take less than 100 seconds. If so, then try:
for i = 1,3500 {

   open connection
   begin transaction

      insert...
   commit
   close connection
}
I'll bet that opening a connection each time will destroy your tps goal, in which case you will need to re-use your connections, perhaps with a connection pool. I know that's pretty easy with Java servlets, but perhaps impossible with plain 'ol fork-a-process-each-time CGI. I've never used mod_perl, so can't comment on that solution. Personally, I would spec the database (and the transactions) before doing anything else. Then I'd consider client-> HTTP ->servlet-> RMI ->appserver-> JDBC ->database --wade

Greg McCann wrote:
>
> We're doing a proposal for a system doing high-volume financial transactions on
> the internet. We're expecting 10,000 transactions per day at the beginning, up
> to 1,000,000 transactions per day eventually. The client has specified an
> Oracle database with an NT web server, using SSL for secure communications both
> between the browser client and our server and between remote servers and our
> main server.
>
> We're debating what language to use for the CGI programming. C++, Java, Perl,
> ...? I have some experience using Perl for database access, but not with Oracle
> or on a system as large as this. Do you have any thoughts on the relative
> merits of these languages for this application? If possible, we would like to
> follow a path which wouldn't lock us in to a Microsoft platform.
>
> Thanks,
>
> Greg
Received on Sun Jun 20 1999 - 16:37:02 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US