[pyar] Limitando size del input Queue de multiprocessing.Pool

[Andres Riancho]

Esa no es una mala idea! Serializar los parametros a disco seria
posible ya que tambien tienen que ser serializables para entrar en una
multiprocessing.Queue... hmmm... lo agrego a mi lista de cosas a
probar.

La gente de scrapy tiene una implementacion [0] de una queue que se
guarda en disco. Y aca [1] hay otra que tiene un cache para no ir a
disco cada vez que se hace put/get.

Nota: en realidad estoy usando el ThreadPool de multiprocessing, por
lo que no seria tanto problema reemplazar el Queue de entrada que
utiliza eso (que es un simple Queue y no un multiprocessing.Queue) con
alguna de estas opciones

[0] https://pypi.python.org/pypi/queuelib
[1] http://code.activestate.com/recipes/501154-persistent-queue/

2014-04-07 20:01 GMT-03:00 Ezequiel Brizuela [aka EHB or qlixed]
<qlixed en gmail.com>:
> Respecto al tema de limitar el tamaño de la cola, no te sirve limitar la
> cola en memoria "tirando" el resto a disco? Si el pool es siempre para la
> misma funcion solo deberias serializar los parametros....
>
> El abr 7, 2014 6:45 PM, "Andres Riancho" <andres.riancho en gmail.com>
> escribió:
>
>> Uy, se torno algo interesante finalmente mi post :) Les tiro algunas
>> cosas extras y comentarios sobre todos los mails anteriores:
>>
>>  * Disclaimer: La pregunta no es especifica de w3af, pero la estoy
>> haciendo debido a que mi problema se encuentra en ese software. De
>> todas maneras, es un problema que posiblemente se encuentren otros
>> cuando empiecen a mandar muchas tareas a un multiprocessing.Pool
>>
>>  * Se dijo en uno de los emails: "Creo q estas tratando de hacer una
>> especie de ratelimit sobre la creacion de procesos", no, ojo que esto
>> es un multiprocessing.Pool, y no hay creacion de nuevos procesos
>> (salvo que alguno del pool se muera). Lo que estoy intentando limitar
>> es la cantidad de tareas que quedan encoladas, esperando ser
>> procesadas por el pool.
>>
>>  * Una de las partes de w3af que más abusa de encolar nuevas tareas en
>> el Pool, corriendo desde un worker es el web_spider [0], más
>> especificamente el metodo _extract_links_and_verify [1]
>>
>>  * En el codigo de w3af lo que ocurre en general es que el core llama
>> al web_spider con una URL, el spider hace un GET a la URL, parsea el
>> response body, y para cada una de las URLs nuevas verifica a ver si es
>> un 404 o no (usando el Pool). En caso de que esa URL NO sea un 404, la
>> misma se envia nuevamente al core para continuar con su procesamiento.
>>
>>     Continuar con su procesamiento significa que ocurre nuevamente lo
>> mismo, el core envia la URL al plugin de web_spider, se encuentran
>> links, etc. El core desde el main thread va mandando tareas al pool,
>> que corre los plugins.
>>
>>     Al menos en esta parte del codigo, solo tengo "1 nivel de
>> funciones de multiprocessing.Pool" anidadas.
>>
>>  * Hice una prueba rapida con un limite de 500 en el Queue, no obtuve
>> problemas mayores... pero todavia me falta hacer mucho más testing.
>>
>>  * Mientras que escribia esta respuesta se me cruzo por la mente el
>> RLock [2], quizás estaría bueno tener algo de ese estilo pero para la
>> queue de entrada del Pool? Es decir, si el queue esta lleno y quiero
>> encolar una tarea desde dentro de otra tarea: me lo permite, pero si
>> quiero encolarla desde el main thread no me lo permite. De esa forma
>> podria evitar los dead-locks. No se si existe... pero es lo que se me
>> cruzo por la mente.
>>
>> [0]
>> https://github.com/andresriancho/w3af/blob/master/w3af/plugins/crawl/web_spider.py
>> [1]
>> https://github.com/andresriancho/w3af/blob/master/w3af/plugins/crawl/web_spider.py#L199
>> [2] https://docs.python.org/2/library/threading.html#threading.RLock
>>
>> 2014-04-07 12:53 GMT-03:00 Claudio Freire <klaussfreire en gmail.com>:
>> > 2014-04-07 10:40 GMT-03:00 Alejandro Santos <listas en alejolp.com>:
>> >>> No es exactamente lo mismo, y para páginas web, con un alto índice de
>> >>> conectividad, la anchura puede ser considerable.
>> >>>
>> >>> También, pensándolo mientras escribo esta respuesta... ¿deduplicás los
>> >>> links antes de meterlos en la cola?
>> >>>
>> >>
>> >> Disclaimer: no tengo nada que ver con W3AF, solamente me resulto
>> >> atractivo el problema :)
>> >>
>> >> (y en algun momento hace muchos a;os use w3af y me parecio una
>> >> herramienta interesante)
>> >
>> >
>> > No entiendo.
>> >
>> > Del thread, me dio la impresión que lo que hacías era similar a un
>> > crawler.
>> >
>> > ¿Qué hacés realmente que genera un grafo tan ancho que no te entra en
>> > memoria?
>> > _______________________________________________
>> > pyar mailing list pyar en python.org.ar
>> > http://listas.python.org.ar/listinfo/pyar
>> >
>> > PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>> >
>> > La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
>> > Argentina - http://www.usla.org.ar
>>
>>
>>
>> --
>> Andrés Riancho
>> Project Leader at w3af - http://w3af.org/
>> Web Application Attack and Audit Framework
>> Twitter: @w3af
>> GPG: 0x93C344F3
>> _______________________________________________
>> pyar mailing list pyar en python.org.ar
>> http://listas.python.org.ar/listinfo/pyar
>>
>> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>>
>> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
>> Argentina - http://www.usla.org.ar
>
>
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar



-- 
Andrés Riancho
Project Leader at w3af - http://w3af.org/
Web Application Attack and Audit Framework
Twitter: @w3af
GPG: 0x93C344F3