El sistema desarrollado para clientes pequeños de 100 articulos maximos, tarda 40 segundos en un entorno de 600 articulos en ese cliente, en un server con load de 3. Y se quejan.

¿Porque no lo mandan al sistema grande?

¿Porque usan 200 ftp simultaneas?

¿porque permiten un load arriba de uno constante?

Sin comentarios.

Las dos ultimas semanas han estado saturadas de trabajo. Por lo general duermo muy poco pero esta semana dos ocasiones seguidas he dormido menos de lo común.

Por otra parte, he estado realizando un cliente de JSON y el universo de bases de datos es de un gb y medio actualizandose cada 20 minutos. Si me descarga la cabecera de código last modified, lo que me evita descargas de más.

Sigo probando ideas de servers al mismo tiempo. Y me acordé hace rato de algo , de una incomodidad fuerte en sueños allá por el domingo: Aunque pràcticamente no sueño, uno de esos días tuve una pesadilla de código arbitrario bajo el JSON.

Digo pesadilla para referirme a un sueño sin lógica, sin fin constructivo, e incluso a media depuración en sueños, yo pensaba: Se que esto es un sueño porque el cliente ya me regresa bien el header de last modify, asi que no entiendo que me quiere decir mi mente al comentarme del código arbitrario. Si mi parser no ejecuta objetos y convierte como paso previo a un array que no puede ejecutar por definición, ergo, este no es una pesadilla de código arbitrario sino un sueño estúpido.

Asi que me desperté. En ocasiones he soñado con código fuente y formas de mejorarlo, pero nunca me imaginé que fuera posible una pesadilla de código arbitrario bajo JSON.

Lo bueno de conocer las reglas del RFC y hacer tu propio parser, te hace inmune a ataques de idiotas con mucho tiempo libre.

Me reportaron que una pantalla que tiene cerca de 200 combos cargados de bases de datos, esta lenta y provoca pantalla en blanco en uno de los clientes del corporativo.

Load arriba de 2, solución obvia: Comentar esta línea
//if ( extension_loaded( «zlib» ) ) ob_start( «ob_gzhandler» ); // Habilita compresion. No mover si no se entiende.

Explicación:
El server no tiene suficiente cpu disponible para iniciar el zlib de php.

El uso que le está dando a ese server no es el originalmente planeado, y no toman en cuenta la sobrecarga que le está causando.

El 23 de mayo escribí acerca de tener archivos dentro o fuera de la base de datos :http://alfonsoorozcoaguilar.com/2011/05/23/archivos-dentro-o-afuera-de-la-base-de-datos/

El 4 de julio comenté que el tmp medía 23 gb. Lo borro cada semana.

Algo hicieron con los cambios de derechos que el tmp esta usando 58 gb de 120… y nose borran con miscript. Al limitar ejecuciones de llamadas a system desde php, los scripts de hace un mes tampoco sirven

Que bárbaros.

Lo bueno es que parece que mi versión propia de repositorio de archivos para corregir las deficiencias de cvs como subversion puede resolver esto por hoy.

Varios de los sistemas que he desarrollado se autentifican por CURL contra passport de microsoft.

Una de las dos claves que uso, no relacionadas con hotmail, no funciona. Probablemente desactivada por no entrar al messenger en esa cuenta. La otra lo usa incidentalmente cuando skype falla. Y son dos dominios desconocidos.

Interesante.

Sea l oque sea no usare la autentificacion por «passport de facebook» jamas.

Como no tiene el asunto para cuando, tomé la decisión drástica de enviar este correo, para preparar el alto.

Asunto :Que respaldos estaran disponibles de servidor de la empresa

Me puse de acuerdo con Alejandro y G para sacar respaldos del servidor de ******* ******, por el metodo de cpanel, y esto es lo que se hará a partir del 15 de agosto.

Puntos importantes:
* Sacaré respaldo diario del servidor ******* ****** a uno de mis servidores propios
* y estarán disponibles online 5 versiones correspondientes a la semana anterior (lunes martes miercoles jueves viernes ), incluyendo base de datos.
* Conservaré respaldos diarios en mi pc de los ultimos 15 dias naturales
* Se guardará además el respaldo del dia 15 y ultimo de cada mes
* por fines de control, se eliminarán el 31 de agosto de este año la mayor parte de los respaldos anteriores al 15 de agosto del presente.

Hace unos ocho dias renove unos dominios en moniker por paypal, y se me cobró. Me llegó hoy un aviso de que uno de los dominios serán desactivados…. y hubo cambios otra vez en el whois.

Esto me pasó solo una vez antes (hace unos 5 años) con un registrar que colapsó.

El sentido comun me dice dejar Moniker Lo mas pronto posible.

Voy a acabar pagando doble unos dominios, pero ya que.

Afortuanadamente solo son unos 15.

Hubo dos avisos anteriores con algunos servicios gratuitos, y publicidad en unas redirecciones includidas, ademas de la imposibilidad de dominios con DNS en blanco.

Que mal.

Tendré que ir pensando que registrar usar para esos casos, casi seguro srsplus.

Saque un respaldo de ayer a hoy en mi casa, metodo normal de cpanel , mide 3.5 gb Tengo dos conexiones, en una se tarda 7.5 horas y en otra 2 horas

Lo copie a mi servidor personal mediante copia directa via ftp, se tarda UNA HORA Y MEDIA EN GENERARLO, y en subirlo poco menos de una hora, el archivo subido de restore cpanel fue de 2 gb, porque desaparece el contenido de tmp del respaldo en ese tipo de copia.

