I am engaged with a project to upgrade a time-tracking system that's been basically unchanged for 10 years. It runs Linux/Apache/CGI/MySQL3 on an HP Proliant Pentium some-or-the-other, with a combination of some perl & bash "here documents" (with a C library to parse/scrub incoming requests) in a process-per-request manner.
The company has grown from about 10 people in 2001 to over 750 today, plans on growing to several thousand over the next few years. There are some performance problems with the application but after investigation it appears the performance problems deal with tables with many millions of time entries clearly missing indexes and results not paginating (causing big pages to come back).
Utilization at the Apache and request processes just simply don't take that much CPU time nor memory; the cartesian joins on million-record tables however does consume lots, and reportedly even locks up periodically at the end of the month.
I want to address the problems with these approaches:
- Add indexes and adjust schema a little.
- Upgrade hardware.
- Upgrade to more recent MySQL
- Update the the UI to be a little less old-school.
I just don't see any reason to completely re-write a CGI program into an in-process architecture. I think CGI will hold up perfectly fine. Would you realistically have any concern on a seperate-process CGI architecture considering the advances we've had over the last decade in hardware? Thing is, we can spend several $Gs on a new server, or many $10Gs on a re-write.