Visualizzazione dei risultati da 1 a 6 su 6

Discussione: Progetti giganti

  1. #1

    Progetti giganti

    Salve a tutti,
    sto cercando qualcuno che abbia un minimo d'esperienza in fatto di siti di grandi dimensioni e totalemente dinamici: siccome il mio sta crollando ho bisogno di qualcuno a cui poter rivolgere domande serie.

    - Un sito visitato da 500 visitatori istantanei come lo strutturi? il db non credo debba stare sull'hd ... e come fare allora?

    - Ok, cluster si ma poi con le sessioni come si fa?? ...e tanto peggio: il db dove lo fai stare (non credo sull'hd)???

    - E la sicurezza del webserver? :O HELP...

  2. #2
    un po' di tempo fa ho lavorato con una serie di siti web sul calcio di livello mondiale, inclusi i siti ufficiali di squadre come Milan, Torino, Bari, Lazioe e svariati altri. facevano un traffico assurdo. la tecnica che abbiamo usato per risolvere i problemi di lentezza è stata quella di creare in automatico le pagine HTML statiche a partire dai dati contenuti nel DB ed inseriti dinamicamente.

    cioè gli amministratori del sito inserivano i contenuti tramite un sistema di back-office; ad inserimento effettuato venivano messi in automatico dei riferimenti alla pagina all'interno di una tabella di "coda creazione". separato dal sistema di amministrazione, c'era un software (scritto in Java nel nostro caso, ma puoi usare anche altre tecnologie) che ad intervalli di tempo regolari leggeva la coda di creazione e costruiva le pagine HTML statiche, salvandole su un file server, e anche rispettando una serie di priorità che dipendono dalle tipologie di pagine (es.: la home page avrà una priorità più alta rispetto ad una pagina più interna).

    ovviamente devi trovare una struttura di directory adeguata. noi avevamo risolto suddividendo le pagine in una serie di tipologie con struttura ben definita dei contenuti (es.: news, schede di dettaglio, archivio news ecc., tutte con un layout e dei contenuti analoghi da tipologia a tipologia). ad ognuna di queste strutture corrispondeva una cartella (puoi costruire una tabella di directory contenente un riferimento alla struttura della pagina, al path nel quale dovranno essere messi i files HTML generati, e alle varie tabelle contenenti i dati dei contenuti delle pagine).

    ovviamente anche i links venivano costruiti in modo automatico per rispettare questa strutturazione di cartelle e pagine statiche.

    se devi fare uno controllo di log-in utente puoi scrivere un PHP che non faccia altro che controllare l'utente logato, leggere il contenuto della pagina HTML statica da visualizzare, e sputarlo fuori al browser dell'utente. ogni link che punta ad una pagina protetta da log-in devi farlo puntare allo script PHP, passandogli gli opportuni parametri per metterlo in grado di riconoscere la pagina richiesta dall'utente. in questo modo stai anche nascondendo l'URL reale della pagina statica (l'utente vedrà solo l'URL del PHP, non quello degli HTML).

    in questo modo il traffico sul DB è solo ed esclusivamente quello prodotto dagli amministratori che inseriscono i contenuti, e quello prodotto dal software di generazione delle pagine statiche (che ha il compito di leggere il DB e costruire il codice HTML statico), ma è quasi del tutto indipendente dal traffico degli utenti.

    ovviamente tutte le pagine che devono interagire direttamente con l'utente (es.: la registrazione dei dati di un modulo di registrazione, i risultati di una ricerca ecc.) devono essere dinamiche.

    in generale ti consiglio di generare contenuti statici a partire da contenuti dinamici, ogni volta che è possibile farlo. ovviamente è anche importante scindere fisicamente i server (file server contenente le pagine generate, database server, web server...).

    in ultimo, le pagine protette da log-in devono essere protette anche da Google.... quindi gli HTML statici devono stare su un path non raggiungibile dal web ma comunque raggiungibile con i dovuti permessi dal software che costruisce le pagine statiche.

    se hai altre domande, chiedi pure.

  3. #3
    aimè ciò che mi racconti non mi è nuovo... ma purtroppo non concigliabile con il mio sito... oramai tutto è dinamico e le pagine dovrebbero essere rigenerate ad ogni F5.. (un esempio? snowboard.com anche se è in asp)

    Quella interessante sarebbe di dividere il DB da webserver.

    Le ottimizzazioni fin'ora effettuate:
    - Da una media di 150 queries/pagina della versione attuale sono a 9 queries/pagina per quella nuova.
    - Ho pensato di aggiungerci anche eAccelerator ma devo ancora provare (alcuni parlano di -50% nella generazione)
    - Molti risultati di alcune queries vengono salvati nelle sessioni (file) che sono 70% più veloci in relazione con una query.
    - Tutti i jpg, css e js sono presi da un altro server...
    - POi ho smarty per i contenuti ma quello rallenta tantissimo (+10ms/pagina) dovrei trovarne una versione più (MOLTO) più rapida...
    - Tutte le immagini dinamiche sono state abolite (per ogni pagina ce n'erano 5 ...600'000 pagine al giorno fai un po il calcolo: povero CPU )

    Non so dove altro prendere spunto per ottimizzare ma ad esempio eBay non penso arrivi al suo sito utilizzando modalità ortodosse... DEV'ESSERCI QUALCOSA DI PIÙ per migliorare! ma io non so come.

  4. #4
    XHTML/CSS? ci hai pensato? così diminuisci di molto il peso delle pagine visto che escludi totalmente le tabelle di layout e trasferisci quasi soltando dati puri nel XHTML. mentre il CSS contenente il layout vero e proprio, una volta visualizzata una pagina, rimane in cache per la maggior parte degli utenti (cioè quelli che hanno abilitato la funzione di cache).

  5. #5
    già preso in considerazione...


    cmq guardavo poco fa, questo forum ha circa 2 milioni di messaggi (una tabella con 2 milioni di righe?!?!?! possibile che sia ancora cosi veloce?)

    e poi... c'è pure scritto che negli ultimi 30 secondi 499 utenti erano online...

    1 utente: circa 10 pagine al minuto...
    con una media di 10 queries per pagina circa... sono 100 queries al minuto per ogni utente...
    ...quindi 49'900 queries al minuto!

    Se una query singola, su una tabella pressochè vuota ci mette circa 1 millisecondo ad essere risolta... qui ce ne sono quasi mille al secondo... il che significa 1 secondo per query... le pagine dovrebbero caricarsi in tipo 15 secondo l'una... EPPURE sono rapide a caricarsi (a volte no, ma in genere lo sono).... come hanno organizzato il loro server??? sembra troppo efficiente! CHe il DB sia locato sulla RAM??? POssibile?? un po rischiso, no???

  6. #6
    nessuno segue il mio ragionamento?

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.