Me resulta evidente que esa es la unica manera posiblle de sacar respaldos que incluyan en un solo paso una cifra de verificacion (creo que es md5), pero ese archivo final, copiado a otro servidor y despues restaurado para la prueba en frio, es el que debe quemarse regularmente o guardarse en los hipoteticos usb.

Notas :

1 ) Tenemos demasiados archivos. Que pasa si creamos una base de datos nueva llamada «boveda» y adapto un script que tengo para que guarde el archivo que definamos a esa boveda, despues de cierto tiempo. Si Redirigimos el error 404 a boveda.php y ese devuelve el archivo descargando de la boveda, no hay que alterarar la programación y es mucho mas rapido de respaldar o verificar una base de datos con blob, que pinche mil archivitos.

2 ) no esta documentado de que es cada directorio ni cada base de datos, se lo que habìa a Octubre del año pasado.

Recomendaciones:

1 ) Ver que hacemos para disminuir el uso de disco duro (¿maquina virtual o algo asi para descarga en otro sitio que no respaldemos?)
2 ) compra de software getright ( http://getright.com/ 19.95 usd y es mas barato) para poder descargar en parcialidades el archivo de 2 gb con nuestra eficaz conexión de internet. WINSCP no le tengo confianza y por lo menos en un caso me ha bajado archivos corruptos por el tamaño.

Hoy tuvimos un problema con los respaldos, mismos que son mi responsabilidad asumida voluntariamente. Se solucionó pero mandé este correo (alteré algunos datos basicos pero este es el problema):

Resumen Breve:

Solo para informar que me pidió David un respaldo de la base de datos del 26 de julio, (para ver algo de pq) y aunque tengo el archivo, no se puede abrir con windows ( ruta demasiado larga dentro ) y probablemente si desde linux. No es importante y ya fue solucionado por David contactando al cliente para ver lo del registro, pero quiero sugerir, de la manera mas enfática, que contratemos otro servidor dedicado para poder hacer pruebas en frio para verificar que tenemos respaldos y no ilusiones, normalmente estoy pasando el respaldo total al disco duro de mi casa, y a uno de mis servidores, mas el que ocasionalmente descargo aqui, pero probar un respaldo de 3.5 gb de tamaño resulta muy complicado y tampoco tenemos la garantia que el respaldo del sistema funcione y que sea suficiente para levantar en otro server( tendriamos que recrear los ajustes de puertos abiertos, etc)

Consideraciones:

a ) En una empresa como la de nosotros, enfocada a información sensible, los respaldos deben realizarse regularmente (cosa que hacemos) y probarse regularmente (no lo hacemos) además de amacenamiento externo (en este caso el nuevo server)

b ) (confidencial)

c ) No tenemos la estructura montada alrededor de continuidad de la empresa si nos cae un rayo a los que conocemos el «know how» o los datos de pago. Creo que es importante, por continuidad de la empresa y detectar nuestros puntos débiles, hacer un plan de continuidad de negocio.

Detalle:

Aunque hemos hablado de un script para automatizar respaldos (del que voy a medias), no es aconsejable automatizar la verificación del respaldo, sino probarlo ocasionalmente para ver que tenemos mas que aire.

Yo asumo que el supuesto error del archivo se puede deber a que nos desconectamos de la red a mitad de su descarga, o a que tenemos directorios con mas de 2 mil archivos.

Lo que haré ADICIONAL a partir de HOY es respaldar la base de datos principal de manera manual y adicional a lo actual, y revisarla manualmente. Estoy respaldando de un modo lento, pero que funciona de manera segura y que me permite verifcar manualmente al terminar, aunque la conexion me hace reiniciarlo. El respaldo de esa base de datos hoy no puede sacarse en formato zip normal, o en horas normales de oficinas, porque mide mas de 1.2 gb pero por lo menos no cabe ya en un cd, y eso es la base de datos PRINCIPAL, de manera independiente al contenido del sitio, y a las bases de datos secundarias. Van cinco veces seguidas que se cae el internet a mitad de la descarga, por lo que no me fue posible descargarla manualmente.

Esto evidentemente me ha obligado a ir borrando varios de los respaldos anteriores, por limitaciones de espacio del disco duro de mi portatil que uso aquí, y de la computadora de escritorio de mi casa.

Que recomiendo:

1 ) contratar otro servidor dedicado para pruebas en frio y almacenar respaldos.

2 ) por lo menos quincenalmente verificar que un respaldo completo levante en frio.

Que voy a hacer:

1 ) Verificar a partir de hoy los respaldos de base de datos manualmente.
2 ) Hacer bitácora de respaldos existentes, describiendo si son aire o probados, incluyendo fecha programada para su borrado.
3 ) proseguir con el script de respaldos del servidor automatizado (no se puede respaldar por ftp por exceso de archivos, debe ser via tar)

Llevo unas semanas batalland ocon sistemas de autentificacion de clientes JSON. Hoy mismo encontré el problema que cambió de proveedor de proceso de tarjeta de credito el datacenter al que rento este servidor, y ese nuevo proveedor bloqueó el pago del server porque le pareció raro que una tarjeta de crédito internacional de México pague servidores en ese país.

Asunto arreglado.

No es la primera vez que me pasa: Cada vez que estados unidos tiene un problema en su calificación de credito, parece que los proveedores de pago directo con tarjeta se ponen sus moños.