Migliorare le performance di Radius

Community IT
1

Ciao a tutti,

sono a caccia di consigli. :slight_smile:

Ho un’applicazione in cui uso la gemma Radius 1 per produrre
documenti Word e Excel XML.
La gemma è comoda (definire i tag è un gioco da ragazzi) e produrre
documenti anche più facile.

La parte più complicata è farlo con performance ragionevoli.

Tutto va bene se si tratta di produrre documenti relativi a pochi
dati. Ma quando tento di produrre, per fare un esempio, un file Excel
che elenca dati tratti da un migliaio di record i tempi diventano
inaccettabili: nell’ordine dei minuti.

Qualcuno di voi ha mai usato Radius? Che strada tentereste per
migliorare la situazione? Radius fa largo uso di regexp e lavora
pesantemente su stringhe: mi viene da ipotizzare che Ruby 1.9 (ora
sono in produzione su 1.8.7) potrebbe dare vantaggi, ma quanto
tangibili?

Intanto grazie,
Silvano

Links:

–
Considera l’ambiente prima di stampare questa email. Be a total user
rather than a complete waster.

. . . Silvano S. . . .
email: [email protected]
site: http://www.sistrall.it

2

Silvano S. wrote:

Tutto va bene se si tratta di produrre documenti relativi a pochi
dati. Ma quando tento di produrre, per fare un esempio, un file Excel
che elenca dati tratti da un migliaio di record i tempi diventano
inaccettabili: nell’ordine dei minuti.

Qualcuno di voi ha mai usato Radius? Che strada tentereste per
migliorare la situazione? Radius fa largo uso di regexp e lavora
pesantemente su stringhe: mi viene da ipotizzare che Ruby 1.9 (ora
sono in produzione su 1.8.7) potrebbe dare vantaggi, ma quanto
tangibili?

Ciao, i tuoi problemi sono 3:
ottimizzazione concatenamento stringhe :
‘abcd’ + ‘cde’ + ‘fgw’
“abcd” + “cde” + “fgw”
“abcd” << “cde” << “fgw”
“#{”abcd”}#{”cde”}{”fgw”}”
L’ordine indica la velocità di esecuzione il 4 è il più veloce.

numero di query sql: cerca di ottimizzare il numero di query, magari
craz una view così velocizzi

scrittura file: se il file che generi è grosso la scrittura su disco
diventa un grosso collo di bottiglia, quindi se salvi il file valuta se
non sia meglio inviare direttamente la stringa al client

3

Grazie Alessandro,

On Friday, April 2, 2010, Alessandro S. [email protected] wrote:

tangibili?

Ciao, i tuoi problemi sono 3:
ottimizzazione concatenamento stringhe :
‘abcd’ + ‘cde’ + ‘fgw’
“abcd” + “cde” + “fgw”
“abcd” << “cde” << “fgw”
“#{”abcd”}#{”cde”}{”fgw”}”
L’ordine indica la velocità di esecuzione il 4 è il più veloce.

Ecco: credo che questo sia il punto dolente. Proverò a lavorarci.

numero di query sql: cerca di ottimizzare il numero di query, magari
craz una view così velocizzi

Il tempo richiesto dalle operazioni su db è quasi ininfluente: 2
secondi su 2 minuti.

scrittura file: se il file che generi è grosso la scrittura su disco
diventa un grosso collo di bottiglia, quindi se salvi il file valuta se
non sia meglio inviare direttamente la stringa al client

Questo è un altro punto interessante: i file prodotti non sono
immensi, ma arrivano facilmente al mezzo mega.

Grazie mille per i consigli. Ci lavoro.
Silvano

–
Considera l’ambiente prima di stampare questa email. Be a total user
rather than a complete waster.

. . . Silvano S. . . .
email: [email protected]
site: http://www.sistrall.it