Buenas y malas noticias del proyecto transparente.gt

[Stuardo -StR- Rodríguez]

Estamos muy contentos que proyecto en http://transparente.gt ya ha logrado recopilar más de 390,000 registros del portal de Guatecompras. Estos datos están publicados en nuestro portal para ser consultados por cualquier usuario, o para descarga para investigaciones más profundas.

Lamentablemente hemos llegado a nuestro límite de cuota de espacio en disco en nuestro servidor para poder seguir recopilando más información.

Actualmente estamos trabajando en buscar patrocinios para poder continuar con nuestro trabajo para poder incrementar nuestro servidor y poder recopilar más datos.

¿De qué forma buscamos patrocinios?

- Si tenés un server o una máquina que pueda estar conectada todo el tiempo para hacer la barrida de datos, con un procesador libre, y 40G libres de espacio, eso soluciona el problema.

- Otra opción es ayudando a mejorar el código. El bloqueo ahora es por espacio. Creo que si mejoro la capa de cache para que comprima las páginas en cache, eso ayudaría, pero no se si volvería muy lento el proceso haciéndolo contraproducente. Es de investigar.

- De lo contrario, donaciones para comprar un año de un server más grande es lo que estamos buscando.

​

--

	Stuardo -StR- Rodríguez	| Mercenary Web Developer	| La Maphpia
	http://maphpia.com	| email:  s...@maphpia.com	| g-hangouts: s...@maphpia.com
	office: +502 2221-9830	| mobile: +502 4210-8819	| skype: stuardo_str

[Javier Alvarez]

Crees que puedan realizar una integración con amazon s3. Yo pongo la cuenta el espacio es muy barato con ese servicio.

--
--
PHPGT :: Grupo de PHPeros de Guatemala
email: ph...@googlegroups.com
reglas de uso: https://sites.google.com/site/grupophpgt

---
Has recibido este mensaje porque estás suscrito al grupo "PHPGT Grupo de PHPeros de Guatemala" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a phpgt+un...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Stuardo -StR- Rodríguez]

2015-05-25 11:11 GMT-04:00 Javier Alvarez <jalvare...@gmail.com>:

Crees que puedan realizar una integración con amazon s3. Yo pongo la cuenta el espacio es muy barato con ese servicio.

Lo que nos topó fue el espacio donde el scraper guarda el cache de la descarga. Si podemos clonar el scraper en un S3, con un intérprete de php y una base de datos MySQL, estamos hechos. Cuando el scraper ya descargue todo, hacemos el dump de la DB en el portal público.

Si donás la cuenta, te lo agradecería un montón. Pasas los accesos y ya pongo el scraper a correr ahí.

[Douglas]

Porque no manejar en código un threashold para lo que se usa de cache?

--
Enviado desde mi Gmail

--

[Stuardo -StR- Rodríguez]

2015-05-25 12:07 GMT-04:00 Douglas <dougy...@gmail.com>:

Porque no manejar en código un threashold para lo que se usa de cache?

El cache se está usando porque se hacen muchas barridas de la misma data. Comienza a descargar cada página para obtener los datos, y BLAM, el scraper crashea porque se encontró alguna excepción, algún dato que no hacía sentido, o similares. Entonces volveeeeeeeeer a descargar todas las páginas anteriores para volver a parsear los datos era muy lento.

Otro caso es que luego nos damos cuenta que podemos mejorar la estructura de la DB, agregar nuevos campos o cosas así. Modificamos la estructura y volvemos a correr el scraper, pero como las páginas ya están descargadas, no se tarda "tanto".

Por eso TODAS las páginas descargadas se guardan en cache.

[Douglas]

Y pq no sacar un hash de cada pagina ya procesada, así no las tenes que volver a procesar si crashea. Descargas, si hace match con algun hash, descartas y seguis adelante.

--
Enviado desde mi Gmail

--

[Stuardo -StR- Rodríguez]

2015-05-25 13:29 GMT-04:00 Douglas <dougy...@gmail.com>:

Y pq no sacar un hash de cada pagina ya procesada, así no las tenes que volver a procesar si crashea. Descargas, si hace match con algun hash, descartas y seguis adelante.

No entiendo tu propusta. El problema no es el manejo del cache, el problema es que ya no tenemos espacio para el cache.

[Douglas]

Por eso, en vez de guardar todo en cache, pq no borrar lo que ya se proceso y guardar las firmas nada mas para saber si es necesario procesar o no.

--
Enviado desde mi Gmail

--

[Stuardo -StR- Rodríguez]

2015-05-25 13:41 GMT-04:00 Douglas <dougy...@gmail.com>:

Por eso, en vez de guardar todo en cache, pq no borrar lo que ya se proceso y guardar las firmas nada mas para saber si es necesario procesar o no.

La meta no es eliminar cache, porque si lo podemos volver a necesitar.

[Manoloweb]

Montar un Varnish en medio de alguna forma no ayudaría? Obvio son más recursos, pero dejando eso de lado... Ayudaría?

[Stuardo -StR- Rodríguez]

2015-05-25 13:48 GMT-04:00 Manoloweb <mano...@gmail.com>:

Montar un Varnish en medio de alguna forma no ayudaría? Obvio son más recursos, pero dejando eso de lado... Ayudaría?

Entiendo que Varnish es para acelerar la página. El sitio transparente.gt no es el problema. El portal no usa cache, ni tenemos problema de tráfico, espacio, disco, memoria ni nada en el sitio. El problema lo tenemos en el sistema que se encarga de descargar las páginas de guatecompras.gt, que corre aparte.

[Manoloweb]

Lo entiendo... Ahí es donde sugería el Varnish, entre gtc y el backend

Ahí el back se preocupa por parsear, no por esperar.

--

[Manoloweb]

Arquitectura...

Al backend se le setea por hosts la ip donde estaría el Varnish, al Varnish se le setea de origin el servidor real de gtc, después se crean crons en muchas máquinas que provoquen que Varnish guarde en caché todo, y luego tu aplicación le pide a Varnish en microsegundos... Cachas?

M

[Stuardo -StR- Rodríguez]

Dejá ver si entendí, el scraper se conecta a varnish en vez de guatecompras. Varnish hace el request a guatecompras y lo guarda en cache. Cuando el scraper necesite volver a obtener la página de guatecomrpas, varnish ya lo tiene y se la retorna sin necesidad de volver a conectarse a guatecompras.

¿Entiendo bien?

Si es así, solo estoy moviendo a que el cache lo maneje varnish en vez del scraper, y los 20G de cache siguen existiendo, solo que en otra capa.

[Manoloweb]

Más o menos, con la diferencia que puedes poner a cientos de externos a pedir caché por anticipado... Así el tiempo de espera no lo tiene el scraper.

Digamos que veinte de nosotros ponemos a correr wgets recursivos por las noches... Cachas?

[Stuardo -StR- Rodríguez]

2015-05-25 17:34 GMT-04:00 Manoloweb <mano...@gmail.com>:

Así el tiempo de espera no lo tiene el scraper.

El problema actual no es el tiempo de carga sino el espacio en disco