Se volessi chiudere in base alla data dell’ultima attività (invece che alla data di creazione), esiste una variabile da utilizzare al posto di created_at?
C’è un modo per escludere i messaggi diretti dalla chiusura? Ho eseguito la query nel mio ambiente di test e ho notato che ha interessato ogni argomento, sia pubblico che privato; vorremmo escludere i messaggi privati, se possibile.
Sul nostro forum, abbiamo quasi 16 anni di contenuti che abbiamo importato dalla nostra precedente soluzione. In termini di tempo necessario per eseguire la query, (a) come possiamo determinare quanto tempo ci vorrà per eseguirla e (b) sarebbe meglio suddividerla (ad esempio, eseguirla per tutto ciò che è precedente al 2010, poi per il 2011, 2012, ecc., fino al 2023) o eseguirla come un’unica query?
Sto solo cercando di assicurarmi (con il punto 4) di non influire troppo sulle prestazioni del sistema. So che molto dipende dall’hardware su cui stiamo eseguendo (che in realtà non conosco, perché abbiamo un team di infrastruttura che si occupa dell’installazione e della manutenzione di tutto l’hardware).
Sul n. 2, utilizzando il plugin data explorer (di cui non ero a conoscenza), sembra che updated_at sia probabilmente il valore in cui si troverebbe il “timestamp dell’ultimo reply”. È una valutazione accurata?
Grazie per questo suggerimento: è molto utile per le mie prime tre domande, credo. Apprezzerei qualche chiarimento su updated_at e sulla pianificazione di operare sulla nostra cronologia estesa di post e argomenti.
Proverei sicuramente prima con un piccolo batch. Ho, ehm, fatto cadere un sito della community con azioni di massa e ho desiderato di aver testato prima un sottoinsieme.
Grazie, sospettavo fosse così. È utile avere conferma dell’approccio.
Penso che potrei provare a recuperare uno dei backup recenti e impostare un ambiente sandbox separato dal mio ambiente di test. Non sono sicuro di come funzionerà il pezzo SSO in quella configurazione, ma sarebbe bello vedere che prestazioni ci sono prima di colpire il sistema di produzione.
Lo terrò presente se hai una community particolarmente attiva, il sito di staging non simulerà completamente la produzione poiché c’è un certo impatto dovuto all’uso organico del sito in aggiunta alle azioni di massa.
Certamente - apprezzo anche il suggerimento al post del server di staging, sarà molto utile.
Sì, il carico utente probabilmente non sarà un grosso problema: sembra che le nostre visualizzazioni di pagina al giorno siano circa 50.000 in media tra tutti (crawler, utenti anonimi e registrati). Comprendere il potenziale aumento del carico rispetto al carico esistente sarà utile a fini di pianificazione.
Ho finito per configurare un server di staging (in realtà è stato abbastanza facile: ho semplicemente ripristinato un backup dalla produzione e ho effettuato l’accesso utilizzando la procedura di recupero dell’amministratore, poiché è configurato solo per OIDC). Sembra che abbiamo circa 160.000 argomenti e un rapido test su una sola categoria con circa 7500 ha richiesto 6 minuti sul mio sistema di test, quindi circa 2 ore per tutti gli argomenti. L’impatto sulle prestazioni del sistema (monitorato con htop) è sembrato piuttosto trascurabile qui.
Sono sicuro che possiamo trovare un periodo di utilizzo basso in cui eseguire il comando rake e possiamo preparare gruppi di categorie se lo desideriamo, quindi funzionerà molto bene per noi.
Apprezzo tutti i suggerimenti e l’aiuto: ho imparato molto sulla piattaforma negli ultimi due giorni come risultato.
