Io uso multiprocessing.dummy.Pool
. Creo un pool di thread singleton a livello di modulo e quindi utilizzo pool.apply_async(requests.get, [params])
per avviare l'attività.
Questo comando mi dà un futuro, che posso aggiungere a un elenco con altri futuri a tempo indeterminato fino a quando non desidero raccogliere tutti o alcuni dei risultati.
multiprocessing.dummy.Pool
è, contro tutta la logica e la ragione, un pool di THREAD e non un pool di processi.
Esempio (funziona sia in Python 2 e 3, fino a quando è installato richieste):
from multiprocessing.dummy import Pool
import requests
pool = Pool(10) # Creates a pool with ten threads; more threads = more concurrency.
# "pool" is a module attribute; you can be sure there will only
# be one of them in your application
# as modules are cached after initialization.
if __name__ == '__main__':
futures = []
for x in range(10):
futures.append(pool.apply_async(requests.get, ['http://example.com/']))
# futures is now a list of 10 futures.
for future in futures:
print(future.get()) # For each future, wait until the request is
# finished and then print the response object.
Le richieste saranno eseguiti contemporaneamente, in modo da correre tutti e dieci di queste richieste non dovrebbe richiedere più la più lunga uno. Questa strategia utilizzerà solo un core della CPU, ma questo non dovrebbe essere un problema, perché quasi tutto il tempo sarà trascorso in attesa di I/O.
fonte
2014-11-19 17:05:10
A differenza di problemi di concorrenza legati alla CPU in Python, questo potrebbe essere possibilmente risolte con un thread separato, o l'uso di 'multiprocessing.dummy' per un pool di thread . –