BaroneRosso.it - Forum Modellismo

BaroneRosso.it - Forum Modellismo (https://www.baronerosso.it/forum/)
-   Segnalazione Bug e consigli (https://www.baronerosso.it/forum/segnalazione-bug-e-consigli/)
-   -   La minchionata dei 30 secondi. (https://www.baronerosso.it/forum/segnalazione-bug-e-consigli/210694-la-minchionata-dei-30-secondi.html)

fai4602 01 maggio 11 14:07

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:

I-MACS 01 maggio 11 14:51

Citazione:

Originalmente inviato da fai4602 (Messaggio 2566074)
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:

non posso che essere d'accordo ed unirmi alla protesta..fà passare davvero la voglia.. :angry:

saluti

Badlucifer 01 maggio 11 14:54

Decisamente fastidiosa la storia dei 30 secondi, ma dipende se è necessaria per non appesantire il server...

simone76 01 maggio 11 15:15

use google

il_Zott 01 maggio 11 15:16

Citazione:

Originalmente inviato da Badlucifer (Messaggio 2566122)
... ma dipende se è necessaria per non appesantire il server...


e si è proprio per questo...

S_Ciambra 01 maggio 11 16:10

Citazione:

Originalmente inviato da il_Zott (Messaggio 2566146)
e si è proprio per questo...

Però mai visto in nessun altro Forum...

fai4602 01 maggio 11 16:26

Citazione:

Originalmente inviato da il_Zott (Messaggio 2566146)
e si è proprio per questo...

Ma dai...........figurati, potrei capire se facessi una ricerca subito dopo averne fatta una, ma di prima acchito.........e che diamine !!!

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:

staudacher300 01 maggio 11 16:51

Citazione:

Originalmente inviato da S_Ciambra (Messaggio 2566186)
Però mai visto in nessun altro Forum...

Presente anche su rcgroups fino all'avvento della versione 4.0. del vbulletin noi siamo fermi alla 3.6.12.
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

ddrake 01 maggio 11 16:54

Citazione:

Originalmente inviato da simone76 (Messaggio 2566144)
use google

con google non puoi cercare in un sottoforum o su un utente o in un thread specifico...

Citazione:

Originalmente inviato da il_Zott (Messaggio 2566146)
e si è proprio per questo...

mi sembra un limite necessario per utenti non registrati, per evitare attacchi con bot e simili (anche se c'è già la verifica testuale). Ma per gli utenti registrati non vedo proprio come potrebbero sovraccaricare il server. Dubito che le cpu siano stressate dalle ricerche su un db. La ricerca è fatta server side, non consuma banda che è invece la risorsa maggiormente costosa per un servizio hosting. E' quindi più oneroso che gli utenti sfoglino un thread alla ricerca delle informazioni anziché fare alcune ricerche.

Avete provato a vedere i carichi con attese di 10 secondi?

Ciao!

staudacher300 01 maggio 11 16:57

Citazione:

Originalmente inviato da ddrake (Messaggio 2566231)
con google non puoi cercare in un sottoforum o su un utente o in un thread specifico...



mi sembra un limite necessario per utenti non registrati, per evitare attacchi con bot e simili (anche se c'è già la verifica testuale). Ma per gli utenti registrati non vedo proprio come potrebbero sovraccaricare il server. Dubito che le cpu siano stressate dalle ricerche sun un db. La ricerca è fatta server side, non consuma banda che è invece la risorsa maggiormente costosa per un servizio hosting. E' quindi più oneroso che gli utenti sfoglino un thread alla ricerca delle informazioni anziché fare alcune ricerche.

Avete provato a vedere i carichi con attese di 10 secondi?

Ciao!

Se hai Windows prova a cercare qualcosa col tasto "cerca" del menù start, e poi prova ad usare contemporaneamente un programma, noterai un certo rallentamento ( in realta' si sbraca proprio" moltiplicalo per gli utenti che usano la ricerca di un forum e vedrai che ci vuole un bel gnocco per soddisfare tutti in tempi accettabili.:wacko:

ddrake 01 maggio 11 17:03

Citazione:

Originalmente inviato da staudacher300 (Messaggio 2566232)
Se hai Windows prova a cercare qualcosa col tasto "cerca" del menù start, e poi prova ad usare contemporaneamente un programma, noterai un certo rallentamento ( in realta' si sbraca proprio" moltiplicalo per gli utenti che usano la ricerca di un forum e vedrai che ci vuole un bel gnocco per soddisfare tutti in tempi accettabili.:wacko:

che c'entra??
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.

tochiro 01 maggio 11 17:48

Citazione:

Originalmente inviato da ddrake (Messaggio 2566231)
Ma per gli utenti registrati non vedo proprio come potrebbero sovraccaricare il server. Dubito che le cpu siano stressate dalle ricerche su un db. La ricerca è fatta server side, non consuma banda che è invece la risorsa maggiormente costosa per un servizio hosting. E' quindi più oneroso che gli utenti sfoglino un thread alla ricerca delle informazioni anziché fare alcune ricerche.

Avete provato a vedere i carichi con attese di 10 secondi?

Ciao!

Concordo su tutto. Una via di mezzo di 10 secondi sarebbe un giusto compromesso.
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.

vrpol 01 maggio 11 18:41

Io di ste' sobe capisco poco....:unsure:
Posso però quotare pienamente Fai
:en_fureur:en_fureur:en_fureur:notouch:

staudacher300 03 maggio 11 21:24

Citazione:

Originalmente inviato da ddrake (Messaggio 2566239)
che c'entra??
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.

Beh era un esempio pratico per dire che quando uno cerca qualcosa la macchina deve farlo e quindi qualcosa succede ed anche se é relativamente poca roba va moltiplicata per il numero di ricerche che vengon fatte in ogni momento, e poi che ne so chi ho davanti a livello infromatico, cerco di farmi capire per quel poco che capisco anche io a livello di programmazione.:P

blinking 03 maggio 11 21:33

se fosse tecnicamente possibile, mi piacerebbe che venisse tolto il limite anche solo per le ricerche che danno ZERO risultati.

staudacher300 03 maggio 11 21:38

Citazione:

Originalmente inviato da blinking (Messaggio 2570462)
se fosse tecnicamente possibile, mi piacerebbe che venisse tolto il limite anche solo per le ricerche che danno ZERO risultati.

Sinceramente non lo so, mi pare di ricordare che ci fosse un qualche problema a monte col vbulletina, provo a sentire il boss, magari sbaglio o ppure adesso si può risolvere, ma penso l'avrebbe fatto, non é che abbia piacere a non andare incontro alle esigenze della gente.
O forse no, sentiamo lui.

Ps: sempre che riesca a beccare in tempi umani la primularossa, altro che baronerosso. :D

ddrake 03 maggio 11 22:42

Citazione:

Originalmente inviato da staudacher300 (Messaggio 2570439)
Beh era un esempio pratico per dire che quando uno cerca qualcosa la macchina deve farlo e quindi qualcosa succede ed anche se é relativamente poca roba va moltiplicata per il numero di ricerche che vengon fatte in ogni momento, e poi che ne so chi ho davanti a livello infromatico, cerco di farmi capire per quel poco che capisco anche io a livello di programmazione.:P

Chiaro, però davvero qualche ricerca su un forum non può creare problemi ad un server come si deve. Immagino, dato il traffico, che baronerosso risieda su server dedicato/i quindi non ci sono problemi di risorse destinate a terzi.

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!

BaroneRosso 06 maggio 11 14:53

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.

luca.masali 06 maggio 11 15:04

Citazione:

Originalmente inviato da fai4602 (Messaggio 2566074)
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:

usa Google, no? :D

blinking 06 maggio 11 15:09

@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:

luca.masali 06 maggio 11 15:13

Citazione:

Originalmente inviato da blinking (Messaggio 2575244)
@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:

no, però ci fai il 90% delle ricerche che ti servono e scarichi il sistema. Poi se devi entrare nei dettagli allora è un altro discorso, quando capita vabbé, ci possono stare anche i 30 secondi. :P

fai4602 06 maggio 11 15:38

Citazione:

Originalmente inviato da BaroneRosso (Messaggio 2575215)
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...........................cut.

Grazie Francesco.

foam 06 maggio 11 16:03

mentre aspetti 30'' puoi postare di politica in off topic

luca.masali 06 maggio 11 16:34

Citazione:

Originalmente inviato da foam (Messaggio 2575326)
mentre aspetti 30'' puoi postare di politica in off topic

eccerto, tanto lì non hai da cercare nulla, un post vale l'alro:D

greg89 06 maggio 11 22:21

Citazione:

Originalmente inviato da BaroneRosso (Messaggio 2575215)
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.

Per curiosità. quanto viene a costare la versione 4.0 di Vbulletin... io sarei già uno di quelli disposti a mettere qualche euro per migliorare il Barone...

ddrake 06 maggio 11 22:25

Citazione:

Originalmente inviato da BaroneRosso (Messaggio 2575215)
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.

Intanto grazie per il vostro lavoro :)

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!

wrighi 06 maggio 11 22:27

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..

BaroneRosso 06 maggio 11 23:54

Citazione:

Originalmente inviato da ddrake (Messaggio 2575876)
Intanto grazie per il vostro lavoro :)

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!

Senza offesa non mi puoi paragonare un ambiente open source Linux / Apache / Mysql con un Solaris / Oracle che e' un ambiente di classe enterprise che solo di licenze puo' costare diverse svariate di migliaia di euro. :wink:
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:

ddrake 07 maggio 11 00:29

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!

fai4602 16 maggio 11 19:03

...........è 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