[PHP] Directory al posto di mysql per sito piu' veloce??

[kramnic]

Salve a tutti.
Sto realizzando un upgrade di un sito web di contenuto editoriale, e sto pensando di alleggerire il codice per rendere il sito piu' veloce.
Al momento il sito prende tutti gli articoli da un database, il che purtroppo, dato che il server linux non e' molto potente, lo rende abastanza lento.
Ho provato script di caching, ma mi complicano un po il codice e mi riempiono directory di files temporanei.. e la cosa non mi piace molto.
Stavo pensando di creare un sito con una struttura tipo questa:

http://www.sito.it/articoli/2010/04/25/nome-articolo/, dove nella cartella 'nome-articolo' vi siano un file index.php che contiene poche linee di codice che vanno a includere le pati fisse della pagina (menu, header e footer) presenti nella ROOT del sito e leggere un file 'content.xml' contenuto invece nella cartella 'nome-articolo', file nel quale e' contenuto il titolo, e il testo dell'articolo.

La cartella 'nome-articolo' sarebbe generata nella sezione admin, da una applicazione che in piu' inserisce un record nel database mysql, che userei a sto punto come backup e soltanto per il motore di ricerca.

L'esito di questo ridurrebbe le interrogazioni al database alla sola funzione i motore di ricerca, mente gli articoli altro nonsarebbero che pagine fisiche, con solo poche righe di contenuto dinamico...

Che ne pensate?

[sebaldar]

ciao,
mi sembra strano che tu abbia problemi di lentezza nella esecuzione della query, hai controllato che sia ottimizzata, esegui la query su una chiave (primaria o secondaria)?

[LeleFT]

La cosa ancora più strana è che tu abbia postato qui un problema relativo a PHP invece che nel forum dedicato a PHP...

Sposto.

Ciao. :ciauz

[kramnic]

Originariamente inviato da sebaldar
ciao,
mi sembra strano che tu abbia problemi di lentezza nella esecuzione della query, hai controllato che sia ottimizzata, esegui la query su una chiave (primaria o secondaria)?

fidati non è un problema di ottimizzazione, è proprio una questione di server catorcio che è molto lento, il tutto sommato a molte consultazioni...

ti faccio un esempio:
la homepage è una prima pagina tipo giornale, che riassume tutti i titoli e gli abstract degli articoli.
Bene, quella la spezzetto in tanti blocchetti che vengono messi in cache con scadenze diverse. E su questo non ci piove.

La cosa che secondo me invece alleggerirebbe il lavoro del database sarebbe la creazione di pagine fisiche anzichè una sola paginona dinamica del tipo ".../leggi.php?numero_articolo=123".
In questo modo avere tante pagine del tipo "articoli/2010/04/27/articolo-123/" alleggerirebbe il tutto.

La cartella sarebbe così strutturata:

/nome-articolo/
/index.php
/content.xml
/config.xml
/media/

Così descritta:
index.php
Contiene due o tre linee di codice che caricano la struttura della pagina dalla cartella "Core" del sito
, ti"<? include (../../../Core/modelli/paginatipo1.php); ?>", che mi va a leggere il contenuto effettivo dell'articolo in content.xml, legge la configurazione dell'articolo in config.xml e carica le immagini e i media vari (compresi css customizzati per l'articolo in questione) contenuti nella cartella "media".

Ora, le domande che mi sono posto son due:
1) "ma perchè non creare direttamente una pagina "/nome-articolo/nome-articolo.html" statica e morta lì?
Il fatto è che se poi devo fare dei cambiamenti al layout delle pagine, da questi sarebbero escluse tutte le pagine (essendo statiche) precedenti a tale cambiamento. A meno di creare uno script che mi ricancella tutto e riscrive tutto, ma non ha senso..

