Rotaie - L'utilizzo delle viste parziali rallenta il rendering?

16

Sto riscontrando problemi di prestazioni su 3.1.0un'applicazione Rails , ora ho apportato modifiche alla cupola sulle mie query con AR e quindi, ma il rendering delle viste richiede ancora troppo tempo, ho diviso le viste, i cicli e così via, su molti parziali che sono resi dinamicamente all'interno di viste e all'interno di altri parziali.

Quindi è una cattiva pratica avere un gran numero di parziali?

Dovrei ridurre il numero di parziali per migliorare il tempo di rendering delle viste?

Grazie

ruby-on-rails view rendering

— Mr_Nizzle
fonte

5

Non conosco differenze significative nelle prestazioni di rendering tra molti parziali e una singola vista quando si esegue il rendering dello stesso contenuto.

Ovviamente, se rendi solo alcuni parziali in alcuni casi e altri in altri casi, riducendo così efficacemente il volume di rendering di una vista specifica, potresti ottenere una certa velocità.

D'altra parte, ho sempre considerato le astrazioni parziali che dovrebbero essere usate almeno da 2 posti diversi per giustificare la loro esistenza. L'altro motivo per utilizzare i parziali è quando si desidera eseguire il rendering della stessa vista ma caricare parziali diversi in base alla logica aziendale in uso.

AGGIORNARE:

Non posso offrire una misura o alcuni numeri concreti sulla velocità di rendering. Se si utilizza un parziale in una vista, per renderlo si chiama il metodo di rendering, quindi esiste una seconda chiamata al metodo. Questo, come ho detto nella mia risposta, non è quasi nulla ma può aiutare a velocizzare le cose un po '.

Tuttavia non ho mai sentito parlare di un progetto che risolva il suo problema di prestazioni rimuovendo i parziali. I parziali sono un buon modo per offrire un meccanismo di riutilizzo alle viste e dal punto di vista dei programmatori dovrebbero essere usati per tale ambito. Dovrebbero essere astrazioni per concetti comuni nelle viste.

Ho lavorato a un progetto in cui i parziali sono stati utilizzati eccessivamente. Non Rails, ma stessi principi MVC. L'uso di piccoli parziali per tutto ciò che puoi immaginare li rende difficili da trovare quando inizi ad averne dozzine. Dove cercheresti un input da modificare? Nella vista? In un parziale? In quale parziale, ci sono 4 parziali per questa vista? ...

Dopo alcuni rigidi refactoring, con ogni aggiornamento di una vista, abbiamo rimosso i parziali non necessari. Non sono scomparsi completamente, ma ciò che è rimasto sono le astrazioni che sono ben definite per il progetto. Rappresentano elementi ben compresi (come un albero per un tipo di oggetti o un tipo di elenco specifico) che si ripetono in una forma o in altre viste. So se vedo un albero che esiste un parziale per quello. So quando vedo un certo tipo di elenco che esiste un parziale per quello. Non li ho cacciati.

La leggibilità del codice è la cosa più importante che si può fare per una base di codice software.

— Patkos Csaba
fonte

Quindi sostanzialmente, se non ho davvero bisogno di un parziale, se quel codice non verrà riutilizzato da altri controller o ricaricato dinamicamente non dovrei usare i parziali? e questo migliorerebbe i tempi di rendering delle viste?

— Mr_Nizzle,

@Mr_Nizzle: ho aggiornato la mia risposta per coprire i problemi sollevati dal tuo commento. Spero che questa spiegazione esaurita sia più comprensibile ... Ho appena capito che il mio secondo paragrafo nella risposta può essere frainteso.

— Patkos Csaba,

Grazie amico Code readability, ecco di cosa si tratta.

— Mr_Nizzle,

22

Non sono d'accordo con entrambe le risposte. Ho copiato e incollato il codice da un parziale nella posizione in cui è presente nella vista padre parziale e con 500 iterazioni, ci vuole un enorme 600 ms di tempo per renderizzare la vista. <% = render xyz%> è secondo me molto rotto.

Esempio, tempo totale per il rendering della vista:

Before:
5759.8ms
5804.2ms
5973.6ms

