La minchionata dei 30 secondi. Da un pò di tempo faccio una tal fatica a fare una semplice ricerca che la maggior parte del tempo mi accontento di sacramentare pesantemente contro il server : ".........questo forum ha bisogno di un' attesa di 30 secondi fra una ricerca e l'altra......" o qualche cosa di simile. Ma che cavolo, nessuna doppia ricerca che si accavalli, entro in una sezione, in un thread qualunque, voglio vedere i messaggi di un utente qualsiasi e quel cazzone di server mi blocca........ma che vada a farsi fottere :uhm: |
Citazione:
saluti |
Decisamente fastidiosa la storia dei 30 secondi, ma dipende se è necessaria per non appesantire il server... |
use google |
Citazione:
e si è proprio per questo... |
Citazione:
|
Citazione:
Uffa, che par di palle..........sono convinto che questo intervallo possa essere ridotto , magari pure tolto, che il server nemmeno se ne accorge. E il server di qua, il server di la, di giù, di sù a destra a sinistra in alto in basso.............:shutup: |
Citazione:
A parte il costo non indifferente della 4.0 c'è il problema non da poco rappresentato dalle modifiche effettuate dal boss via via che se ne presentava la necessita' molte delle quali non compatibili col 4.0. Ragion per cui finché si può si evita di ricominciare daccapo. Tralascio il fatto che mettendo sotto scopa il server togliamo risorse agli altri utenti per cui è meglio imparare ad usare con furbizia ed oculatezza il motore di ricerca. Noi postiamo in proporzione il doppio degli americani ma l'Italia non é l'america, l'acqua é poca anzi scarseggia e la papera non galleggia.:D |
Citazione:
Citazione:
Avete provato a vedere i carichi con attese di 10 secondi? Ciao! |
Citazione:
|
Citazione:
parliamo di ricerche fatte su un db (immagino mysql o postgresql) mica delle inefficenze di winzozz :) Ripeto, potreste vedere i carichi con tempi di attesa di 10 secondi. Se notate una differenza significativa allora verosimilmente c'è un problema nella progettazione del db. Ciao! P.S. Ho fatto per lavoro sviluppo di strumenti di testing server side su datawarehouse, qualcosa ne so. |
Citazione:
O forse sfogliare tutte le pagine di un thread porta più click e quindi più banner visualizzati. Magari è una politica commerciale sensata, basta saperlo perché in altro modo quei 30 secondi non me li spiego. Naturalmente tutto imho. |
Io di ste' sobe capisco poco....:unsure: Posso però quotare pienamente Fai :en_fureur:en_fureur:en_fureur:notouch: |
Citazione:
|
se fosse tecnicamente possibile, mi piacerebbe che venisse tolto il limite anche solo per le ricerche che danno ZERO risultati. |
Citazione:
O forse no, sentiamo lui. Ps: sempre che riesca a beccare in tempi umani la primularossa, altro che baronerosso. :D |
Citazione:
Supponiamo che il numero totale di ricerche nel forum per unità di tempo attualmente sia = 100 e supponiamo che i tempi correnti siano accettabili. Di questi X sono fatti da utenti non registrati. 100-X sono fatti da utenti registrati. Le ricerche vengono ripetute in meno di 30 secondi soprattutto in caso di errori di battitura, ripensamenti sui criteri di ricerca ecc. Abbassando a 10 sec il limite aumenterebbero le ricerche solo per questi casi di errori vari. Quanto sarebbe l'aumento effetivo del numero di ricerche? non so ma non penso sarebbe molto elevato. Poi chiaramente potrebbe esserci anche l'utente registrato con più nick che lancia un attacco con Selenium per intasare i server, tutto può essere. Ma con tempi di attesa da 10 secondi dubito riesca a intasare alcunché. Data la mancanza di un'indicizzazione la ricerca per stringhe è in genere lunga ma se le risorse lo consentono il db moltiplica i processi di ricerca. Il problema in genere non è il tempo di calcolo o la memoria quanto il collo di bottiglia degli accessi al disco. Per ottimizzare le risorse un db utilizza metodi intelligenti di caching in memoria dei record aperti più spesso. Tipicamente i record più recenti avranno maggior probabilità di essere in memoria (fisica o swap su disco dedicato). I risultati vengono inoltre presentati mentre i thread sono ancora in esecuzione (per fortuna :rolleyes:). E' utile invece mantenere un limite per utenti non registrati per evitare congestionamenti da parte di bot. Ciao! |
Allora ho abbassato il time out a 10 secondi vediamo come va, un paio di anni fa ci avevamo provato e non era andato proprio bene. Riguardo il perche' e' stato messo a 30 secondi e' semplicemente un settaggio di default del forum ed e' dovuto all'enorme consumo di risorse che fa il MySql con le ricerche. Il Mysql non e' proprio il massimo con il suo algoritmo di ricerca ed anche ottimizzando le risorse a salire delle dimensioni del DB cresce esponenzialmente il carico sul sistema (sia di CPU che di Ram), non e' una cosa che si e' inventata il sottoscritto ma un dato di fatto basta andare sul sito del VBulletin e dare una letta alla sezione forum di grosse dimensioni. Considerate poi che la ricerca viene effettuata su un DB di oltre 4 milioni di record, mentre la tabella principale che contiene tutti i post, dove di solito e' effettuata principalmente la ricerca, e' grande circa 2.5GiB, quindi non sono proprio 4 campi da cercare. I forum piu' grandi, vedi ad esempio HWupgrade, hanno server appositi con un duplicato del DB dedicati esclusivamente alle funzioni di ricerca proprio per evitare sovraccarichi sulle macchine principali. L'ottimizzazione si puo' certamente fare, ma per tutto c'e' un limite di risorse HW, ovviamente si possono acquistare macchine sempre piu' grosse (ed infatti e' quello che generalmente si fa) ma visto che non e' che i server non e' che li regalino dentro le uova di Pasqua si cerca di rimanere nei limiti delle proprie possibilita' Tanto per la cronaca BaroneRosso.it gira su ben 2 server e la scorsa settimana sono stato in farm per aumentare la ram del server principale che e' stata portata a 24GB totali, visto che ultimamente avevamo finito i 12GB installati. |
Citazione:
|
@Luca: aridaje, con google non puoi fare ricerche avanzate come "da dentro" il forum grazie Francesco per la modifica, speriamo che il server la regga:wink: |
Citazione:
|
Citazione:
|
mentre aspetti 30'' puoi postare di politica in off topic |
Citazione:
|
Citazione:
|
Citazione:
Spesso cali di prestazioni in MySql (ma anche negli altri dbms) sono dovuti alla progettazione del database più che alla pesantezza delle richieste. La buona notizia è che ripensando un po' la struttura si possono migliorare le cose. Il partizionamento su server di ricerca con dischi SSD è un'opzione, certo. Anche un partizionamento con discriminanti temporali avrebbe un senso. Si potrebbe anche fare uno split delle tabelle più grandi su più dischi se non è già stato fatto. MySql ha un sistema abbastanza semplice per realizzarlo, i symlink. Non conosco l'OS di baronerosso ma sotto Solaris c'è un'importante funzionalità di non dividere su più cilindri un file. Non conosco in dettaglio vbulletin. Occorrerebbe anche capire come gestisca il carico di lavoro. Quante fork query faccia per una ricerca a seconda della situazione di carico del sistema. Parte dell'inefficienza potrebbe essere situata qui. Nei nostri test eseguivamo senza problemi centinaia di query contemporanee su datawarehouse > 10gb. Server Solaris, db Oracle :) Ciao! |
fastidiosa è vero.. non serve a nulla perchè i 30 secondi sono proprio 30 fissi e non soggetti ad un effettivo traffico.. se paradossalmente 100 utenti fanno una ricerca e subito un'altra.. si troveranno comunque tutti insieme a rifarla dopo 30 secondi.. è chiaro che se devo aspettare 30 secondi aggiorno la pagina e appena disponibile torno ad usarla. ne deriva che non serve come filtro per diluire le ricerche.. funzionerebbe se invece di aspettare 30 secondi ci fossero solo 30 slot libere per la ricerca e toccasse aggiornare appena se ne libera 1.. in quel caso si potrebbe dire che a causa del traffico bisogna attendere.. |
Citazione:
Preciso nulla contro l'opensource ma sono 2 mondi completamente diversi, Solaris gira su macchine estremamente ottimizate a tale scopo e confrontare Oracle e Mysql su DB di una certa dimensione e' come andare a fare una gara di auto da corsa con una macchina a pedali, basta solo vedere che immenso casino sia avere un DB bilanciato con Mysql. Visto che parli di query sul db ti posso dire che le stat del Mysql mi danno ben 296,30 k query l'ora, ovvero 82 e rotti al secondo su media giornaliera (bisogna pure considerare che il carico sul server ovviamente non e' mai costante lungo tutta la giornata), certo dei dischi ssd aiuterebbero non poco, ho avuto occasione di provarli, ma a parte il piccolo dettaglio che dischi del genere per server costano piu' o meno come un rene :( , e' ancora una tecnologia troppo recente ed ha diversi problemi sia di affidabilita' che di compatibilita', al momento preferisco i SAS a 15K che fanno egregiamente il loro lavoro. Ottimizzare il codice ovviamente si puo' ma piu' di tanto non si puo' fare piu' che altro perche' si dipende dal progetto di altri che e' il VBulletin, piu' modifiche si applicano maggiori sono i problemi a cui si va incontro ad ogni aggiornamento, tanto per rispondere a Greg89 la licenza del VB4 e' gia' stata acquistata pero' migrare alla nuova versione e' molto complesso in quanto ci sono diverse modifiche sul sistema che obbligano a riscrivere parti di codice ed a fare diversi test per non ritrovarsi tutto bloccato (per la cronaca sul server test di casa, un semplice core 2 con 4 gb di ram, impiega circa 6 ore per fare tutti gli aggiornamenti necessari), tra l'altro il team di sviluppo ha rilasciato fin troppe versioni una dietro l'altra ed onestamente preferisco aspettare un attimo prima di fare tutto il lavoro, infatti molti grossi forum stanno passando solo ora alla nuova versione, diciamo che la mia roadmap prevede il passaggio alla nuova piattaforma durante l'estate.:wink: |
Infatti, non intendo comparare i due sistemi, non avrebbe senso. Anche perché i nostri erano server di tre/quattro anni fa. Surclassati da quelli attuali. Solaris comunque lo avevamo open... anche oracle era a costo zero per la verità, in quanto partner ^_^ Quello che intendo dire è che spesso con un'ottimizzazione del db si può ottenere un vantaggio prestazionale non indifferente. Lo scopo del nostro testing era appunto quantificare il vantaggio prestazionale di una determinata soluzione. Ciao! |
...........è diventa di 60 secondi.......... Ma che cavolo succede................ora di secondi me ne chiede SESSANTA !!!!!!!!!! :shutup::shutup::shutup: |
Tutti gli orari sono GMT +2. Adesso sono le 17:49. |
Basato su: vBulletin versione 3.8.11
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
E' vietata la riproduzione, anche solo in parte, di contenuti e grafica. Copyright 1998/2019 - K-Bits P.I. 09395831002