There is some FUD going around here. Peers don’t randomly reconnect every 20 seconds or every minute. A tracker can suggest a “minimum reannounce interval” to the client in its response; decent clients will honor this field and not send another request to the tracker for the time-period specified. Usual values in this field are 15-45 minutes, and clients are free to reannounce in larger intervals (but may risk being dropped from the tracking table, depending on the tracker congfiguration).
A tracker does not necessarily need a persistent process. A BitTorrent tracker is nothing else than a WebService served through HTTP; there are plenty of PHP, Perl, etc.-based trackers out there. Some of them are HIGHLY optimized for performance. If you run your own PHP with FastCGI (as described in countless threads on this forum and on the wiki), the performance hit of an individual announce is negligible – The total transaction (on a tracker with a reasonable number of peers) is no more than 1-2 kilobytes of data. php memcached-based tracker will probably outperform PHP+mySQL ones.
(whether DH would choose to classify custom PHP as a BitTorrent-related process, god only knows; it would be quite the double-standard, though).
The “original” Python-based BitTorrent tracker used to be slow and clunky. Since then, a lot of effort has been made to optimize it. A current version thereof will take advantage of either JIT PSYCO code compilation or linked in C-libraries for the “heavy” lifting. To give you an idea of how well that works : The official distribution tracker for the Chinese version of the World of Warcraft - The Burning Crusade expansion (a 4gb file) easily handled over 750k concurrent peers. Sure, using anakata’s hypercube + its tracker module would probably have used less system resources, but it’s wrong to characterize that code as slow or incapable or riddled with issues.
The original poster mentioned a tracker for him and his friends. I assume he does not have more than a couple dozen of these close friends. With those amounts, you do not get into the requests per second stage; Requests per minute or Requests per hour are probably a much more readable stat for that amount of peers. (just as a random data-point : tracker servicing 90k peers on ~4k torrents receives about 250-350 requests per second. This number would be somewhat lower with a smaller number of torrents).
I have seen PHP-based trackers servicing 20k concurrent peers without breaking a sweat. Admittedly, it was highly optimized code without any mySQL doodads – but it worked.
Ultimately though, ask support@ what they think. They can probably tell you what they will deem appropriate use.