Visualizzazione dei risultati da 1 a 6 su 6
  1. #1

    connessioni concorrenti su server?

    Salve a tutti,
    premetto che sono un nuovo utente ancora incosciente, da poco mi sono avvicinato al mondo della programmazione ed ora mi è sorto un problemino:
    ho creato un'applicazione che si installa su client che si collega ad un database posto su una macchina in remoto.
    Questo programmino non fa altro che interrogare, inserire e modificare record nel database(creato con mysql-sulla macchina server è montato mysqlserver).
    La connessione alla macchina server avviene tramite internet.

    Il dubbio è come faccio a sapere quante utenze (connessioni) concorrenti posso avere alla macchina server su cui è montato il database?
    E per avere almeno un centinaio di connessioni concorrenti cosa dovrei fare?
    Ringrazio tutti del gentile aiuto,
    saluti e buone feste Danilo Russo.

  2. #2
    Utente di HTML.it
    Registrato dal
    Jan 2011
    Messaggi
    1,469
    la risposta non è immediata, con una domanda un pochino generica.

    In generale (ipotizzando una configurazione "semplice", chè mi pare coerente col tenore del quesito) la risposta dipende sia dalla macchina (inteso come sistema operativo) sia dal mysql, sia dal mysql.ini (ovvero come è configurato), sia da cosa intendi per "interrogare, inserire, modificare" (ossia il carico sulla macchina).

    Per capirci una ricerca full text su una tabella myisam di 1 milione di righe ti "blocca" per una ventina di secondi l'avanzamento di tutte le altre query mysql (il riferimento è ad un database per forum), e in questo caso le connessioni sono... 0, 1 o 2
    ---
    Per avere una grande concorrenza la risposta è... dipende.
    Sia dal tipo di carico (letture=parallelizzabili, scritture in generale no?), dalla possibilità di partizionare le tabelle (orizzontalmente con mysql >5.1), sia dall'efficienza del sistema operativo e di tutti gli switch cui è collegato.

    Anche lo storage engine scelto incide considerevolmente
    ---

    personalmente (parlo di un esempio personale di macchina buona, ma non "spaziale") amministro un sistema freebsd con mysql con una media di 430 query al secondo sulle 24 ore [è il db di un forum, quindi il "solito" mix di letture-scritture-aggiornamenti], non credo sia facile andare oltre (sono circa 2 millisecondi a comando), con un singolo computer e mysql
    ---
    La risposta non è un granchè, ma se precisi un pochino le richieste magari posso essere più utile

  3. #3
    Inizio con il ringraziarti per la tua disponibilità, e approfitto per fare gli auguri di buon anno!

    il problema è di semplice spiegazione.
    Ho un database, costruito su 4 tabelle in mysql con engine: MyIsam e codifica utf8.
    il client provvisto di un'applicazione, scritta da me, invia stringhe sql con diverse query a seconda dei comandi che si lanciano. tra le tabelle del database alla fine solo una sarà quella che avrà la maggiore frequenza di popolamento: prevedo che entro un anno debbano essere registrati perlomeno un milione di record. La tabella in questione è provvista di 9 campi:
    contatore, INT, data, VARCHAR(11), DOUBLE, INT,VARCHAR(11), data, ora;
    apparte il codice inviato per il popolamento del database (operazioni meno frequenti rispetto l'invio di Query di selezione) quasi tutte le query di selezione agiscono su questa tabella. Non avvengono ricerche in fulltext per lo più ho creato query con operatori di aggregazione in modo da ottenere dati per statistiche.

    Ora la perplessità è questa come faccio ad essere sicuro che, avendo 100 utenti(che agiscono da client), il server riesca a gestire tutte e 100 utenze anche nel caso che siano contemporaneamente loggati. Precisando, le classi di query create sono all'incirca 7-8. Quindi ogni utente avrà a disposizione 7-8 comandi per ottenere dei dati...ovviamente poi ci sono comandi che permettono l'inserimento dei record nel database.
    L''idea che avevo era di crearmi un server:
    quindi comprare una macchina con sistema operativo windows con un processore della intel e caricare unicamente su di essa questo database...poi in futuro potrò forse metter altri database, ma al momento non c'è tale problema, Ovviamente tale macchina verà collegata alla rete internet per poi far si che tutti gli utenti possano accedere al database disponendo di una connessione internet.

    ringraziandoti per la tua gentilezza, ti saluto
    Danilo Russo.

  4. #4
    Utente di HTML.it
    Registrato dal
    Jan 2011
    Messaggi
    1,469
    Ho un database, costruito su 4 tabelle in mysql con engine: MyIsam e codifica utf8.
    Attento: per cominciare dipende da quante righe ci sono, e quali indici, e che tipo di interrogazioni fai.
    Se le righe son poche => non hai problemi
    Se le righe son molte (diciamo da 1.000.000 in su, come ordine di grandezza) bisogna rifletterci (join?)

    apparte il codice inviato per il popolamento del database (operazioni meno frequenti rispetto l'invio di Query di selezione) quasi tutte le query di selezione agiscono su questa tabella.
    Te lo sconsiglio e, tra breve ti spiego perchè
    ...per lo più ho creato query con operatori di aggregazione in modo da ottenere dati per statistiche.
    Questo è, in generale, male
    Ora la perplessità è questa come faccio ad essere sicuro che, avendo 100 utenti(che agiscono da client), ...
    100 utenti possono essere pochi o tantissimi, a seconda del tipo di carico che generano
    L''idea che avevo era di crearmi un server (...)Ovviamente tale macchina verà collegata alla rete internet per poi far si che tutti gli utenti possano accedere al database disponendo di una connessione internet.
    Ti sconsiglio sia windows si la connessione a internet diretta del database mysql, che ha un livello di protezione bassissimo.

    ====
    Per ordine (tra un poco devo assentarmi, magari dettaglio di più)

    myisam NON gestisce la concorrenza di più utenti, o meglio appioppa lock a livello di tabella in scrittura (ciò non è vero nel caso di aggiunte in coda, se lo setti così), quindi va malissimo quando hai un mix di letture e scritture da parte di molti utenti.

    ogni scrittura (in realtà gli update, non le insert in coda, lo ribadisco) blocca tutte le altre letture degli altri 99 client.

    E' quindi chiaro che è il mix di comandi SQL a stabilire se 100 utenti per un milione di righe son molti o pochi. Se, essenzialmente, non fanno altro che interrogare i dati, allora son pochi, e li gestisci anche con una macchina piccola.

    Se fanno update molto spesso => devi cambiare engine (innodb) e ripensare l'intera procedure
    ====
    Riguardo poi alla macchina "esporla" direttamente su internet è troppo pericoloso, in quanto i meccanismi di autenticazione di mysql sono deboli, debolissimi, e rischi attacchi di tutti i tipi, te lo sconsiglio

    Per quanto riguarda poi "che tipo di macchina", se ci gira solo mysql, alla grande ti suggerirei una FreeBSD, di gran lunga più performante e sicura di una Windows (oltre che più economica).

    Come già detto, tuttavia, rifletti a fondo su "come" far arrivare i comandi al server mysql

    PS perchè UTF8 e non latin1? hai caratteri strani? UTF ti aumenterà a dismisura la dimensione della tabella

    PS/2 che funzioni di aggregazione? sono ben pensate? sono indispensabili? hai già provato le explain extend?
    Non conviene calcolarle on-the-fly, invece che ricalcolarle ogni volta?

  5. #5
    Ho incominciato a cambiare gli engine del database, ho imposto innoDB, ed anhce latin1 anzicchè UTF8.
    purtroppo le funzioni di aggregazione mi servono per l'estrapolazione di valori che poi andranno a confluire in statistiche fatte a parte, quindi non penso di poterne fare a meno.
    Un esempio di una delle funzioni che più uso è:
    (questo script viene lanciato da un programma scritto in VB creato con Visual Studio, è giusto una GUI per permettere l'aggancio con il database. Ho creato una gui, perchè non volevo usare il browser come interfaccia)


    select cliente.nome, cliente.cognome, cliente.via, cliente.citta, cliente.telefono,
    cliente.cellulare, cliente.Piva, cliente.ECE AS CondizioniEconomiche,riordini.nota as OPERAZIONE,
    max(riordini.dataNOTA)Appuntamento_in_data, max(riordini.orarioNOTA) alle_ore

    from cliente inner join riordini

    on cliente.idCLIENTE=riordini.idclienti

    where
    (
    riordini.idclienti=
    (
    select riordini.idclienti
    from riordini
    where(
    (riordini.nota='RICHIAMARE')
    and
    (
    (
    (datediff(CURDATE(),riordini.dataNOTA) > 6) and (datediff(CURDATE(),riordini.dataNOTA) < 30)
    )
    )
    )
    group by riordini.idclienti
    having count(riordini.idclienti)> 1
    )

    )
    ;


    dove la tabella "riordini" è quella con maggiore popolazione.

    comunque sicuramente gli utenti di questo database dovrannò "inserire" e "modificare".
    Per quanto riguarda il sistema operativo, il freeBSD non l'ho mai usato...ho usato LINUX il MacOs, i vari windows.
    Per la sicurezza del database, c'è da dire che questo non sarà montato su un sito internet, e il database lo potranno vedere solo gli utenti che disporranno del programma che ho preparato...quindi tanto quanto al momento non è quello il problema principale...poi forse più in là ci darò un occhiata per renderlo più sicuro.

    Quindi volendo riassumere, che cosa potrei fare per far si che nel momento in cui tutti e 100 gli utenti siano collegati e stiano inserendo, modificando e interrogando, non vada in panne il sistema?

  6. #6
    Utente di HTML.it
    Registrato dal
    Jan 2011
    Messaggi
    1,469
    Originariamente inviato da dan_o_ru
    (...)
    Manca il describe.
    mancano gli indici

    E soprattutto manca l'explain extended
    Comunque, giusto per dare qualche idea,
    1) trasforma la funzione su datanota in un intervallo
    (questo è bene se è indiciato, l'ottimizzatore non lavora)

    2) è la selettività degli indici che determina la velocità

    3) se hai un'applicazione, spezza in due la query, memorizzando i risultati intermedi (da verificare)

    4) non mi è chiarissimo come sono memorizzati i dati, ma puoi partizionarli orizzontalmente?

    comunque sicuramente gli utenti di questo database dovrannò "inserire" e "modificare".
    Questo è "normale", ma cosa fanno?
    inseriscono e modificano, o interrogano?
    Per stabilire cosa fare devi assolutamente misurare, l'ottimizzare qualcosa "a capocchia" (al di là delle solite banalità)


    Per la sicurezza del database, c'è da dire che questo non sarà montato su un sito internet, e il database lo potranno vedere solo gli utenti che disporranno del programma che ho preparato...quindi tanto quanto al momento non è quello il problema principale...poi forse più in là ci darò un occhiata per renderlo più sicuro.
    Non mi è chiarissimo. Se usano la porta standard 3306, o comunque una qualsiasi altra porta "esposta", la sicurezza è bassa (anzi nulla)

    Quindi volendo riassumere, che cosa potrei fare per far si che nel momento in cui tutti e 100 gli utenti siano collegati e stiano inserendo, modificando e interrogando, non vada in panne il sistema?
    stabilire il profilo di utilizzo, attivare il solito slow query log, eventualmente mettere un proxy SQL (ma fai prima a loggare le query direttamente da applicazione).

    Se sono inserimenti "umani" (ossia sono persone fisiche che inseriscono i dati e fanno "scrivi") i tempi sono così lunghi che non prevedo alcun problema.

    Se invece ci sono inserimenti batch allora il mix va valutato.

    Il punto è: in quanto tempo viene eseguita la query di selezione?
    Quanto spesso viene lanciata?

    Per "contarli" puoi banalmente usare show processlist, o da mysqladmin
    ---
    Riguardo ai processi mysql di default sono 100 o 150 (a seconda della versione), puoi aumentarli con max_connections

    In generale 100 utenti non sono un numero particolarmente elevato (bsd e linux di sicuro, windows non so)

    EDIT: attenzione a differenziare tra max_connections max_user_connections. Se esiste un "filtro" (es. server http) allora ti troverai con uno o due utenti, e tante connessioni.
    Se ogni utente invece ha una connessione devi settare di conseguenza nelle impostazioni

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.