CGI vs. Servlets
Aniket
we are facing a dilemma of Java vs CGI in web enabling the
application.
Although, Java should be general preference, it is believed that there
are some performance issues associated with java in tandem. So if the
number of concurrent requests are not very high, should one go for CGI
instead? It saves the cost as well, since no additional package like
JToolkit need to be bought.
Another consideration is also the pathway interface thru Java which
requires addtional layer in between.
We are expecting around 50-100 concurrent requests max.
So will CGI be preferrable in such a case?
Thanks in advance!
regards,
aniket
Roberto Veldhoven
> number of concurrent requests are not very high, should one go for CGI
> instead?
request here. For low-volume that would do.
For real high-volume you should IMHO use CGI, but implement it as
server-classes. It works good on our site. Have a look at the
.../webserver/samples/C_Demo that comes with iTP webserver.
I know little about Java, except that all VM-versions around
continually cause problems on my PC.That alone keeps me away from
trying NonStop Java.
> We are expecting around 50-100 concurrent requests max.
> So will CGI be preferrable in such a case?
Starting/stopping so many programs per second would be a problem. But
as you do not specify the elapsed time of a single request it is hard
to give an accurate answer.
Mark Roy
www.nuwave-tech.com/soapam. It translates SOAP requests directly into
Pathway requests.
Mark
"Aniket" <a...@programmer.net> wrote in message
news:e3cf26d5.04062...@posting.google.com...
Aniket
> > (...)So if the
> > number of concurrent requests are not very high, should one go for CGI
> > instead?
> You probably mean the kind of programs that start and stop on every
> request here. For low-volume that would do.
> For real high-volume you should IMHO use CGI, but implement it as
> server-classes. It works good on our site. Have a look at the
> .../webserver/samples/C_Demo that comes with iTP webserver.
I dont have much knowledge of functioning of iTP pathway.
So I have a small doubt here. if i have a Server-Class with maxservers
10 and all processes are processing some request, so what will happen
if 11th request arrives? Will it be queued in usual manner or will it
be discarded?
> I know little about Java, except that all VM-versions around
> continually cause problems on my PC.That alone keeps me away from
> trying NonStop Java.
>
> > We are expecting around 50-100 concurrent requests max.
> > So will CGI be preferrable in such a case?
> Starting/stopping so many programs per second would be a problem. But
> as you do not specify the elapsed time of a single request it is hard
> to give an accurate answer.
Thts true. For tht, some heavily loaded servers may need to have
static processes.
So if CGI is as efficient we may go for that itself.
Thanks a lot for the info!
aniket
Frans Jongma
> > > (...)So if the
> > > number of concurrent requests are not very high, should one go for CGI
> > > instead?
> > You probably mean the kind of programs that start and stop on every
> > request here. For low-volume that would do.
> > For real high-volume you should IMHO use CGI, but implement it as
> > server-classes. It works good on our site. Have a look at the
> > .../webserver/samples/C_Demo that comes with iTP webserver.
> So u mean CGI can as efficiently work with high load as well?
> I dont have much knowledge of functioning of iTP pathway.
> So I have a small doubt here. if i have a Server-Class with maxservers
> 10 and all processes are processing some request, so what will happen
> if 11th request arrives? Will it be queued in usual manner or will it
> be discarded?
>
>
add more instances of the serverclass. As a proofpoint of the
perfromance of Pathway CGIs, I know of a customer that runs over 150
http requests per second ; each request goes to a pathway CGI and the
CGI issues business transactions involving NonStop SQL database.
>
> > I know little about Java, except that all VM-versions around
> > continually cause problems on my PC.That alone keeps me away from
> > trying NonStop Java.
Usually, the NonStop server is a better managed environment than the
average workstation. At least, there are no browsers insisting on
downloading specific JVM versions. The above reason should not stop
you from looking at Java on NonStop.
> >
> > > We are expecting around 50-100 concurrent requests max.
> > > So will CGI be preferrable in such a case?
> > Starting/stopping so many programs per second would be a problem. But
> > as you do not specify the elapsed time of a single request it is hard
> > to give an accurate answer.
> Thts true. For tht, some heavily loaded servers may need to have
> static processes.
>
> So if CGI is as efficient we may go for that itself.
>
> Thanks a lot for the info!
>
> aniket
Let me put a few pro's and cons here.
- CGIs. have the advantage that they are easy to write. Just a few
lines of shell scripts and you're in business. The downside is that
-as was mentioned- you will see many transient processes: shell
being started, shell loading script program etc. Another downside
may be: where does the data come from? You cannot access your (SQL)
data from a script language, so you would needto include a program
in your shell script.
- Pathway CGI. These come from the above idea that you would need a
program to do the database access anyway, so why not write this
program as a pathway server that implements some of the methods to
interface with the webserver. A kind of best of both worlds. This
works quite well. However, you need programmers that create HTML
code in C or COBOL and that is a cumbersome task. The industry has
seen the same problem (mix of data access code, business code and
User-interface code) and this problem has been addressed by the
introduction of Java Server Pages (JSP) in combination with
Servlets.
- Java Servlets (in combination with JSPs). This would bring you some
of the advantages of CGIs, because many programmers can do JSP and
servlet programming. This option does not have the downside of not
being able to call SQL, because of the Java part that supports JDBC
for database access. But even more, you can use the JPATHSEND calls
to interface with existing Pathway servers. The JVMs that act as the
servlet container run as pathway servers themselves, so you get the
benefit of manageability and scalability an availability.
Note that the CGI library is single-threaded if you are not the Java
container, this means that a (pathway) CGI can only handle one request
at a time, wheras the Servlet/JSP container is multithreaded and can
therefore handle multiple requests. And since the SQL/MX JDBC driver
performs the SQL I/O non-blocking, a container is able to handle
multiple requests in parallel, given enough CPU power.
If ease of development is important to you, Java servlets (with JSPs)
is clearly the way to go.
Regards,
frans.
Roberto Veldhoven
> troep_rober...@hotmail.com (Roberto Veldhoven) wrote in message news:<fe183113.04062...@posting.google.com>...
> > > (...)So if the
> > > number of concurrent requests are not very high, should one go for CGI
> > > instead?
> > You probably mean the kind of programs that start and stop on every
> > request here. For low-volume that would do.
> > For real high-volume you should IMHO use CGI, but implement it as
> > server-classes. It works good on our site. Have a look at the
> > .../webserver/samples/C_Demo that comes with iTP webserver.
> So u mean CGI can as efficiently work with high load as well?
With numstatic > 0 they are very efficient.
On the contrary, the GENERIC-CGI (.cgi) will start/stop a new process
on each request, that can be a problem with high volumes.
The client will not notice any difference between these two, except
for the response time.
> I dont have much knowledge of functioning of iTP pathway.
The installation is really simple. Just a few enters and the
demo-environment is up and running, and you can start experimenting.
> So I have a small doubt here. if i have a Server-Class with maxservers
> 10 and all processes are processing some request, so what will happen
> if 11th request arrives? Will it be queued in usual manner or will it
> be discarded?
If you mean usual=pathsend then yes, that's how it will work. The
request will simply be queued to $RECEIVE of one of the
server-processes and be processed when the process reads it. If you
expect REAL high load you will also need copies of HTTPD running in
all cpu's, to evenly distribute the load across all available
LINKMON's. A HTTPD-process will use the LINKMON-process in its own cpu
($ZLnn) to forward the request to your pathway-server.
(...)
Andy Leszczynski
You can ue static CGI written in C or C++. It beats servlets in terms of
performance.
A.
Aniket
aniket
troep_rober...@hotmail.com (Roberto Veldhoven) wrote in message news:<fe183113.04063...@posting.google.com>...