After:
5268.7ms
5201.6ms
5222.4ms

Diff = 5846 - 5231 = 615 ms

Modificato

Ho finito per RIMUOVERE tutti i _parziali all'interno del _model parziale e lo ho portato a ~ 2000ms, a quel punto ho provato a spostare il _model parziale nell'indice, ma questo NON ha avuto alcun effetto sui tempi di rendering, quindi immagino sia con le chiamate al rendering annidato che lo fa.

— AJP
fonte

Interessante scoperta sul parziale nidificato. Intendi dire UNDRYing di un parziale ridotto di 600ms e unDRYing di tutti i parziali ridotto di 3800ms? Potresti rilasciare l'app demo per questo?

— Lulalala,

@lulalala sì esattamente, e scusa non posso come è stato per il mio lavoro e ora l'ho spostato da Rails a Django, quindi non sono più in contatto con quel codice. Guardando Wyatt Barnett ha risposto , ora non sono sicuro che in realtà i parziali stessero facendo accessi al DB inefficienti che il mio codice unDRYed stava in qualche modo evitando.

— AJP

1

Ho trovato la stessa cosa. La rimozione del codice dai parziali e il ripristino della vista mi hanno dato anche un aumento delle prestazioni di ~ 450ms.

— bcackerman,

1

Nella mia esperienza con Rails con viste HAML, molti piccoli parziali rallentano significativamente il rendering. Sembra che ci sia un overhead fisso per ogni parzializzazione, così come l'avvio della raccolta dei rifiuti durante il rendering di molti parziali in una vista. L'incorporamento di un parziale utilizzato in una tabella di 50 elementi ha ridotto il rendering della pagina di 500 ms.

— d4n3

2

Rails 4: ho appena rimosso alcune migliaia di parziali nidificati su una grande app e ho ottenuto un'enorme velocità. Non hai i numeri, ma sì, se hai problemi di prestazioni varrebbe la pena rimuovere alcuni parziali nidificati per vedere se aiuta.

— Rick Smith

5

Non è un ragazzo rotaie, ma le viste parziali non sono probabilmente il problema in sé. Piuttosto, sembra che tu stia facendo un po 'di SELECT N + 1. Guarda le cose dal punto di vista del server DB per assicurarti di non batterlo in un impeto.

— Wyatt Barnett
fonte

2

Lavorare su un'app Rails 4.2 in questo momento in cui un'azione lenta ha richiesto in media circa 745 ms.

Quando rimuovo il codice dai parziali e lo inserisco nel modello principale, il tempo impiegato è in media inferiore a 25 ms.

Il numero di chiamate per rendere i parziali era solo 29.

— Sammy Larbi
fonte

2

Anche se non hai nessun problema n + 1 e tutto il database funziona in anticipo (diciamo con un CTE ricorsivo), i parziali nidificati sono ancora molto lenti. Haml ed Erb mi sembrano entrambi lenti. Su Rails 5.1.4 vedo alcuni millisecondi per ogni parziale, oltre a parziali occasionali che sono molto peggio (probabilmente corrispondente alla raccolta dei rifiuti).

Ho notato che se rinomino il parziale mentre una di queste richieste è in esecuzione, ricevo immediatamente un errore su come il file non viene trovato. Quindi apparentemente Rails sta leggendo il disco parziale, lo sta riparando e lo sta valutando per ogni iterazione. Nessuna meraviglia è lento!

— Paul A Jungwirth
fonte

0

Gran parte della lentezza osservata nei parziali nidificati si verifica solo durante lo sviluppo. Passa alla produzione per testare.

— Zapaf
fonte

Forse potresti commentare perché la versione di sviluppo è notevolmente più lenta ed essere più sfumato su quando utilizzare quale modalità per quale test.

— Kain0_0

francamente non conosco tutti i dettagli, so solo che stavo avendo gli stessi problemi e ho scoperto che era molto migliorato quando sono passato alla produzione. Posso immaginare che, come notato da Paul Jungwirth, la rilettura del parziale e del reparsing avvenga durante lo sviluppo quando i file potrebbero essere cambiati.

— Zapaf,