perl/cgi vs. Datablade, performance issues
We're looking for a way to access perl using a persistent database connection using (shudder) Netscape Enterprise Server 3.0. What looks like might work best at this point is possibly to use fastcgi and Apache with the DBI-DBD perl interface. A couple of questions it would be cool to have answered are: 1. Does anyone know of a fast-cgi-like implementation for Enterprise Server 3.0? Will we be able to parallelize database access like appears to be possible using Apache and DBI-DBD? 2. Currently half of the things we run are built using the Illustra Datablade. If we don't stay with NES 3 and instead go with Apache, how much slower will cgi-bin access using the Datablade be? What would be recommended methods for making this impact less significant? 3. Why doesn't the Informix/Illustra Datablade support Apache? We really want to be able to take advantages the performance benefits of Apache and perl. When we asked our representative at Informix about this he sent us a copy of WebConnect (which was very generous. They've been very helpful). Here's a snippet from the docs: "'OPEN ROBUST ... ENVIRONMENTS'... Web Connect provides an open developing environment... unlike cgi (which) requires developers to write proprietary scripts... through a collection of Informix-specific HTML tag extensions, Web authors can create applications...". Let me translate this into language that makes sense from my perspective: "Web connect glues proprietary (but we don't want to call it that) mouths on to your thighs providing you with the same functionality you had with your arms but much better for all your needed applications such as biting and chewing". Well this is true if all we ever wanted to do was bite and chew. And I'm sure Web connect is a vast step up from our current Illustra Datablade for our products that use it. But what we really want is something that will allow us to use existing languages (like perl, for instance) to allow us to build applications with complex processing needs and let us get decent performance accessing the database. While Datablades are a quick way to get information out of a database they're really not suitable as a kitchen-sink toolkit for complex applications. Please comment, if you would. Austin