Newsgroup: it.comp.os.linux.development
Titolo: Velocità query mysql

allora devo fare un applicativo che durante la sua esecuzione forka per
generare N figli (con N discretamente alto, per adesso siamo sull'ordine
del centinaio, ma arriveremo presto a 1000).
ogni figlio non fa altro che eseguire uno script php tramite popen e
memorizzarne il risultato in un db.
Quindi diciamo che questo processo fa:
padre->connessione al db -> fork -> popen -> scrittura dei risultati nel
db
Mi stavo chiedendo in termini di velocità , occupazione memoria e cpu
quanto possono migliorare le performances a in base al linguaggio che uso.
Il programma fa poco altro che query al db, e comunque i processi figli
sono legati alla velocità degli script php (che non ho tempo nè voglia
di tradurre in altri liguaggi), almeno credo.
Quindi : posso fare un script in python o php o quel che è, oppure se uso
il C ho un aumento tangibile delle prestazioni?
ah, un'altra soluzione potrebbe essere:
padre -> fork -> exec sullo script (e tutte le operazioni sul db avvengono
dentro allo script)
ecco è tutto, sono benevenuti consigli di ogni genere

 ecco č tutto, sono benevenuti consigli di ogni genere
Il massimo incremento di prestazioni lo avresti con:
padre-> apertura DB->creazione thread->scrittura DB con api C di mysql.
In questo modo cancelli una serie di overhead non da poco (il fork ad 
esempio ti aumenta a N anche il footprint in memoria dell'applicazione e 
di conseguenza azzera quasi l'utilita' della cache del processore), il 
contro e` che ti esponi, a seconda di come e` realizzato il tuo codice, 
anche a problemi di conncorrenza nelle API mysql che utilizzi.
L'interfaccia C di mysql e` molto semplice ed il php non e` molto 
diverso dal C come flusso di codice, quindi la conversione suppongo non 
sara' molto pesante....
Sono piuttosto convinto che una modifica di questo tipo potrebbe 
incrementare le prestazioni del tuo sistema almeno di un fattore 10, 
pero` SE il collo di bottiglia fosse altrove (scrittura su DB, query...) 
le prestazioni non sarebbero migliorate con il cambio di architettura.
Bye,
  Gabry

 pero` SE il collo di bottiglia fosse altrove (scrittura su DB
infatti alla fine il senso della mia domanda era condamentalmente
questo:
se il padre lo faccio in (ad esempio) python, ho davvero un
perdita delle prestazioni o mi devo comunque rimettere alla lentezza della
scrittura/lettura su db o degli script php?
in ogni caso grazie della risposta.

 scrittura/lettura su db o degli script php?
Il grosso della lentezza di PHP e` la compilazione degli script.
Probabilmente facendo tutto in un unico processo scritto in PHP che forka 
parti di se` stesso, avresti gia` un incremento di velocita`, perche` 
compili una volta sola.
Non mi pare ci sia un modo per eseguire direttamente i precompilati da 
linea di comando come si fa con un webserver sotto.
Bye.

 linea di comando come si fa con un webserver sotto.
ehm, non ho capito.

 ehm, non ho capito.
Quando usi PHP con un webserver puoi installare una cache dei precompilati 
(eAccelerator, TurckMMCache e simili) che mantengono in cache appunto i 
precompilati, evitando di doverli compilare ad ogni chiamata, e 
incrementando cosi` le prestazioni anche di 10 volte.
Via linea di comando non mi pare si possa fare, quindi se richiami i tuoi 
script semplicemente con un exec("php nomescript.php"); (o con system()) 
vengono prima compilati, e poi eseguiti, ogni volta.
L'alternativa e` appunto quella di fare un unico script php (che compili 
all'avvio) dove forki (con pcntl_fork()) i vari figli che si collegano ai 
siti e fanno parsing delle pagine.
Ti consiglio di usare PHP5, che ha migliorato molto il garbage collector 
rispetto al 4.
Bye.

 rispetto al 4.
farollo , se me ne daranno la possibilitŕ
grazie mille degli utili consigli
Andrea
ps: ma "forkare" c'č nel dizionario? :)

 ps: ma "forkare" c'è nel dizionario? :)
Non credo, ma se gli americani ci mettono "w00t" (con gli zeri...) noi 
possiamo metterci "forkare" :)
Io forko, tu forki, ... se noi forkassimo, voi forkereste, ... :D
Bye.

 
Se quello che vuoi fare è uno spider, e se vuoi le massime prestazioni, 
la soluzione è usare il multiprocesso (ma con *pochi* processi per 
macchina) e la programmazione asincrona.
Il tutto dipende anche da quanto dispendiosi sono i calcoli che devi fare 
sui record scaricati.
Se non sono dispendiosi io farei così:
1) HTTP GET asincrono del record
2) parsing ed elaborazione dei dati (in modalità sincrona)
3) INSERT asincrona verso il database 
   (che io sappia solo PostgreSQL offre una API asincrona, per MySQL
    dovrai usare un pool di thread)
Probabilmente, se hai una concorrenza molto alta, vorrai limitare il 
numero di connessioni concorrenti al database, creando un pool di 
connessioni.
Tutti questi passi, ovviamente, li fai compiere in parallelo dai N 
processi.
Se invece il punto 2) è dispensioso allora:
1) Crei un process pool in cui girano i processi lavoratori che fanno
   il parsing ed elaborazione dei dati
2) HTTP GET asincrono del record
3) comunicazione asincrona via pipe con i processi lavoratori
4) INSERT asincrona verso il database
Ovviamente non è una cosa che scrivi dall'oggi al domani (specialmente la 
seconda soluzione, la prima è più semplice)...
Probabilmente ti semplifichi la vita se usi sqlite (ma usa un lock per la 
scrittura, potresti avere problemi se usi più di un processo).
Tieni conto che se il codice lo scrivi bene, probabilmente raggiungerai 
un alto livello di concorrenza usando un solo processo (sempre nella 
prima ipotesi).
Manlio Perillo

 possiamo metterci "forkare" :)
Vedo che non sono l'unico lettore di slashdot :)

 
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   Registered Linux user #337974  < 
http://giovanni.homelinux.net/
 >

 "fare dei test", ma fare testamento!
Ti sbagli, una delle accezioni riconosciute di "testare" è proprio quella
di "to test": 
Lemma: testare
Etimologia: Deriv. di test, sul modello dell'ingl. to test
Definizione: v. tr. [io tèsto ecc.] in diversi linguaggi tecnici,
sottoporre a un test: testare un soggetto, un candidato | esaminare,
verificare, collaudare: testare un programma all'elaboratore.
[
http://www.garzantilinguistica.it/interna_ita.html?sinonimi=0&exact=true&parola=76499
]
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 di "to test": 
Si, da quando gli ignoranti pretendono di parlare italiano.


 Si, da quando gli ignoranti pretendono di parlare italiano.
No, da quando le lingue vengono contaminate. Cioè da sempre. E da quando i
dizionari contemplano certi verbi. Come già detto: informati.
L'ignoranza non c'entra. Altrimenti smetti pure di dire sport, bar e
garage.
