AMC devient de plus en plus lent au fur et à mesure du scan de copies.

C'est bizarre car je n'observe pas ce phénomène — mais je n'ai pas dépassé 1500 pages à scanner.

Les développeurs voient-ils une contre-indication ?

A priori non, car cela semble bien supporter les accès concurrentiels (AMC parallélise certains opérations).

Il y aurait la solution d'un dossier spécifique SQLite sur un RAMdisk, mais le risque de corruption de base m'effraie un peu.

En cs de crash, on peut tout refaire à partir des fichiers source (sans avoir fait de mise à jour sur le système cela devrait passer sans problème).
Et ça vaudrait peut-être le coup de faire le test sur un examen que vous avez déjà traité, pour voir si c'est vraiment les accès disque qui limitent le traitement.

la regénération de copies anonymisées

De quelle étape parlez-vous exactement ?

Bonjour,
Désolé, j'ai été imprécis. J'ai scanné 2000 copies de 3 pages ie 6000 pages.
1) J'ai essayé de modifier les paramètres SQLite, ce n'est pas persistent, mais associé à la connexion sqlite.
Il faudrait donc que je modifie la connexion sqlite utilisée par AMC, j'ai un peu cherché, mais je ne vois pas ce type de paramétrage sur l'interface ou dans les différents fichiers.
2) La génération des copies anonymisées pour correction humaine est réalisée plusieurs fois, de manière à débuter la correction humaine avant d'avoir terminé tous les scans.
Je relance donc régulièrement la génération (tous les jours) pour prendre en compte les nouvelles copies scannées.
3) Sur le RAMdisk, je suis d'accord sur le fait de pouvoir rejouer le scan, mais est-ce que le numéro d'anonymat des copies va changer car le risque serait trop important dans ce cas (a cause du fonctionnement évoqué ci-dessus).
A moins que je puisse fixer la graine. (je crois bien avoir vu un post là dessus sur le forum)

Bonne journée,
Aurélien

Il faudrait donc que je modifie la connexion sqlite utilisée par AMC

Ce n'est pas prévu actuellement via la configuration d'AMC. Il faudrait modifier le code d'AMC : dans AMC/Data.pm, ajouter la configuration souhaitée dans la fonction require_module, après le bloc ATTACH

        debug "Connecting to database $module...";
        $self->{dbh}->{AutoCommit}     = 1;
        $self->{dbh}->{sqlite_unicode} = 0;
        $self->sql_do( "ATTACH DATABASE ? AS $module", $filename );
        $self->{dbh}->{sqlite_unicode} = 1;
        $self->{dbh}->{AutoCommit}     = 0;
# ajouter ici les PRAGMA souhaités, un par ligne ...
        $self->{dbh}->do("PRAGMA journal_mode = WAL");

La génération des copies anonymisées pour correction humaine

Oui pardon j'avais oublié que vous utilisiez le panneau "Anonymat" dans l'onglet "Notation". A priori je ne vois pas trop de moyen simple d'accélérer le processus.

A moins que je puisse fixer la graine.

Si dans votre code une graine de générateur aléatoire n'a pas été fixée, alors plus grand chose ne fonctionnera dans AMC.
Le générateur utilisé par AMC pour le mélange des questions/réponses a une graine fixe. C'est le cas également de celui de fp, mais pas celui de pgf par exemple.

Bonjour,
1) Merci bien, je vais tester cela.

2) Pour la graine aléatoire, je parlais de l'identifiant donné à chaque copie anonyme.
Je me demandais si la correspondance numéro de candidat / identifiant de copie anonyme était reproductible (ie si l'identifiant de copie est un hash du code candidat ou s'il est déterminé à partir de l'identifiant de copie. En cas de crash de la base, le contraire serait catastrophique.
Cela éliminerait la solution RAMDISK.

Bonne soirée,
Aurélien

Pour la graine aléatoire, je parlais de l'identifiant donné à chaque copie anonyme.

Celui-ci est en effet aléatoire et non-reproductible.