Jé Queue's questions

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.

I am examining a high-volume Apache prefork site and noticing that many log entries such as:

CustomLog '|/foo/bar/cronolog -foo -bar'
RewriteLog '|/foo/bar/cronolog -bar -foo'

When apache logs the request or the rewrite is cronolog spawned for EACH request or is the pipe opened and written-to for the lifetime duration of the preforked apache process?

(This was asked on stackoverflow but I'll remove from there as more applicable here I think.)

I'm in need of running ethernet between nodes in an older brick, steel & mortar building where 802.11* at any power just simply stinks, and no we can't run CAT5 through the walls. Primarily this is to connect several media centers to an internet line.

What is wired in ubiquity though is 75 ohm coax F connector'd.

DLink apparently makes a product: http://www.dlink.com/products/?pid=668

Any other (less pricey) suggestions for running data via 75ohm?

This question topically touched on this, but running on 64-bit Linux, I have a set of data caching JVMs as well as wanting a large web cache. Each cache today is configured to in gross fit in system memory (24GB) and persist to disk in LRU.

I'm curious however the performance if we **over-**allocated the cache processes and set up a SSD for a high-priority Linux swap. I'm wondering if the Linux kernel may be a little smarter/faster than our simplistic LRU process?

I'm concerned with over-allocating JVM heap and having heap pages swap by the kernel as to GC it would have to traverse said pages regularly.

What real performance gains/losses are there on 2.5" vs. 3.5" 15k SAS drives. Are folks really seeing seek differences, &c?

I have several JVMs that all listen to TCP 80 each bound on their own 127.0.100.1 -> 127.0.100.255 range.

Is there a theoretical limit to the effective bandwidth that can be pushed through the LO device? Is this simply a limitation of the kernel and TCP stack vs. the limitations of a 'regular' network interface?