Linux, PHP, MySQL, Windows, C#

Era da un po’ di tempo che mi chiedevo se l’implementazione di Linq To SQL per mysql di DevArt fosse più efficiente o meno dell’alternativa di casa mysql.

Ho quindi deciso di farmi in casa un benchmark che, sebbene effettuato in modo piuttosto grossolano e rapido ha dato dei risultati abbastanza netti.
Il test è stato eseguito con le seguenti condizioni (da qui capirete che è abbastanza spartano come benchmark):

• Windows 7 64 BIT
• mysql 5.1.x 64 BIT per Windows
• .NET Framework 4.0
• Utilizzato Cassini al posto di IIS
• DevArt versione 6.30.185.0
• mysql Connector NET versione 6.4.4

In pratica ho lanciato due procedure separate con la mia macchina nelle stesse condizioni di lavoro e a distanza di pochissimo tempo, quindi applicativi aperti, musica che suona e via discorrendo

Il test era suddiviso in due componenti, l’esecuzione di 1.000 query su una tabella con campo indicizzato passandogli un valore randomico e l’inserimento di 1.000 record sempre con valori randomici.
In particolare l’inserimento prevedeva il COMMIT ad ogni STATEMENT perché altrimenti non si notava alcuna differenza di performance tra i due drivers.

Di seguito i risultati nudi e crudi:

mysql (utilizzo 27%/30% CPU poi sceso in insert a 13%/15%) 6.4.4

• Data avvio select: 30/12/2011 18:12:03
• Data fine select: 30/12/2011 18:12:31
• Data avvio insert: 30/12/2011 18:12:31
• Data fine insert: 30/12/2011 18:12:43

DevArt (utilizzo 27%/31% CPU in insert a 13%/17%) 6.30.185.0

• Data avvio select: 30/12/2011 18:13:21
• Data fine select: 30/12/2011 18:13:38
• Data avvio insert: 30/12/2011 18:13:38
• Data fine insert: 30/12/2011 18:13:44

Tempo SELECT MySQL: 28 secondi
Tempo SELECT DevArt: 17 secondi

Tempo INSERT MySQL: 12 secondi
Tempo INSERT DevArt: 6 secondi

Direi che è abbastanza chiaro che, a parte una lieve differenza nell’utilizzo della CPU (in favore del driver mysql Connector NET meno esoso), la velocità di esecuzione sia delle SELECT che delle INSERT è nettamente in favore di DevArt.

Morale, bene così, almeno non ho toppato driver per un importante progetto che sto sviluppando!

Nella configurazione di mysql (mi pare anche nella standard da RPM delle redhat based) non viene configurato il parametro il parametro: tmpdir che normalmente assume il valore di default del sistema. Su Linux naturalmente /tmp.

Qualora per motivi di spazio o banalmente convinti che la /tmp non sia necessario renderla di ampie dimensioni, potrebbe accadere che durante certe operazioni molto pesanti su tabelle con quantitativi di record notevoli, il sistema esaurisca lo spazio nella partizione temporanea durante la fase di elaborazione dati e scrittura di una tmp table, proprio su questa partizione.

La query abortira’ con un messaggio del tipo no space left on device o qualcosa del genere.

In tal caso andra’ allargata la partizione tmp di sistema (o dove si appoggia mysql) o in alternativa cambiato il path (che deve essere scrivibile dallo user “mysql“), fermato il servizio mysql e riavviato.

