Visualizzazione dei risultati da 1 a 4 su 4
  1. #1
    Utente di HTML.it
    Registrato dal
    Oct 2006
    Messaggi
    42

    [JOOMLA] hosting o housing?

    Salve,

    avrei una domanda riguardo il cms joomla e l'eventualità che il portale che creo abbia connessioni multiple nello stesso momento:

    In sostanza quindi vorrei sapere quale sarebbe la scelta migliore per poter offrire una navigazione "prestante", nonostante il mio portale abbia un numero sostanzioso di contenuti e di accessi al database.

    La cosa che mi cruccia maggiormente è l'ampiezza di banda e come viene gestita dalle webfarm (genericamente), e nel caso in cui dovessi affittare un server, delle specifiche tecniche a cui dover dar conto, per esempio, di quanta ram avrebbe bisogno?


    Mi potreste dare un consiglio?

    grazie,
    Mith84

  2. #2
    Beh, per quanto ti si volesse rispondere, nel limite del regolamento ovviamente, quindi senza fare nomi, dovresti dare informazioni in più.

    Partiamo dalla base: joomla è un mattone, cosi come tanti altri CMS presenti in giro, e quando ci sono MOLTI accessi contemporanei i mattoni diventano molti

    La ram serve relativamente se la macchina non è configurata correttamente: con 256mb di ram, senza nessuna ottimizzazione, ci sarebbe una tonnellata di memoria libera!

    Tu considera che il server dedicato che gestisco ha 2 gb di memoria di cui solo 370mb sono usati "realmente": il resto è usato come cache del sistema operativo (sono presenti tantissimi siti di clienti li su). Inoltre sul server c'è la posta, l'antispam, l'antivirus, webdav, subversion, e tanta altr aroba. Nel tuo caso però, avendo solo il tuo sito, non arriveresti neanche ad avvicinarti a quei consumi!

    Devi fare un conteggio molto semplice: quanti utenti avrò connessi contemporaneamente in media? Considerando che Joomla, di base, consuma mediamente 6mb di memoria per pagina, ovviamente se hai aggiunto componenti, moduli particolari o quant'altro, questo valore sale, e mettendo, ad esempio, 50 utenti connessi nell'arco di 1 secondo, e mettendo che per l'esecuzione una pagina impiega 5 decimi, quindi mezzo secondo, per non usare la swap durante l'elaborazione (la swap è una memoria virtuale presente sul disco che però, per essere usata, va copiata in memoria fisica e la porzione di memoria fisica usata va copiata nella swap) avrai bisogno di (50 * 6) / 2 ovvero 150mb di memoria. In realtà il conteggio è ovviamente molto spartano perché potrebbero connettersi tutti e 50 contemporaneamente e non distribuiti nell'arco di 1 secondo.

    Ovviamente c'è anche da considerare che 50 utenti, in un secondo, sono una cifra ASTRONOMICA: 50 * 60 (secondi) * 60 (minuti) * 24 (ore) vorrebero dire 4.320.000 pagine visualizzate

    Perché ti ho fatto un esempio cosi esagerato? Per farti capire che anche con questa cifra astronomica, in realtà, il problema non è tanto la quantità di memoria ma come la si usa!

    Infatti se si configura mysql correttamente, ovvero configurando correttamente la cache per le chiavi, la cache per le query, la cache per le tabelle e via dicendo, e poi si aggiunge un bel sistema di caching per php come eAccelerator si riduce CONSIDEREVOLMENTE il tempo di esecuzione delle pagine, anche se si consuma più memoria.

    Mediamente, un server ha da 1 gb a salire, se devi avere un solo sito ... già un gb basta e avanza.

    Il problema principale, in realtà, è la CPU ed il DISCO ... se però si configura tutto correttamente questo problema si riduce ai minimi termini: configurando correttamente apache (o meglio ancora nginx con php in fastcgi) si può utilizzare memcached, un software per il caching che è quasi il più veloce in circolazione! Se il webserver carica li su il file che deve spedire al client, tutti gli accessi successivi non saranno fatti al disco ma al software che ha tutto in memoria!

    Se tutto ciò si fa correttamente, anche un E5200/E5300 è già MOLTO più che sufficente per gestire tutto!
    The fastest Redis alternative ... cachegrand! https://github.com/danielealbano/cachegrand

  3. #3
    Utente di HTML.it
    Registrato dal
    Oct 2006
    Messaggi
    42
    Grazie della risposta daniele, molto esaustiva.

    Quello che mi hai detto è molto utile, ma solo considerando la possibilità che io affitti il server.

    Nel caso in cui io invece volessi prendere in considerazione la possibilità di mettere il portale su un server in hosting, cosa dovrei considerare per sapere se la navigazione nel portale risulterà decente o meno?

    se dovessi invece scegliere l'housing, la configurazione alla fine dovrei farla tutta io, o comunque il provider ci pensa lui e poi io modifico solo quello di cui ho bisogno?

    scusa se suona generico, ma è giusto per avere un idea più chiara su come procedere nella scelta della webfarm.

    grazie mille,
    mith84

  4. #4
    mi sa che c'è un pò di confusione ...

    se parliamo di "server dedicati", in colocation (quindi tuo che mandi/porti alla webfarm) o in housing (ovvero affittato dalla webfarm), è indifferente: se lo devi acquistare e mandare ti devi preoccupare, al momento dell'acquisto, di controllare le caratteristiche per poi mandarlo e controllare i contratti per la banda mentre se lo devi affittare allora controlli le caratteristiche del server e della banda direttamente dalla webfarm ... ma il discorso è ASSOLUTAMENTE identico

    se invece parli di normale hosting, beh, direi che allora il ragionamento che fai è sbagliato di fondo: non puoi mettere a paragone un servizio di hosting che, per quanto professionale sia, non ti garantisce NULLA (a parte, forse, la banda)! Se uno dei siti killa il server su cui sei puoi farci decisamente poco ^^

    Se cerchi garanzie ci vuole la macchina dedicata acquistata o in affitto, se non hai bisogno di garanzie e numeri certi va bene anche l'hosting nella misura in cui il tuo sito web non fa un traffico eccessivo e non richiede ingenti risorse hardware.
    The fastest Redis alternative ... cachegrand! https://github.com/danielealbano/cachegrand

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.