2012/6/19 michele boscolo [email protected]:
Ciao, mi ha incuriosito quello che hai detto, mi potresti fare un
piccolo codice d’esempio su come far comunicare diversi processi tra
loro??
DRb facilissimo:
server.rb
require ‘drb’
crea una classe, magari usando delle strutture dati sensate 
QueueManager = Struct.new :queued, :visited do
def next_url
queued.shift
end
def save url, content, new_links
p “#$0: saving visited #{url}”
visited << [url, content]
self.queued = new_links + queued
end
end
rendila distribuita
DRb.start_service nil, QueueManager.new([‘origin’], [])
stampa lo uri di bind
puts DRb.uri
#loop forever
DRb.thread.join
…
#client.rb
require ‘drb’
connettiti allo uri passato da command line
queue_manager = DRbObject.new nil, ARGV.shift
#implementa la tua logica
def visit url
sleep rand(5)
p “#$0: visiting #{url}”
[‘some content’, [rand.to_s, ‘new_links’]]
end
gira in eterno, invocando i metodi remoti come se fosser locali
while true
url = queue_manager.next_url
queue_manager.save(url, *visit(url))
end
…
Se vuoi gestire errori/retry/politeness/priority… diventa pi complicato
E poi volevo un vostro parere, su cosa sia pi performante tra il
lanciare diversi processi che eseguono particolari parti di codice pi
lento tipo IO lento, oppure usare i Thread oppure ancora usare un
sistema come Eventmachine che fa uso dei Fiber??
Evented io, quindi event machine o simili, perch rischi spesso che un
thread/processo si piombi ad aspettare su una connessione di rete, e
generalmente avere 1000+ thread o processi pesantuccio. Ma neanche
cos tanto, con i computer attuali.
In compenso non scali a pi macchine… in quel caso, N processi
fetcher tutti con event loop, e un master controller che fa
distribuzione dei task secondo me la soluzione “giusta”.
In generale la cosa che ti migliora un sacco le prestazioni mettere
una cache per il dns
In altre parole vorrei sapere, secondo voi quale sia la strada migliore
da intraprendere per un’applicativo, con molto IO, quindi tempi d’attesa
lunghi, non mi interessa il fatto che debba gestire molte connessioni
contemporaneamente, deve solo eseguire una serie di operazioni nel minor
tempo possibile, e che dia la possibilit di gestire gli errori in caso
ce ne fossero.
pi connessioni rendono pi efficiente l’uso della banda, e gestire
gli errori pi facile in un single thread, single process.
Il problema se puoi farlo con le librerie che usi, e.g. se puoi
fetchare l’html con typheous e poi passarlo al motore webkit come
stringa, allora direi fai quello.
–
twitter: @riffraff
blog (en, it): www.riffraff.info riffraff.blogsome.com
work: circleme.com