2) "ma allora mysql che lo usi a fare?".
Quando dal pannello di admin vado a creare un articolo, una parte dello script inserisce l'articolo nel database, l'altra crea la cartella contenente i file di cui sopra.
Il database a questo punto verrebbe solo interrogato quando:
- uso il motore di ricerca (ogni record avrebbe il link all'articolo senza dover scaricare il testo, quindi ulteriori dati)
- se devo andare a modificare un articolo, altro non devo fare che andare sul db, modificare da db e lo script in automatico mi rigenera la cartella di cui sopra
- nella prima pagina del sito, che però mi carica soltanto i titoli degli articoli e pochi abstract, e il tutto messo in cache con scadenza di 24 ore

A me sembra che possa funzionare... e pure molto leggero..

Voi che ne pensate? Scusate il papiro ma volevo essere chiaro..
E cmq si è un po' contorta la cosa

[k.b]

E' difficile dire se ci guadagni o no. Il modo migliore per avere un sostanziale incremento delle prestazioni, e' fare un caching full-page: in questo modo il client richiede la pagina e il webserver gli restituisce l'HTML precedentemente elaborato e cachato. Se devi comunque servire le pagine dinamicamente ad ogni richiesta, non e' affatto detto che usando il filesystem invece del DB otterrai un miglioramento delle prestazioni: alla fine i dati sempre dal disco li prendi, no?

Potresti avere vantaggi se il database e' intasato di richieste mentre il webserver e' piuttosto scarico (ma non mi sembra questo il caso), quindi riequilibrando i carichi guadagneresti un po', ma in generale l'overhead delle due soluzioni mi sembra paragonabile. Quello che dici tu non fa altro che spostare l'incombenza dell'accesso ai dati e della loro estrazione dal database all'interprete PHP... che pero' girano entrambi sullo stesso computer quindi

[kramnic]

Originariamente inviato da k.b
Quello che dici tu non fa altro che spostare l'incombenza dell'accesso ai dati e della loro estrazione dal database all'interprete PHP... che pero' girano entrambi sullo stesso computer quindi

Beh ma parsare un file xml e connettersi a un database non sono lenti uguali no?
Che io sappia parsare l'xml nella stessa cartella e' piu' veloce di tutto il processo del db (creare una connessione al database, cercare il dato,fetchare il risultato ecc..)..

So che una pagina statica e' la soluzione piu veloce, ma mi servono delle parti dinamiche perche':
1- se faccio dei cambiamenti (in termini di aggiunte di roba) alla struttura del sito non devo riscrivere tutti i files
2- tutti gli articoli hanno delle restrizioni di accesso, in base al livello dell'utente
3- devo avere la liberta' di bloccare l'articolo senza eliminarlo

Magari la via di mezzo potrebbe essere un semplice parser di questi parametri, mentre i contenuti veri e propri potrebbero essere contenuti direttamente nella pag index.php...

Oppure provo sul campo con uno script che mi calcoli il tempo che ci si mette con la soluzione db e quella filesystem... :master:

[k.b]

Originariamente inviato da kramnic
Beh ma parsare un file xml e connettersi a un database non sono lenti uguali no?
Che io sappia parsare l'xml nella stessa cartella e' piu' veloce di tutto il processo del db (creare una connessione al database, cercare il dato,fetchare il risultato ecc..)..

Mah sinceramente non credo. Alla fine l'unico overhead aggiunto e' la connessione al db, e quanti millisecondi puo' farti perdere?
Un file xml poi lo devi leggere tutto in memoria prima di parsarlo ed estrarre i dati, dal db invece estrai solo quello che ti serve.

Per come la vedo io un xml e' una soluzione meno efficiente ma piu' pratica per lo scambio di dati tra sistemi diversi, comunque fai qualche benchmark e vedi i risultati sul campo.

[bionicoz]

Per esperienza personale ti posso dire che su un server davvero catorcio (p200mmx con 196mb di ram, nn so se ve lo ricordate) con un'applicazione come gallery2(non so se la conoscete) nel caso di un singolo utente connesso, era più veloce prelevare i dati direttamente da file, piuttosto che da db. (quell'app fa cmq davvero un sacco di richieste al db per creare la pagina, almeno 20, ad occhio). Ora, visto che la situazione si è ribaltata "upgradando" con un pIII 600 con 512mb, la domanda sorge spontanea: quanto è catorcio il tuo serverino?