¿Cuánto tiempo puede funcionar un trabajo de cron de PHP para/lo estoy haciendo bien?

Question

He creado un raspador php/mysql, que está funcionando bien, y no tengo idea de cómo ejecutarlo más eficientemente como un trabajo cron.

Hay 300 sitios, cada uno con entre 20 y 200 páginas raspadas. Se necesitan entre 4 y 7 horas para raspar todos los sitios (dependiendo de la latencia de la red y otros factores). El raspador necesita hacer una carrera completa una vez al día.

¿Debo ejecutar esto como 1 trabajo cron que se ejecuta durante las 4 a 7 horas completas, o ejecutarlo cada hora 7 veces, o ejecutarlo cada 10 minutos hasta que se complete?

El guión está configurado para ejecutarse desde el cron como esto:

while($starttime+600 > time()){ 
    do_scrape(); 
} 

la que se ejecutará la función do_scrape(), que raspa 10 URL a la vez, hasta que (en este caso) 600 segundos tiene pasado. El do_scrape puede tardar entre 5 y 60 segundos en ejecutarse.

Pregunto aquí, ya que no puedo encontrar información en la web sobre cómo ejecutar esto, y soy cauteloso acerca de cómo hacerlo funcionar diariamente, ya que php isnt realmente diseñado para ejecutarse como un solo script durante 7 horas.

Lo escribí en vainilla PHP/mysql, y se está ejecutando en VFA debian reducido con solo lighttpd/mysql/php5 instalado. Lo he ejecutado con un tiempo de espera de 6000 segundos (100 minutos) sin ningún problema (el servidor no se cayó).

Se agradece cualquier consejo sobre cómo realizar esta tarea. ¿Qué debería estar cuidando, etc.? o ¿voy a ejecutar todo esto mal?

Gracias!

Answer 1

No hay nada de malo en ejecutar un script PHP bien escrito durante largos períodos. Tengo algunos scripts que literalmente han estado funcionando continuamente durante meses. Solo observa el uso de tu memoria, y deberías estar bien.

Dicho esto, su arquitectura es bastante básica, y es muy poco probable que se escala.

Puede considerar pasar de una gran secuencia de comandos monolítica a una estrategia de dividir y vencer. Por ejemplo, parece que su script está haciendo solicitudes síncronas para cada URL. Si eso es cierto, entonces la mayor parte de ese tiempo de ejecución de 7 horas se usa ociosamente esperando una respuesta de algún servidor remoto.

En un mundo ideal, no escribiría este tipo de cosas PHP. Algún lenguaje que maneje hilos y pueda hacer fácilmente peticiones http asincrónicas con devolución de llamada sería mucho más adecuado.

Dicho esto, si estuviera haciendo esto en PHP, me gustaría tener un guión que patee a N niños que toman datos de URL, y pegan los datos de respuesta en algún tipo de cola de trabajo, y luego otra script que prácticamente se ejecuta todo el tiempo, procesando cualquier trabajo que encuentre en la cola.

Luego, cronifica su gestor de script fetcher para que se ejecute una vez por hora, gestiona algunos procesos de trabajo que recogen los datos (en parellel, para que la latencia no lo mate) y pegue el trabajo en la cola.Luego, el quechua-cruncher ve el trabajo en la cola y lo cruje.

Dependiendo de cómo implemente la cola, esto podría escalar bastante bien. Puede tener varias casillas de búsqueda de datos remotos y pegarlas en una cola central (con una cola implementada en mysql, o memcache, o lo que sea). Incluso es posible que tenga varias cajas que saquen trabajo de la cola y hagan el trabajo.

Por supuesto, el demonio está en los detalles, pero este diseño es generalmente más escalable y, por lo general, más robusto que una secuencia de comandos de búsqueda simple de proceso de repetición.

Answer 2

No debería tener problemas para ejecutarlo una vez al día hasta su finalización. Esa es la forma en que lo haría. Los tiempos de espera son un gran problema si php se sirve a través de un servidor web, pero como está interpretando directamente a través del ejecutable php, está bien. Sin embargo, te aconsejaría que uses Python u otra cosa que sea más amigable para las tareas.