Aleternativas a timeLimit() para bucles
Jimmy Collazos || acido || cuatroxl.com
Tengo un script para el envío de newsletters; hasta ahora todo parecía correcto.
El problema es que la base de datos ya tiene más de 68 000 usuarios. Por lo que a la hora de enviar los email el programa no funciona.
En principio mi solución pasaba por aumentar el tiempo de ejecución en el php ( set_time_limit() ) pero, por gracia divina, tengo a un supuesto técnico de sistemas que me dice que es imposible habilitar esa posibilidad
No sé muy bien como podría tratar esto, creo que tengo que enviar los emails por bloques pero no estoy muy lucido hoy.
Si alguno a tenido algún problema similar, encantado de escuchar ideas.
--
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:::::::::::::::: J i m m y C o l l a z o s :::::::::::::::::::::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
desarrollado web; estándar, accesible, escalable
----------------------------------------------------------------------------
acido69
Eduard Llach
Por mi parte una alternativa "cutre" que he encontrado y me ha funcionado es ir "recargando" la página via javascript y haciendo paginación
$registros = 500
$pagina = ( array_key_exists('pagina',$_GET) ) ? $_GET['pagina'] : 1;
$registro = $registros * ($pagina-1);
$SQL = "...... LIMIT $registro, $registros";
/** procesar envío de correos **/
$pagina++;
echo( "<html><body><script type=\"text/javascript\">window.location.href='script.php?pagina={$pagina}';</script><p>procesando página {$pagina}</p></body></hrml>" );
Y eso me va dando de 30 segundos en 30 segundos.
--
Has recibido este mensaje porque estás suscrito al grupo "Grupo de programadores PHP de Barcelona" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a phpbar...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a phpbarcelona...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/phpbarcelona?hl=es.
--
Eduard Llach
warper
http://php.net/manual/en/function.usleep.php
Saludos
jan
Eduard Llach escribió:
Juanjo López Mellado
Entiendo que lo haces por cron, ¿no?
Seguro que hay una solución mucho mejor, pero a bote pronto se me ocurre el envío por bloques
como bien dices. Me faltan datos, pero supon que en cada ejecución puedes enviar unos 20.000
emails, lo cual te obliga a ejecutar el script en 4 tandas.
Debes buscar alguna forma de segmentar tu lista de emails en 4 partes más o menos iguales. Falta
probarlo pero podrías utilizar la primera letra del email. En la 1a. tanda envías los emails que comiencen
por a, b, c, d por ejemplo, en la segunda los que lo hagan por e, f, g, ... bueno, ya lo pillas.
Si lo haces en 5 ó 6 tandas y no vas a ajustar los 20.000 por cada tanda, puedes tener un sistema
que te dure bastante tiempo.
Si no te quieres matar en esos cálculos entonces puedes hacer un ORDER BY de los emails e ir
cogiéndolos de 15.000 en 15.000 con un LIMIT. (Presupongo MySQL, espero que se entienda).
KISS total :-D
Espero haberte ayudado.
--
Has recibido este mensaje porque estás suscrito al grupo "Grupo de programadores PHP de Barcelona" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a phpbar...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a phpbarcelona...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/phpbarcelona?hl=es.
--
Juanx
Informático de profesión y mejor persona :-D
No tengo "feisbuk", pero sí LinkedIn: http://www.linkedin.com/in/juanx
-- Si te gustan los coches visita mi desactualizado blog http://conplomo.blogspot.com --
Juanjo López Mellado
Oye. Se me ocurre que podrías juntar varias direcciones en el campo BCC y aprovechar un
envío para varios destinatarios, ¿no?
</ocurrencia>
warper
Es mejor uno a uno, aunque en caso de massmailing y errores es un poco pesado recibir y gestionar la baja en la lista de tropocientos emails devueltos.
Pero en cierta manera, a mi modo de ver, es la forma mas logica y correcta.
Salud
warper
Juanjo López Mellado escribió:
Juanjo López Mellado
Si pones un churro de emails en un BCC, CC o TO, corres el riesgo que algunos servidores no acepten el email, o lo demoren, por "Too much recipients".
Correcto. Pero no le dará el error por poner 3 receptores por email, y eso ya le permitiría
reducir de 68.000 envíos a 22.600, ¿no?
Ojo que lo digo sin conocimiento de causa, no me he encontrado en esta situación antes...
Si además agrupas los receptores por servidor (todos los de gmail juntos, todos los de yahoo
juntos, etc.) seguro que el envío va más rápido. Si envías por SMTP casi seguro que sí, si lo
haces por servidor local (sendmail, etc.) a lo mejor no se nota...
Saludos.
César Escribano
Si el técnico te ha dicho que es imposible usar set_time_limit(), será que tiene el sistema en safe_mode. Puedes intentar convencerle de que safe_mode es un modelo de seguridad obsoleto, que no se recomienda en PHP 5, que desaparecerá en PHP 6, etc
si no, podrías usar el método de recargar el formulario por javascript que comentaba Eduard. El componente Acajoom de Joomla lo hace así y va muy bien, además ir viendo el proceso de un envío tan grande es relajante :)
saludoss
César
Pablo
Pero lo ideal es que envies por bloques
-- mens. original --
Asunto: Re: Aleternativas a timeLimit() para bucles
De: César Escribano <ce...@anui.org>
Fecha: 16/03/2010 08:19
saludoss
César
>> <mailto:war...@gmail.com>> escribió:
>>
>> Yo uso el usleep() para estos casos.
>>
>> http://php.net/manual/en/function.usleep.php
>>
>> Saludos
>> jan
>>
>> Eduard Llach escribió:
>>> El set_time_limit si se puede tocar, pero corres el riesgo que
>>> cualquier script lo haga y, consecuentemente te "mate" el
>>> servidor, cosa especialmente grave si contiene sistemas de
>>> producción.
>>>
>>> Por mi parte una alternativa "cutre" que he encontrado y me ha
>>> funcionado es ir "recargando" la página via javascript y
>>> haciendo paginación
>>>
>>> $registros = 500
>>> $pagina = ( array_key_exists('pagina',$_GET) ) ?
>>> $_GET['pagina'] : 1;
>>> $registro = $registros * ($pagina-1);
>>> $SQL = "...... LIMIT $registro, $registros";
>>> /** procesar envío de correos **/
>>> $pagina++;
>>> echo( "<html><body><script
>>> type=\"text/javascript\">window.location.href='script.php?pagina={$pagina}';</script><p>procesando
>>> página {$pagina}</p></body></hrml>" );
>>>
>>> Y eso me va dando de 30 segundos en 30 segundos.
>>>
>>> 2010/3/16 Jimmy Collazos || acido || cuatroxl.com
>>> <http://cuatroxl.com> <aci...@gmail.com <mailto:aci...@gmail.com>>
>>>
>>> Hola, buenos días a todos.
>>>
>>> Tengo un script para el envío de newsletters; hasta ahora
>>> todo parecía correcto.
>>>
>>> El problema es que la base de datos ya tiene más de 68 000
>>> usuarios. Por lo que a la hora de enviar los email el
>>> programa no funciona.
>>>
>>> En principio mi solución pasaba por aumentar el tiempo de
>>> ejecución en el php ( /set_time_limit() /) pero, por gracia
>>> divina, tengo a un supuesto técnico de sistemas que me dice
>>> que es _imposible habilitar esa posibilidad_
>>>
>>> No sé muy bien como podría tratar esto, creo que tengo que
>>> enviar los emails por bloques pero no estoy muy lucido hoy.
>>>
>>> Si alguno a tenido algún problema similar, encantado de
>>> escuchar ideas.
>>>
>>>
>>>
>>>
>>> --
>>> ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
>>> :::::::::::::::: J i m m y C o l l a z o s
>>> :::::::::::::::::::::
>>> ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
>>> desarrollado web; estándar, accesible, escalable
>>> ----------------------------------------------------------------------------
>>>
>>> acido69
>>> --
>>> Has recibido este mensaje porque estás suscrito al grupo
>>> "Grupo de programadores PHP de Barcelona" de Grupos de Google.
>>> Para publicar una entrada en este grupo, envía un correo
>>> electrónico a phpbar...@googlegroups.com
>>> <mailto:phpbar...@googlegroups.com>.
>>> Para anular tu suscripción a este grupo, envía un correo
>>> electrónico a phpbarcelona...@googlegroups.com
>>> <mailto:phpbarcelona%2Bunsu...@googlegroups.com>
>>> Para tener acceso a más opciones, visita el grupo en
>>> http://groups.google.com/group/phpbarcelona?hl=es.
>>>
>>>
>>>
>>>
>>> --
>>> Eduard Llach
>>> --
>>> Has recibido este mensaje porque estás suscrito al grupo "Grupo
>>> de programadores PHP de Barcelona" de Grupos de Google.
>>> Para publicar una entrada en este grupo, envía un correo
>>> electrónico a phpbar...@googlegroups.com
>>> <mailto:phpbar...@googlegroups.com>.
>>> Para anular tu suscripción a este grupo, envía un correo
>>> electrónico a phpbarcelona...@googlegroups.com
>>> <mailto:phpbarcelona...@googlegroups.com>
>>> Para tener acceso a más opciones, visita el grupo en
>>> http://groups.google.com/group/phpbarcelona?hl=es.
>>
>> --
>> Has recibido este mensaje porque estás suscrito al grupo "Grupo
>> de programadores PHP de Barcelona" de Grupos de Google.
>> Para publicar una entrada en este grupo, envía un correo
>> electrónico a phpbar...@googlegroups.com
>> <mailto:phpbar...@googlegroups.com>.
>> Para anular tu suscripción a este grupo, envía un correo
>> electrónico a phpbarcelona...@googlegroups.com
>> <mailto:phpbarcelona%2Bunsu...@googlegroups.com>
--
Octavio Benedí Sánchez
final. Es una especie de recursividad, si se puede llamar así.
El concepto seria este:
1º Envías el email desde el punto de entrada inicial. Es decir
exactamente como lo estas haciendo ahora mismo. Un formulario, Cron,
lo que sea.
2º El script sabe cuantos mails puede enviar pongamos por ejemplo los
20.000 que han comentado previamente. Así que envías los 20.000 mails.
3º Si aún quedan mails por enviar después de los enviados en el punto
2, el script se relanza con un parámetro que le indique el punto por
el que va. Volviendo de este modo al punto 2.
Para relanzar el script, si estas en un entorno linux te recomiendo un
simple exec, derivado a /dev/null para que corra en background. Por
ejemplo algo así como:
exec('wget -O - "URL_del_script?start=20001" >/dev/null 2>&1 &');
De este modo no necesitas de un navegador para hacer que el script se
relance y no tienes que saber ni cuanto tiempo va a durar ni cuantas
entradas tienes que hacer, simplemente cada 20000 volvería a
iniciarse.
No es lo más elegante pero como han dicho antes es bastante KISS.
On 16 mar, 11:19, César Escribano <ce...@anui.org> wrote:
> no puedes enviar un bolet�n con varios destinatarios visibles en CC,
> porque estar�as revelando informaci�n a los dem�s destinatarios, y
> tampoco puedes usar BCC masivamente porque es muy f�cil que un sistema
> antispam te tire atr�s los mails, y en el peor de los casos te marque
> como spammer. Lo recomendable es enviar cada uno por separado y con el
> destinatario especificado en el To: (y otras cosas acerca del spam que
> no vienen al caso)
>
> Si el t�cnico te ha dicho que es imposible usar set_time_limit(), ser�
> que tiene el sistema en safe_mode. Puedes intentar convencerle de que
> safe_mode es un modelo de seguridad obsoleto, que no se recomienda en
> PHP 5, que desaparecer� en PHP 6, etc
>
> si no, podr�as usar el m�todo de recargar el formulario por javascript
> que comentaba Eduard. El componente Acajoom de Joomla lo hace as� y va
> muy bien, adem�s ir viendo el proceso de un env�o tan grande es relajante :)
>
> saludoss
>
> C�sar
>
> El 16/03/2010 10:54, warper escribi�:
>
>
>
> > Si pones un churro de emails en un BCC, CC o TO, corres el riesgo que
> > algunos servidores no acepten el email, o lo demoren, por "Too much
> > recipients".
>
> > Es mejor uno a uno, aunque en caso de massmailing y errores es un poco
> > pesado recibir y gestionar la baja en la lista de tropocientos emails
> > devueltos.
> > Pero en cierta manera, a mi modo de ver, es la forma mas logica y
> > correcta.
>
> > Salud
> > warper
>
> > Juanjo L�pez Mellado escribi�:
> >> <ocurrencia>
> >> Oye. Se me ocurre que podr�as juntar varias direcciones en el campo
> >> BCC y aprovechar un
> >> env�o para varios destinatarios, �no?
> >> </ocurrencia>
>
> >> El 16 de marzo de 2010 10:42, warper <war...@gmail.com
> >> <mailto:war...@gmail.com>> escribi�:
>
> >> Yo uso el usleep() para estos casos.
>
> >> http://php.net/manual/en/function.usleep.php
>
> >> Saludos
> >> jan
>
> >> Eduard Llach escribi�:
> >>> El set_time_limit si se puede tocar, pero corres el riesgo que
> >>> cualquier script lo haga y, consecuentemente te "mate" el
> >>> servidor, cosa especialmente grave si contiene sistemas de
> >>> producci�n.
>
> >>> Por mi parte una alternativa "cutre" que he encontrado y me ha
> >>> funcionado es ir "recargando" la p�gina via javascript y
> >>> haciendo paginaci�n
>
> >>> $registros = 500
> >>> $pagina = ( array_key_exists('pagina',$_GET) ) ?
> >>> $_GET['pagina'] : 1;
> >>> $registro = $registros * ($pagina-1);
> >>> $SQL = "...... LIMIT $registro, $registros";
> >>> /** procesar env�o de correos **/
> >>> $pagina++;
> >>> echo( "<html><body><script
> >>> type=\"text/javascript\">window.location.href='script.php?pagina={$pagina}' ;</script><p>procesando
> >>> p�gina {$pagina}</p></body></hrml>" );
>
> >>> Y eso me va dando de 30 segundos en 30 segundos.
>
> >>> 2010/3/16 Jimmy Collazos || acido || cuatroxl.com
> >>> <http://cuatroxl.com> <acid...@gmail.com <mailto:acid...@gmail.com>>
>
> >>> Hola, buenos d�as a todos.
>
> >>> Tengo un script para el env�o de newsletters; hasta ahora
> >>> todo parec�a correcto.
>
> >>> El problema es que la base de datos ya tiene m�s de 68 000
> >>> usuarios. Por lo que a la hora de enviar los email el
> >>> programa no funciona.
>
> >>> En principio mi soluci�n pasaba por aumentar el tiempo de
> >>> ejecuci�n en el php ( /set_time_limit() /) pero, por gracia
> >>> divina, tengo a un supuesto t�cnico de sistemas que me dice
> >>> que es _imposible habilitar esa posibilidad_
>
> >>> No s� muy bien como podr�a tratar esto, creo que tengo que
> >>> enviar los emails por bloques pero no estoy muy lucido hoy.
>
> >>> Si alguno a tenido alg�n problema similar, encantado de
> >>> escuchar ideas.
>
> >>> --
> >>> ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :
> >>> :::::::::::::::: J i m m y C o l l a z o s
> >>> :::::::::::::::::::::
> >>> ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :
> >>> desarrollado web; est�ndar, accesible, escalable
> >>> --------------------------------------------------------------------------- -
>
> >>> acido69
> >>> --
> >>> Has recibido este mensaje porque est�s suscrito al grupo
> >>> "Grupo de programadores PHP de Barcelona" de Grupos de Google.
> >>> Para publicar una entrada en este grupo, env�a un correo
> >>> electr�nico a phpbar...@googlegroups.com
> >>> <mailto:phpbar...@googlegroups.com>.
> >>> Para anular tu suscripci�n a este grupo, env�a un correo
> >>> electr�nico a phpbarcelona...@googlegroups.com
> >>> <mailto:phpbarcelona%2Bunsu...@googlegroups.com>
> >>> Para tener acceso a m�s opciones, visita el grupo en
> >>> http://groups.google.com/group/phpbarcelona?hl=es.
>
> >>> --
> >>> Eduard Llach
> >>> --
> >>> Has recibido este mensaje porque est�s suscrito al grupo "Grupo
> >>> de programadores PHP de Barcelona" de Grupos de Google.
> >>> Para publicar una entrada en este grupo, env�a un correo
> >>> electr�nico a phpbar...@googlegroups.com
> >>> <mailto:phpbar...@googlegroups.com>.
> >>> Para anular tu suscripci�n a este grupo, env�a un correo
> >>> electr�nico a phpbarcelona...@googlegroups.com
> >>> <mailto:phpbarcelona...@googlegroups.com>
> >>> Para tener acceso a m�s opciones, visita el grupo en
> >>> http://groups.google.com/group/phpbarcelona?hl=es.
>
> >> --
> >> Has recibido este mensaje porque est�s suscrito al grupo "Grupo
> >> de programadores PHP de Barcelona" de Grupos de Google.
> >> Para publicar una entrada en este grupo, env�a un correo
> >> electr�nico a phpbar...@googlegroups.com
> >> <mailto:phpbar...@googlegroups.com>.
> >> Para anular tu suscripci�n a este grupo, env�a un correo
> >> electr�nico a phpbarcelona...@googlegroups.com
> >> <mailto:phpbarcelona%2Bunsu...@googlegroups.com>
> >> Para tener acceso a m�s opciones, visita el grupo en
> >> http://groups.google.com/group/phpbarcelona?hl=es.
>
> >> --
> >> Juanx
> >> Inform�tico de profesi�n y mejor persona :-D
> >> No tengo "feisbuk", pero s� LinkedIn:http://www.linkedin.com/in/juanx
> >> -- Si te gustan los coches visita mi desactualizado blog
> >>http://conplomo.blogspot.com--
>
> >> --
> >> Has recibido este mensaje porque est�s suscrito al grupo "Grupo de
> >> programadores PHP de Barcelona" de Grupos de Google.
> >> Para publicar una entrada en este grupo, env�a un correo electr�nico
> >> a phpbar...@googlegroups.com.
> >> Para anular tu suscripci�n a este grupo, env�a un correo electr�nico
> >> a phpbarcelona...@googlegroups.com
> >> Para tener acceso a m�s opciones, visita el grupo en
> >>http://groups.google.com/group/phpbarcelona?hl=es.
>
> > --
> > Has recibido este mensaje porque est�s suscrito al grupo "Grupo de
> > programadores PHP de Barcelona" de Grupos de Google.
> > Para publicar una entrada en este grupo, env�a un correo electr�nico a
> > phpbar...@googlegroups.com.
> > Para anular tu suscripci�n a este grupo, env�a un correo electr�nico a
> > phpbarcelona...@googlegroups.com
> > Para tener acceso a m�s opciones, visita el grupo en
> >http://groups.google.com/group/phpbarcelona?hl=es.
Pablo Pazos
Has recibido este mensaje porque estás suscrito al grupo "Grupo de programadores PHP de Barcelona" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a phpbar...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a phpbarcelona...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/phpbarcelona?hl=es.
--
Atte.
A/C Pablo Pazos Gutierrez
Sitio: http://sites.google.com/site/pablopazosgutierrez/
Blog: http://informatica-medica.blogspot.com/
Sígueme en twitter: http://twitter.com/ppazos
César Escribano
Jimmy, ¿tu script se ejecuta desde el navegador o desde consola? ¿es una tarea periódica o manual? ¿el módulo PHP del servidor está en safe_mode? ¿podrías crear tareas cron? ¿envías los emails por smtp o van directamente al sendmail local?
saludos,
César
pablof...@gmail.com
php.net/set_time_limit es suficiente.
Lo de recursividad es increbilemente bestial, pero con todas las letras.
Lo que dice Pablo Pazos me parece una buena opcion, hacer un deamon en
python no es muy dificil y de paso aprendes un poco sobre python.
Te cuento un poco como uso yo generalmente los mails.
Me paso en varios proyectos que tengo una cantidad de mails, de
reportes, de registracion, de cambio de clave, de alta de productos,
de muchos etc.
Esperar mientras la funcion de mail de php procesa los mails es
realmente tedioso y consume muchos recuros.
Lo que implemente en varios proyectos en produccion. es encolar en una
cola de ActiveMq, o ahora uso Amazon SQS, un objeto json con todas las
propiedades del mail.
to: from, subject, smartyTemplateName, properties, si quiero algun
header especifico, o un body plano.
Esto se encola todo, y cada un minuto corre un cron que lee esa cola y
desencola de a x cantidad. Y se encarga de enviarlos por ejemplo 100,
en este caso el sistema esta capacitado para enviar hasta 144000 mails
por dia, si necesitas mas bueno aumentas el limite de 100 a 200 o a lo
que quieras..
El sistema es muy simple, de hecho si te interesa te puedo pasar las librerias.
En mi caso uso Smarty, Zend Framework para el envio de mails, y la
interfaz para las colas,
Pero vos podes encolar en la base de datos si te interesa.
On 3/16/10, César Escribano <ce...@anui.org> wrote:
> de todas formas aun no tenemos muy claro cómo lo lanza ni en qué entorno,
>
> Jimmy, ¿tu script se ejecuta desde el navegador o desde consola? ¿es una
> tarea periódica o manual? ¿el módulo PHP del servidor está en safe_mode?
> ¿podrías crear tareas cron? ¿envías los emails por smtp o van
> directamente al sendmail local?
>
>
> saludos,
>
> César
>
>
>
> El 16/03/2010 15:01, Pablo Pazos escribió:
>> Buenas,
>>
>> Revisando los mails veo muchas alternativas para hacer que PHP haga lo
>> que necesitas, pero tal vez PHP en este caso no sea la mejor opción.
>> PHP es bueno cuando las cosas se ejecutan de forma request/response,
>> pero cuando hay grandes procesamientos como este (ya he tenido que
>> hacerlo y siempre termino en cómo modificarle el timeout al PHP) sería
>> mejor opción usar algo que no dependa del timeout, por ejemplo un
>> proceso Java, que puedes lanzar, quedar coriendo por horas enviando
>> mails y terminar sin problemas.
>>
>> Saludos,
>> Pablo Pazos.
>> http://code.google.com/p/yupp
>>
>> 2010/3/16 Octavio Benedí Sánchez <octavi...@gmail.com
>> <mailto:octavi...@gmail.com>>
>>
>> Y si lo que haces es que el propio script php se llame a si mismo al
>> final. Es una especie de recursividad, si se puede llamar así.
>>
>> El concepto seria este:
>>
>> 1º Envías el email desde el punto de entrada inicial. Es decir
>> exactamente como lo estas haciendo ahora mismo. Un formulario, Cron,
>> lo que sea.
>> 2º El script sabe cuantos mails puede enviar pongamos por ejemplo los
>> 20.000 que han comentado previamente. Así que envías los 20.000 mails.
>> 3º Si aún quedan mails por enviar después de los enviados en el punto
>> 2, el script se relanza con un parámetro que le indique el punto por
>> el que va. Volviendo de este modo al punto 2.
>>
>> Para relanzar el script, si estas en un entorno linux te recomiendo un
>> simple exec, derivado a /dev/null para que corra en background. Por
>> ejemplo algo así como:
>>
>> exec('wget -O - "URL_del_script?start=20001" >/dev/null 2>&1 &');
>>
>> De este modo no necesitas de un navegador para hacer que el script se
>> relance y no tienes que saber ni cuanto tiempo va a durar ni cuantas
>> entradas tienes que hacer, simplemente cada 20000 volvería a
>> iniciarse.
>>
>> No es lo más elegante pero como han dicho antes es bastante KISS.
>>
>> On 16 mar, 11:19, César Escribano <ce...@anui.org
>> > >> <mailto:war...@gmail.com <mailto:war...@gmail.com>>> escribi�:
>> <mailto:acid...@gmail.com> <mailto:acid...@gmail.com
>> > >>> <mailto:phpbar...@googlegroups.com
>> <mailto:phpbar...@googlegroups.com>>.
>> > >>> Para anular tu suscripci�n a este grupo, env�a
>> un correo
>> > >>> electr�nico a
>> phpbarcelona...@googlegroups.com
>> <mailto:phpbarcelona%2Bunsu...@googlegroups.com>
>> > >>> <mailto:phpbarcelona%2Bunsu...@googlegroups.com
>> <mailto:phpbarcelona%252Buns...@googlegroups.com>>
>> > >>> Para tener acceso a m�s opciones, visita el grupo en
>> > >>> http://groups.google.com/group/phpbarcelona?hl=es.
>> >
>> > >>> --
>> > >>> Eduard Llach
>> > >>> --
>> > >>> Has recibido este mensaje porque est�s suscrito al
>> grupo "Grupo
>> > >>> de programadores PHP de Barcelona" de Grupos de Google.
>> > >>> Para publicar una entrada en este grupo, env�a un correo
>> > >>> electr�nico a phpbar...@googlegroups.com
>> <mailto:phpbar...@googlegroups.com>
>> > >>> <mailto:phpbar...@googlegroups.com
>> <mailto:phpbar...@googlegroups.com>>.
>> > >>> Para anular tu suscripci�n a este grupo, env�a un correo
>> > >>> electr�nico a
>> phpbarcelona...@googlegroups.com
>> <mailto:phpbarcelona%2Bunsu...@googlegroups.com>
>> > >>> <mailto:phpbarcelona...@googlegroups.com
>> <mailto:phpbarcelona%2Bunsu...@googlegroups.com>>
>> > >>> Para tener acceso a m�s opciones, visita el grupo en
>> > >>> http://groups.google.com/group/phpbarcelona?hl=es.
>> >
>> > >> --
>> > >> Has recibido este mensaje porque est�s suscrito al
>> grupo "Grupo
>> > >> de programadores PHP de Barcelona" de Grupos de Google.
>> > >> Para publicar una entrada en este grupo, env�a un correo
>> > >> electr�nico a phpbar...@googlegroups.com
>> <mailto:phpbar...@googlegroups.com>
>> > >> <mailto:phpbar...@googlegroups.com
>> <mailto:phpbar...@googlegroups.com>>.
>> > >> Para anular tu suscripci�n a este grupo, env�a un correo
>> > >> electr�nico a phpbarcelona...@googlegroups.com
>> <mailto:phpbarcelona%2Bunsu...@googlegroups.com>
>> > >> <mailto:phpbarcelona%2Bunsu...@googlegroups.com
>> <mailto:phpbarcelona%252Buns...@googlegroups.com>>
>> > >> Para tener acceso a m�s opciones, visita el grupo en
>> > >> http://groups.google.com/group/phpbarcelona?hl=es.
>> >
>> > >> --
>> > >> Juanx
>> > >> Inform�tico de profesi�n y mejor persona :-D
>> > >> No tengo "feisbuk", pero s�
>> LinkedIn:http://www.linkedin.com/in/juanx
>> > >> -- Si te gustan los coches visita mi desactualizado blog
>> > >>http://conplomo.blogspot.com--
>> >
>> > >> --
>> > >> Has recibido este mensaje porque est�s suscrito al grupo
>> "Grupo de
>> > >> programadores PHP de Barcelona" de Grupos de Google.
>> > >> Para publicar una entrada en este grupo, env�a un correo
>> electr�nico
>> > >> a phpbar...@googlegroups.com
>> <mailto:phpbar...@googlegroups.com>.
>> > >> Para anular tu suscripci�n a este grupo, env�a un correo
>> electr�nico
>> > >> a phpbarcelona...@googlegroups.com
>> <mailto:phpbarcelona%2Bunsu...@googlegroups.com>
>> > >> Para tener acceso a m�s opciones, visita el grupo en
>> > >>http://groups.google.com/group/phpbarcelona?hl=es.
>> >
>> > > --
>> > > Has recibido este mensaje porque est�s suscrito al grupo
>> "Grupo de
>> > > programadores PHP de Barcelona" de Grupos de Google.
>> > > Para publicar una entrada en este grupo, env�a un correo
>> electr�nico a
>> > > phpbar...@googlegroups.com
>> <mailto:phpbar...@googlegroups.com>.
>> > > Para anular tu suscripci�n a este grupo, env�a un correo
>> electr�nico a
>> > > phpbarcelona...@googlegroups.com
>> <mailto:phpbarcelona%2Bunsu...@googlegroups.com>
>> > > Para tener acceso a m�s opciones, visita el grupo en
>> > >http://groups.google.com/group/phpbarcelona?hl=es.
>>
>> --
>> Has recibido este mensaje porque estás suscrito al grupo "Grupo de
>> programadores PHP de Barcelona" de Grupos de Google.
>> Para publicar una entrada en este grupo, envía un correo
>> electrónico a phpbar...@googlegroups.com
>> <mailto:phpbar...@googlegroups.com>.
>> Para anular tu suscripción a este grupo, envía un correo
>> electrónico a phpbarcelona...@googlegroups.com
>> <mailto:phpbarcelona%2Bunsu...@googlegroups.com>
--
----------------------------------------
Pablo Morales
blog: http://blog.pablo-morales.com
linkedln: http://www.linkedin.com/pub/9/528/21
skype: pablofmorales
gtalk: pablof...@gmail.com
msn: pfm...@hotmail.com
César Escribano
Es más, si tiene PHP en safe_mode, no creo que le permitan hacer nada en consola ni lanzar procesos
saludos
pablof...@gmail.com
nativa de php, por la cual no hay que avisarle nada al sysadmin, o la
directiva del php.ini me parecio mas logico que el sysadmin no quiera
cambiar una directiva.
Jimmy Collazos || acido || cuatroxl.com
perdón por contestar tan tarde; ya que soy el interesado pero un marrón a caído del cielo :(
La situación es la siguiente:
Tengo un CMS; en el pueden redactar el newsletter y una vez terminado; tiene la opción de guardarlo o enviarlo.
en un princio esto funcionaba bien; pero parece que en un par de meses el número de usuarios a crecido bestialmente; más de 68mil
Por lo que a la hora de darle a enviar emails; se queda cargando y al cabo de unos segundos te pinta una página en blanco.
Como bien dije; utilizar Set_time_limit() es imposible.
Creo que la opción de utilizar ajax y enviar los mails en grupos de 1000 (por ejemplo) es la única medianamente valida que tengo.
Aunque me preocupa que un fallo en la conexión o algo ponga en peligro el envio y no le llegue a todo el mundo.
Y todo esto gracias al administrador iluminado.....
--
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:::::::::::::::: J i m m y C o l l a z o s :::::::::::::::::::::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
César Escribano
También podrías utilizar una columna en la tabla de suscriptores, para marcar si se le ha enviado el boletín, o directamente el identificador del ultimo boletín que se le envió. Así, si te ves obligado a repetir el envío, te saltas esos y ya está.
Esto es lo que hace Acajoom (entre otras cosas) y nunca he tenido problemas
saludos
César
Octavio Benedí Sánchez
parece bestial?
Te detallo un poco más como funciona esta aproximación y sus
cualidades y espero tus críticas constructivas.
Lo único que hace es utilizar una opción del sistema para partir la
ejecución de un script php muy largo en varios trozos.
El sistema es tan seguro como lo sea una única ejecución. Evitar más
de una instancia al mismo tiempo o control de usuarios entiendo que
van incorporados, así como cualquier medida de seguridad que tenga el
script inicial de Jimmy.
Lo que hace mi solución es partir un script demasiado largo (en
tiempo) en varios pedazos. Además nada más lanzar la ejecución del
siguiente pedazo la parte anterior muere liberando completamente la
memoria luego nunca vas a ocupar más memoria que la que ocupa un solo
pedazo de ejecución.
Por otro lado esta solución puede implementarse en entornos donde
puedes ejecutar comandos shell en un entorno chrooteado pero no tienes
acceso a un sistema cron o similar, que son muchos.
Otra ventaja es que si estas encuestando una pool de mensajes a
enviar, la cola de mensajes puede ir creciendo y estos serán añadidos
y enviados por el proceso que se inició en primer lugar.
Por último, aunque las opciones de python o java son completamente
válidas, requieren de un servidor que permita ejecutar código java o
python. Mientras que mi solución sólo requiere de un sistema que
disponga de un entorno PHP y pueda ejecutar el comando wget (o en su
defecto curl o similares).
Entiendo que mi solución sirve para entornos muy concretos y con un
coste de recursos muy bajo.
On 16 mar, 15:54, "pablofmora...@gmail.com" <pablofmora...@gmail.com>
wrote:
> >> 2010/3/16 Octavio Benedí Sánchez <octavioben...@gmail.com
> >> <mailto:octavioben...@gmail.com>>
> ...
>
> leer más »