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:

  1. Add indexes and adjust schema a little.
  2. Upgrade hardware.
  3. Upgrade to more recent MySQL
  4. 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.

  • Do you mean G as grand? Because I read it over and over to mean 10^9. – ptman Oct 17 '10 at 8:10
  • Colloquial grand, yes. – Jé Queue Oct 17 '10 at 14:05

some thoughts:

  • yes, upgrade hardware, if only to avoid dependency on hard-to-find spare parts.
  • properly indexing DB can easily reduce times by a factor of 100 or 1000 or even more, especially on multi-million-record tables.
  • going from GCI to some other architecture avoids process startup time, nothing more. it's a big difference when doing hundreds or thousands of requests per second, this doesn't seem to be your case.
| improve this answer | |

I don't really think there is an issue, just buy the new hardware.

Even if you do decide to re-write the application later, would you really deploy your new app on old hardware? I doubt it, so either way you need to invest in the hardware.

And with any luck (and some performance testing) the new hardware will (after your do 1&3 in your list) scale fine and you can skip the many $10Gs re-write

| improve this answer | |
  • Good point on that new HW is in the queue regardless. – Jé Queue Oct 17 '10 at 1:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.