by josh » Fri Dec 19, 2003 5:11 pm
The biggest threshold issue here was that all user info is stored in a database. We did an implementation that used a CLOB-type field for the eaten message log (a TEXT field of arbitrary size), and found that just doing that tanked the database server -- the extra overhead of handling the LOB column was just too much.
To make it work, we switched over to a fixed length text column that was a lot lighter weight for the db server, but also restricted us to three "records" using our definition.
Perhaps we could come up with a design at some point that stores the logs in files or we could place the LOB column in another table that's only accessed when needed. We do have about 1250 users who currently have the eaten message log "turned on", and these are likely to be fairly active users, so we're still looking at a hit no matter how we handle it.
We do have a lot on our plate in the near term - we're adding a "send the first message" feature (which consists mainly of anti-abuse code), and then we need to do another release that will hopefully contain some pre-packaged user interface code (in PHP or whatever), and there are at least a couple of queued features after that, so we'll be tied up for awhile....