|Hypothetical question about application|
If I told you that a major e-commerce website used cobol as part of its web application, what would be your first impression? It's being used to interface between the database and the web server via CGI scripts.
Now, if I told you it was running very slow - would you be surprised? Why?
Any thoughts would be greatly appreciated.
|Now, if I told you it was running very slow - would you be surprised? Why? |
Cobol is old mainframers language - these people just won't move on! Anyway I would not automatically equate Cobol/mainframe with slow because its not since banks and others run these systems and its all pretty fast for the job they do. It is possible however that what the cobol bit does was not to be meant done in "real-time" (ie normal acceptable response time of a webpage).
Performance tuning is rarely an easy task, but I'd look at communications between web and cobol bits, and then at actual performance of cobol bit on (presumably) mainframe.
As far as I know, Cobol was never meant to be run in realtime. It is a reporting language, used to take sales data and the like and present it to managers before the days of spreadsheets and powerpoint... the closest modern day equivalent to Cobol I can think of is XSL (which parses and presents XML data). People used to submit their cobol applications to run as a batch program. I don't remember much about programing in Cobol, but I remember doing things like writing and reading from scratch tape because the IBM mainframe didn't have enough memory to process the job (in fact, tape was used as the primary source and target of data). The mainframe was single process, so that if your batch job took longer than X number of seconds, it would abort out (or you would have to request the process to have a longer timeout limit).
While I suppose it would be possible to run your ecommerce system with a Cobol backend, there are a lot of things that are possible that wouldn't be a good idea. I mean, you could write your ecommerce system in DOS batch files if you wanted to. But there are probably better ways of doing things.
I'd think they would be smart people for using cobol in the back end. That code is likely older than I am, and very highly tuned and bug-free.
I would not be surprised, but the problem is probably not the cobol in the backend. You have lots of variables here:
* Is the server big enough?
* Are the CGIs optimized?
* Is the web server optimized?
* Are the server admins not boneheads?
* Is the database big enough to handle the request load?
Switching away from cobol may make things worse! You will have to rewrite everything and will definetly introduce new bugs. Then you'll have to tune everything.
One of my employer's sites is slow because the told everybody to set their browsers to revalidate every page, so the server does a lot of work validating upwards of 20 requests per page. 50% of its requests respond 304 Not Modified, rather than a more sensible 10-15%.
You can't blame cobol until you've determined it can be the only cause of the problem. You may think that C is fast, but the right kind of idiot can write C thats gets beaten out by a scripting language.
|While I suppose it would be possible to run your ecommerce system with a Cobol backend, there are a lot of things that are possible that wouldn't be a good idea. |
I will speculate but its likely to be bank with ancient but still running Cobol/mainframe backend with website to do things that the system was never designed for - allowing multiple customers view balance, make transactions etc. The system may have only been designed for a handful of tills in branches and mainly batch processing (like generating lots of statements in one go).
There is no such thing as "slow"* language - there is poor coding however.
* not even Java ;o)
>>what would be your first impression?
I would venture to guess that the company utilized it's current business environment by extending it to the web. Quite common.
>>It's being used to interface between the database and the web server via CGI scripts.
Also quite common. They probably decided to use their internal employees and talent to code the interfaces with their data using the native language that was already being employed on their platform. Learn how to parse GET and POST query strings using the language, in this case COBOL, and they were off to the races...
>>Now, if I told you it was running very slow - would you be surprised? Why?
I agree with drbrain on this one. There are so many variables involved here that it's too early to point to the COBOL applications. Did the slow-down occur recently, or has it always been this way? Where is the slow-down, exactly? After the request hits the server, during CGI processes?
Sounds like a fun project, no doubt.
LMAO. Well, you can't quite blame cobol right away, or the CGI... but that would be the first thing I would benchmark. (Also have a DBA look at the DB performance).
This is stuff that's being replaced by Java/J2EE- instead of having a different process running for each CGI request, you multi-thread your application... as well as run a connection pool to your database.
Of course, if your CGI interface to the database is not the choke point, it would be stupid to introduce bugs in a system that's been working for a while. It's worth benchmarking though, and if it's getting really slow you and traffic is growing, you may need to migrate before your old system can't handle the load.