Importante: Questa pagina utilizza i cookie (cookies). L'utilizzo di questo sito senza disattivare i cookies in del browser, significa che sei d'accordo per il suo utilizzo.
Al momento ho configurato il mio sistema per cancellare l'intera cache ogni settimana. Con una cache vuota, il mio database è di circa 1.1GB, mentre con una cache piena, si tratta di 4,5 GB.
Ho notato che maggiore è la cache, il mio più alto carico del server media ottiene. In qualsiasi momento il mio forum ha tra i 650 e 1300 utenti online, ma questo non sembra influenzare il carico tanto quanto la dimensione della cache.
Con una cache di grandi dimensioni, il carico del server è 3,3-3,8, mentre con uno vuoto, rimane nel range 2,0-2,5. Questo non è affatto male, come ho già a 16-core server, ma mi stavo chiedendo se un tale comportamento è prevedibile con le dimensioni del database fluttuante!
vBET ha indici per le tabelle di cache ed utilizza più veloce motore di MySQL per il cappello - MyISAM. Così abbiamo scelte migliori per la cache DB. Tutta la differenza che si nota non è nel lato di vBET, ma nel lato di MySQL che esegue query. Indici ti dà una risposta più rapida e assicura che il tempo di risposta non sta andando drammaticamente con grandi quantità di dati. Ancora MySQL deve cercare più grandi indici e come credo ci vuole più risorse. Questo è il motivo per cui si nota il carico del server più grande.
Anche - quando la traduzione è presente nella cache allora è presa da lì. Se poi non viene chiesto di Google per la traduzione. Ci vuole più tempo poi, ma molto probabilmente ha anche meno risorse del server. Ci vuole più tempo perché non vi è comunicazione con i server di Google che richiede tempo, non c'è traduzione che richiede tempo e non ci sta inviando i risultati di Google al vostro server che prende anche il tempo. Ci vuole meno risorse, perché server è in attesa di risposta passivamente e quando si arriva c'è solo semplice l'estrazione di risposta. Ottenere traduzione dalla cache è molto, molto più veloce - la traduzione è già stato fatto ed è sul proprio server, ancora devono essere prese dal database, query devono essere eseguiti, MySQL richiede un po 'di CPU e memoria per questo.
Supponendo che - utilizzando la cache è un'idea molto buona. Se vi sentirete che il server ha problemi con cui si può sperimentare di disabilitare la cache per alcune lingue e confrontare le prestazioni del server. Noi non consigliamo di rimuovere la cache completamente.
Le prestazioni sono bene in questo momento, è solo che non è mai il carico è andato molto più alta di 2,0 prima vBET. Credo che ne valga la pena, però!
Fino a quando il carico è inferiore a 16,0 poi il server non è tassato, quindi penso che stiamo bene
Stiamo pensando di aggiungere anche della cache dei file vBET. Perché in questo momento la nostra priorità e la maggior parte degli sforzi sono vBET4.0 non abbiamo alcun programma per la funzionalità di file di cache. Si ricorda che è possibile personalizzare le lingue funziona con cache. Quindi, se volete potete utilizzare solo la cache di alcuni di traduzione che si renderà disponibile. Inoltre tieni presente che la versione a pagamento del vBET hanno migliorato cache del database per cui è più veloce che in versione gratuita. Ci sono anche altri miglioramenti in versione a pagamento - in genere è più veloce e prendere meno memoria. Abbiamo già clienti che stanno usando con successo su tavole di grandi dimensioni.
Non abbiamo fatto test di performance con nginx acceleratore, quindi non posso confrontare.
Si prega di notare che il marchio di licenza gratuita acquisto non è obbligatorio e si può sempre aggiornare la licenza più tardi.
In questo momento che siamo molto vicino al rilascio di vBET4.0 e noi abbiamo molto lavoro con quello. Se vuoi testare bb sotto nginx, quindi per favore aprire nuovo thread nella richiesta di funzione. Se è in esecuzione nginx php poi bb lavoro lì. Una questione - se si desidera utilizzare la traduzione SEO Link quindi riscrivere le regole saranno necessaria. Abbiamo quelli preparati solo per apache nel file. htaccess, in questo momento, ma se non siete in grado di riscrivere Apache per nginx poi si possono sempre utilizzare collegamenti con lingua attributo - questo è molto facile. Si può sperimentare con la versione gratuita per evitare problemi imprevisti prima di acquistarne uno a pagamento.