Alternative ai lavori cron o altri modi per migliorare le prestazioni delle operazioni pianificate

Question

Alternative ai lavori cron o altri modi per migliorare le prestazioni delle operazioni pianificate

#1 da (2 voti)
#2 da (2 voti)

3

Sto lavorando su un sito web di social network in cui gli utenti ottengono valutazioni dopo aver intrapreso azioni specifiche e sono state soddisfatte le condizioni appropriate sulle tabelle. I punteggi sono calcolati in base a "ore lavorate totali" e "punti totali ottenuti". Il php cron ha un sql che INNER JOINs 7 tables. Per mantenere questo aggiornamento, eseguiamo un cron per controllare le voci della tabella una volta al giorno per aggiornare i valori.

Questo è solo un cron di 15 in totale. Alcuni di loro inviano solo e-mail con Mandrill, uno invia una newsletter e ci saranno altre newsletter nel prossimo futuro.

Attualmente, quando c'è un evento attivo sul sito (è una specie di un sito di networking per eventi ma con funzioni amministrative e di gestione in loco), circa 2000+ utenti e i loro dati sono coinvolti in questi processi. Ma ce ne saranno sempre di più presto.

Abbiamo avuto due arresti anomali del server che hanno veramente rovinato il server a causa di due crons prima, uno di questi è quello che aggiorna le valutazioni degli utenti. Il secondo cron che stava avendo problemi stava aggiornando le ore totali in cui un utente lavorava su due tavoli. Avremo bisogno di avere ancora più attività pianificate per altri dati come questi da aggiornare automaticamente.

Dopo alcune ricerche ho trovato The Fat Controller che è -

A parallel execution handler, used to repeatedly run other programs, usually scripts, a bit like CRON. It was designed to handle the execution of scripts which perform background processing for websites which generally need to repeat, react to how much work there is to do at any one time or run as a daemon.

(Come indicato qui - link )

Qualche idea su come le prestazioni dell'esecuzione di 5 script php precedentemente utilizzati come cron dovrebbero essere paragonati a eseguirli come lavori cron? Inoltre, alcuni dei lavori cron che abbiamo attualmente bisogno di eseguire in ore / giorni specificati (cioè inviare posta a un utente - non fine settimana - alle 9.30 ecc.) È possibile con uno strumento come il fat controller? O è possibile impostare l'attività da eseguire una volta all'anno?

Qualsiasi raccomandazione sul modo migliore per gestire questo tipo di processi sarebbe molto apprezzata.

database performance php scheduling cron

posta Ekin 03.09.2015 - 21:28

fonte

2 risposte

Leggi altre domande sui tag database performance php scheduling cron

Come calcolare il numero di dipendenze indirette di una classe? Dove mettere la tabella del paese?

score 2 · Answer 1

Mi è sempre piaciuto cron . Penso che sia facile da capire, e (come la maggior parte delle app * nix) fa solo una cosa: lanciare script quando la data / ora correnti corrisponde a un modello.

Ciò che tali script, tuttavia, è una storia completamente diversa. Se sono ben scritti e testati, possono essere fantastici - componenti fondamentali delle operazioni quotidiane.

Se scritti male, possono (come qualsiasi app) possono impantanare il sistema o peggio.

La maggior parte delle sostituzioni cron che ho visto sono state scritte per essere più facili da usare, non per essere "più stabili" o "più performanti". cron di per sé è molto stabile e poiché non fa alcun sollevamento pesante, le prestazioni in realtà non sono un problema.

Se fossi in te darei un'occhiata agli script che stai chiedendo a cron di eseguire e darei un'occhiata al tuo database. Potresti avere alcune costose chiamate al database, mancare un indice, ecc.

score 2 · Answer 2

Gestisco un server Rails che deve gestire un bel po 'di elaborazione in background. Utilizziamo approcci diversi a seconda del lavoro da svolgere e della quantità di elaborazione che svolgono o di come è necessario pianificarli.

Per iniziare, i tuoi lavori dovrebbero essere in grado di funzionare contemporaneamente. In pratica, è vedere ogni lavoro come utente e assicurarsi di utilizzare le stesse tecniche che useresti per più utenti come transazioni e blocco dei record.

Fondamentalmente ci sono tre approcci:

Semplici job cron. Lo usiamo per lavori che funzionano molto regolarmente (ogni ora, una volta al giorno) e che richiedono un sacco di elaborazione (per qualche strana ragione nell'esecuzione di uno script Rails dalla riga di comando e lo stesso script all'interno di un controller diRails quest'ultimo caso a volte usa molto più memoria, anche un po 'più lento)

Il secondo approccio è ciò che chiamate il "controller grasso". Questo controller è chiamato da un cron job (semplicemente eseguendo un semplice curl o wget da cron.hourly). Questo è per alcune semplici attività in cui eseguiamo le cose in un momento specifico, o forse solo se non vengono eseguiti altri lavori. (Io uso un semplice trucco qui, quando il controller si avvia scriverà un file temporaneo e lo eliminerà al termine, se il file è presente all'avvio non verrà eseguito affatto, evitando alcuni conflitti se alcune importazioni di dati impiegano più tempo del previsto) .

La terza variante è una quequ. Fondamentalmente una tabella in cui scrivo alcune richieste che possono essere eseguite più tardi o di notte (invio di e-mail, conversione di immagini ...). Un altro cron job inizierà quindi a lavorare su questa coda in un dato momento. (Esistono diverse librerie carine per Rails che aiutano a organizzare questo tipo di lavoro.)