[SEGNALO CHE HO SCOPERTO QUESTA COSA DA POCO E LIMITANDOMI AD ALCUNI TEST E PROVE VELOCI MA REALI, PERCUI OGNI EVENTUALE APPROFONDIMENTO/SMENTITA ETC... E' BEN ACCETTO]

Segnalo una problematica di sicurezza abbastanza importante per coloro che utilizzano adodb utilizzando il driver mysqli (le nuove funzioni di connessione con mysql native in php 5).

In sostanza le nuove funzioni mysqli consentono mediante la seguente funzione: mysqli_multi_query di poter eseguire più statement SQL in mysql come ad esempio:

SELECT * FROM TBL1 WHERE id = 1; DROP table TBL2;

Questa query utilizzando le vecchie librerie mysql (es. mysql_connect) dava errore.
La possibilità di eseguire più query SQL è supportata su mysql 5.0.x anche da command line, non saprei se anche vecchie versioni lo consentivano.

Questo significa che se per esempio utilizziamo in php una query del tipo:

$sql = “SELECT * FROM tbl1 WHERE id = $_GET['id']“; // (Premesso che venga come minimo fatto l’escape dei caratteri come ‘ o “)

Possiamo rischiare che qualche burlone passi in GET il seguente valore:
“1; DROP TABLE tbl2;”
Il che comporterebbe che l’SQL eseguito sia:

SELECT * FROM TBL1; DROP table TBL2;

Di fatto quindi con AdoDB con driver mysqli, la seconda query viene effettivamente eseguita.

Diventa quindi essenziale fare un controllo sull’input dell’utente per $_GET['id']. Ad esempio verificando che sia un numero intero.

La soluzione più rapida è quella di cambiare la connect di AdoDB dicendogli di usare il driver mysql anziché mysqli, la soluzione migliore e da fare comunque resta in ogni caso il filtraggio di tutti i dati in input.

Di seguito l’articolo in italiano di Punto Informatico:

http://punto-informatico.it/2494271/PI/News/mysql-51-una-falsa-partenza.aspx

E qui l’articolo ufficiale in lingua inglese di Michael Widenius ex CTO della mysql AB acquistata tempo fa da SUN.

http://monty-says.blogspot.com/2008/11/oops-we-did-it-again-mysql-51-released.html

Io per adesso rimango sul 5.0 sul quale onestamente ho avuto pochi problemi.

Finalmente trovo il tempo di pubblicare un articolo…

Vediamo di seguito l’utilizzo dei TRIGGER in mysql 5, se non dico male infatti sino alla versione 5.0.x i TRIGGER su mysql non erano disponibili.

Prima di tutto, a cosa servono i TRIGGER? I TRIGGER hanno il principale scopo di automatizzare determinate operazioni sul database all’occorrenza di determinati eventi come INSERT, UPDATE o DELETE.

Il modo con cui creare un TRIGGER è piuttosto semplice:

CREATE TRIGGER setnoprice BEFORE UPDATE ON prodotto
FOR EACH ROW
BEGIN
IF NEW.online = ‘no’ THEN
SET NEW.prezzo = 0;
END IF;
END

Analizziamo cosa fa di fatto questo TRIGGER, al di là della sintassi:

Ipotizziamo di avere ad esempio un sito di e-commerce dal quale i prodotti sono acquistabili esclusivamente quando il loro prezzo è maggiore di zero, mentre sono online altri prodotti per il quale esiste una presentazione ma l’acquisto può essere fatto contattando l’ufficio commerciale e non viene esposto il prezzo.

Conseguentemente quando un prodotto va offline è automatico che non sia più vendibile. La soluzione più classica e semplice (apparentemente) è quella di gestire l’operazione direttamente da backoffice dell’applicativo in modo automatico o peggio ancora di delegare al gestore del backoffice il fatto di resettare a zero il prezzo quando un prodotto va offline.

[Piccolo inciso, so benissimo che potrebbe essere bloccato l'acquisto oltre che per prezzo a zero anche nel caso il flag online sia off, così come so che il prodotto non sarebbe nemmeno visualizzato, ma un'esempio lo dovevo fare... ]

Entrando nel dettaglio mysql applicando questo TRIGGER si preoccupa di eseguire PRIMA [BEFORE] dell’azione UPDATE [solo update quindi] la verifica se online diventerà uguale a off e in tal caso forza il nuovo valore di prezzo a zero.

In sostanza il TRIGGER va a sostituire quelle operazioni automatiche che normalmente vengono delegate all’applicativo.

Per maggiori informazioni potete consultare direttamente il manuale di mysql alla pagina relativa ai TRIGGER.