I just played around with the antville database and noticed that it looks like there are no indices at all on the ACCESS table! (Except for the primary key, that is.) For example, simply querying for Access data for one weblog takes 10 seconds:

mysql> select count(*) from ACCESS where WEBLOG_ID=1;
+----------+
| count(*) |
+----------+
|     1614 |
+----------+
1 row in set (10.25 sec)

whereas a similar query takes 0.1 seconds on the TEXT table, which has an index on WEBLOG_ID:

mysql> select count(*) from TEXT where WEBLOG_ID=1;
+----------+
| count(*) |
+----------+
|       69 |
+----------+
1 row in set (0.01 sec)

This suspicion is also consistent with the antville_indexes.sql file which doesn't have any entries for the ACCESS table.

I propose we add indices to the relevant columns of the ACCESS table. If that doesn't help enough, we can still delete older records, but I think if we are able to keep all the access history in DB, that would be even better.

PS: for another cool Ausbaustufe of Referrer-Logs have a look at www.disenchanted.com (via LNGR). This is a per-page referrer tracker that really implements bidirectional links. Interestingly, it seems to also have to solved a performance problem because the referrers page is broken down into smaller portions. I think it wouldn't be too hard to implement this for antville if we added the target URL, or maybe better the target story id, to the ACCESS table and a listReferrers macro to the story prototype... just thinking out loud...

PPS: I just noticed that the table definition for ACCESS has a lot of mediumtext columns:

#----------------------------
# Table structure for ACCESS
#----------------------------

create table ACCESS (
   ID bigint(20) not null auto_increment,
   WEBLOG_ID bigint(20),
   REFERRER mediumtext,
   IP mediumtext,
   URL mediumtext,
   PATH mediumtext,
   `ACTION` mediumtext,
   BROWSER mediumtext,
   `DATE` datetime,
   unique ID (ID)
);

Is this really a good thing performance- and space-wise? wouldn't it be better to have varchar(256) and varchar(512) in most places?

I committed a patch that makes weblog homepages "ignore" future stories, i.e. stories for future days are ignored in the main story list but can still be reached via calendar.

helma.org

I also checked in a change for the calendar where nbsp-padding is only done for single digit dates (i.e. date of month < 10).

I didn't check the file out to antville.org. Please have a look.

XML Parsing Error: junk after document element Location: www.antville.org Line Number 1, Column 41:Error in application 'antville':

Runtime error Conversion to object unsupported by null
----------------------------------------^

If I save a story under no certain topic, the "link me"-perma-link will be generated as .../[creationdate]/#####. Whereas if I save a story under a topic, the perma-link will automatically created as .../topics/[topicname]/#####, but the story remains also parallely available under .../[creationdate]/#####.

Question: Is it posible to influence the way a perma-link is created? I think of a setting that always chooses the [creationdate]-version as perma-link, even if a story is related to a topic.

Background: subsequent changes of topic names or story classifications ("topification"?) turn perma-links into dead links.

I just noticed that the /referrers pages on Antville weblogs take forever to compute, something far beyond 5 seconds. Is there some way we can accelerate this?

The easiest solution (and maybe the best one) would be to kick older records out of the ACCESS table, unless there is a reason to keep them all. Maybe it would also be possible to optimize the ACCESS table some more. Something that is definitely not very good for performance is the

... and REFERRER not like "%" + this.href() + "%" ...

in the SQL query in function weblog.listReferrers_macro()...

is it possible that a site [sitename].antville.org works with the url www.[sitename].antville.org as well? many less experienced internet users believe that a proper cough "internet address" has to start with www.(at least this is what my referrer logs imply.)

after installation on mac os x was a breeze the same installation fails terribly on suse linux ("Premature packet header end"). as far a i understand the binary for the mod_webapp.co does not work here and it the sources has to be compiled. apparently, i need all the apache sources to do so and i'm too busy for this.

here's the question: does anyone have a compiled mod_webapp.co that works with suse linux on the pc? cheers.