log in runtime

per quanto riguarda l'animazione puoi usare una semplicissima gif animata, che scompare quando mostri l'output dello script lento

se invece vuoi mostrare dei testi prima di aver completato l'esecuzione dello script puoi usare dei classici echo intervallati dalla funzione flush():

http://php.net/manual/en/function.flush.php

il riultato non è garantito

per l'ultimo punto, quello che vuoi realizzare sono delle elaborazioni batch: l'utente richiede l'elaborazione attraverso una funzionalità del sito, la richiesta viene registrata sul db che un cron job provvede a leggere e ad eseguire. Al termine dell'esecuzione viene registrato l'esito sulla stessa tabella. L'utente accede ad una apposita pagina dove trova lo stato di elaborazione ed eventualmente visualizza i risultati.

 :bye:

mmm

Avevo sempre pensato alla gif animata, ma credevo non fosse professionale o comunque valida - da lì pensavo all'AJAX "mantieni la gif animata finché lo script elabora"; ma non conosco bene AJAX, indi starò sparando cavolate.

Per la flush potrei provare, sempre che Drupy non mi mandi a quel paese, visto che il link punta ad una funzione la quale viene poi rende l'output da filtrare e inserire nel tema.

L'ultima sembra quella migliore, tra l'altro Drupy implementa i cron job, ha anche dei batch suoi - un campanello d'avviso? -...

Per un momento m'era anche passato di mente di eventuali Trigger e Action, qualasiasi evento (la fine dell'elaborazione) come Trigger a cui si associa un'action (il redirect verso l'esito e la sparizione della semplicissima gif)? mmm non mi sembra granché però.

Se i batch sono realmente onerosi ti conviene pensare a delle richieste di elaborazioni batch da eseguire in differita e poi ad un sistema per prelevare a posteriori i risultati.

In questo modo gli utenti non stanno impalati ad aspettare il risultato. Potresti anche pensare ad un sistema di notifica (via mail?) del completamento delle operazioni, in modo che l'utente sappia quando andare a prelevare i risultati.

 :bye:

Considera che un utente o massimo due potrebbero eseguire quest'operazione una volta ogni tre mesi circa o anche ogni sei mesi.

Detta così verrebbe una cosa del genere: "ok, elaboro, ti mando per email l'avviso che ho finito" e magari anche un link che mostri una sorta di log o i risultati dell'elaborazione. Così l'utente non attende che lo script finisca o peggio chiuda per errore la tab o creda si sia bloccata l'elaborazione...

I risultati ottenuti saranno poi distribuiti nel DB e da là altre parti del software li manipoleranno...

Così mi piacerebbe, se ho capito bene, sai?

Esattamente, in azienda procediamo in questo modo, soprattutto quando è meglio lanciare queste elaborazioni in un momento in cui non ci sono altri utenti collegati al sistema (di notte), per evitare che il carico possa rallentare le normali funzionalità del sistema.

In questo modo evitiamo che gli statement SQL delle elaborazioni pesanti generino dei lock che vanno a bloccare gli statement SQL delle operazioni "leggere" degli altri utenti.

Anche per le stampe di reportistica pesante procediamo in questo modo. L'utente preleva il PDF con il report prodotto in differita.

 :bye:

Già vero, il lock degli statement... su MyISAM blocca l'intera tabella, o erro? Mi pare InnoDB invece blocchi il singolo record; nel mio caso si tratta di insert o update principalmente di due tabelle su 7 del modello + altre 50 e oltre del CMS <.< escluso eventuali msg di log.

Durante un'operazione del genere, si potrebbe registrare un progressivo calo delle performance...

Dunque operazione pianificata in background + log...

Il PDF in sto caso lo genera prelevando dati dal DB?

Si, la reportistica PDF si basa su dei dati di dettaglio o di riepilogo prelevati dal DB. Abbiamo anche delle tabelle che servono solo a memorizzare i risultati delle elaborazioni, in modo da poter produrre più volte i PDF a fronte degli stessi dati calcolati dall'elaborazione. Si stratta quindi di tabelle di appoggio.

 :bye:

ok, vedo di risolvere secondo questa direzione, vi terrò aggiornati  :bye:

...Dubbio: ma come posso attivare dei batch da una pagina web, chiuderla (se voglio) e aspettarmi che questi continuino ad elaborare??  :crazy:

I batch non vengono avviati dalla pagina web ma solo "prenotati". L'utente effettua una richiesta di elaborazione batch specificando anche i parametri necessari alla sua esecuzione.

Queste informazioni vengono salvate nel database e un cron job di tanto in tanto, o quando tu preferisci, va a leggere queste prenotazioni e le esegue una alla volta. E' quindi lo script PHP lanciato dal cron job ad eseguire le elaborazioni in differita.

 :bye:

bon, qui mi son fermato... potresti farmi un esempio codoso stupido o mi linki qualche materiale?  :smitten:

Ho capito come si potrebbe fare, ma in dettaglio con php no.  :buck:

È come se io lanciassi al server via SSH un comando barch (o anche no) che richiama uno script php per eseguire le operazioni, magari dando & alla fine, così posso chiudere la SSH.

Per curiosità, una cosa così non è implementabile dalla funzione system?system($comando. " &");

Grazie  :-[

Il codice non te lo posso mostrare perché è roba di lavoro. Ti assicuro però che è molto semplice.

Per prima cosa devi realizzare uno script PHP che registra su DB la richiesta di elaborazione batch fatta da un utente. Lo script dovrà inserire un record in una tabella contenente eventualmente anche i parametri necessari ad eseguire l'elaborazione. Insomma, il solito form che memorizza informazioni su DB.

Fatto ciò devi realizzare un altro script che legge questa tabella, estrae solo i record che risultano "da elaborare" (è sufficiente un flag nella tabella per distinguere le richieste evase da quelle da evadere).

Per ciascun record estratto lo script deve capire quale elaborazione lanciare (quale script PHP includere) e poi, al termine dell'esecuzione di questo script, settare il flag "elaborato" per quel record.

Puoi affidare a cron l'esecuzione di questo script che legge le richieste di elaborazione.

In PHP registri le richieste, in PHP leggi le richieste da evadere, in PHP esegui l'elaborazione "prenotata". Serve solo cron per programmare la lettura periodica delle richieste.

Il database serve a scambiare le informazioni tra lo script che registra la richiesta e lo script che la deve eseguire.

 :bye:

ah no, nessun segreto industriale da divulgare :D

Allora è più o meno come avevo immaginato, cron sostituisce la manina umana che lancia poi l'esecuzione. Mi viene in mente una cosa che non ho mai approfondito.

Drupal ha un sistema di trigger e action: quando si verifica un evento triggerato, esegue una certa azione; ma non so se a prescindere dall'utente loggato o se lo fa lui in background.

In questo caso il trigger è strettamente legato con cron...

mmm mi metto a sviluppare  :coolsmiley: