Estas en: Home > MySQL

Entradas etiquetadas con MySQL

Optimización de WordPress

Mejorando el redimiento, el tiempo de carga y la puntuación de Page Speed de tu WordPress

0

Ya tienes tu WordPress instalado, configurado y con un estupendo tema. Le has instalado entre media y una docena de plugins, ya sean para añadir nuevas características a la administración, o para el frontend. Le has añadido un montón de contenidos para que, en cuanto lo subas a producción, los usuarios se queden maravillados de lo bien que escribes, de los productos que vendes, de los trabajos que realizas, etc. Has contratado al mejor analista SEO de todo el mundo para conseguir estar en los primeros puestos y comerte a la competencia. Tienes una campaña de marketing para radio, televisión, prensa e internet, que ni los de Nike.

Y lo subes a producción.

Y aunque tendrás visitas, venderás tus productos, y los usuarios te conocerán gracias a la campaña de marketing, el negocio no termina de despegar. Empiezas a preguntarte qué sucede. Pides informes, análisis, reuniones, cambios, mejoras. Pero nada lo soluciona.

(más…)

Integración continua: primeros pasos

0

Ya expliqué la semana pasada qué era eso de la integración continua, pues bien, ahora toca dar los primeros pasos. Obviamente necesitamos un ordenador que haga de servidor, una máquina virtual, o bien un servidor de verdad si lo que pretendes es utilizar de forma profesional.

Como sistema operativo para esta guía utilizaré Ubuntu 14.04. Tú puedes usar el que quieras pero tal vez te resulte más complicado encontrar algún software, con lo que tendrás que investigar más.

El hardware a usar dependerá de las necesidades que tengas, o para lo que quieras un servidor de integración continua. En mi caso utilizo un pc de gama baja con micro AMD, 8 GB de RAM, sin teclado, ratón, ni monitor (y por tanto sin escritorio gráfico), y con una tarjeta WiFi para conectar a internet. Y esto, para mí, es suficiente. Si lo fueses a usar en un grupo de desarrollo, lo mejor es usar un VPS o un servidor dedicado, ya que mejorará en gran medida el rendimiento.

Ya tenemos el hardware listo y nuestro sistema operativo está instalado, por tanto vamos a iniciar los primeros pasos para crear nuestro servidor de integración continua.

(más…)

Logo Cassandra

Cassandra 1.x y PHP para desarrolladores SQL: La consola

0

Cassandra dispone de una herramienta a través de la consola o shell para poder trabajar con ella. Parecida a la de MySQL.

Para acceder a la consola solo tendremos que escribir lo siguiente:

> cassandra-cli

Si todo va bien nos aparecerá algo parecido al siguiente texto:

Welcome to Cassandra CLI version 1.0.7
Type 'help;' or '?' for help.
Type 'quit;' or 'exit;' to quit.
[default@unknown]

Ahora tenemos que conectar con la base de datos de la siguiente manera:

connect localhost/9160;

Fíjate que al final del comando hay un punto y coma. Hay que añadirlo, como si fuera una sentencia SQL, sino te aparecerán unos puntos suspensivos para que finalices el comando. Si te ocurre esto último, pon el punto y coma y pulsa enter. Te debería aparecer algo como lo siguiente:

Connected to: "Test Cluster" on localhost/9160

Hay una forma de resumir los pasos anteriores en una sola linea:

> cassandra-cli -h localhost -p 9160

Ahora vamos a mostrar los keyspaces que tiene la base de datos actualmente:

show keyspaces;

[ci-box type=»warning»]Recuerda poner el punto y coma.[/ci-box]

Este comando te mostrará un listado de los keyspaces y sus column families que se encuentran en la BD, además de información relevante sobre las propiedades, tanto de los keyspaces como de sus column families correspondientes.

El objetivo de este post no es explicar con detalle cada propiedad de los keyspaces y las column families (he de admitir que muchas de ellas las desconozco), sino mostrar y enseñar la forma de trabajar por consola con Cassandra.

Vamos al lío.

 

CREAR UN KEYSPACE

Tan sencillo como la siguiente sentencia:

create keyspace my_keyspace;

Después de dos o tres segundos te mostrará algo como esto:

b511da50-88c0-11e1-0000-242d50cf1fff
 Waiting for schema agreement...
 ... schemas agree across the cluster

 

ACCEDER A UN KEYSPACE

Igual de sencillo:

use my_keyspace;

Ahora que ya estamos dentro de nuestro keyspace, toca añadir column families.

 

CREAR COLUMN FAMILIES

Muy sencillo:

create column family my_column_family;

Añadamos datos.

 

AÑADIR DATOS A UNA COLUMN FAMILY

En MySQL utilizaríamos una sentencia INSERT para añadir información a una tabla concreta, en la que anteriormente habremos creado sus columnas. En Cassandra no hay que crearlas con antelación. (En realidad se puede utlizar un archivo para configurar el esquema del keyspace dando las propiedades adecuadas a cada column family y sus respectivas columnas, pero para iniciarnos en Cassandra y aprender su funcionamiento no es necesario).

Para no complicarnos mucho primero vamos a configurar la column family.

Las column families disponen de diferentes tipos de codificación de datos para guardar los datos, es decir, si guardamos información en UTF-8 y nuestra column family está configurada como ASCII o Bytes nuestros datos se guardarán, sí, pero al recuperarla solo veremos un batiburrillo de número y letras.

Para evitar esto configuramos la column family para que guarde los datos en UTF-8:

assume my_column_family keys as utf8;
assume my_column_family comparator as utf8;
assume my_column_family validator as utf8;

Ahora ya podemos crear nuestro primer registro:

set my_column_family['1']['nombre'] = 'pepito';
 set my_column_family['1']['edad'] = '120';

Si ejecutamos el siguiente comando:

get my_column_family['1'];

Nos devolverá las columnas que tuviese la fila con id = 1, junto con los correspondientes valores de esas columnas.

Esto es el funcionamiento básico de la consola de Cassandra. Hay muchos más comandos para obtener información de Cassandra y realizar algunas tareas más, para obtener la ayuda y ver estos comandos solo tienes que escribir lo siguiente:

help;

¿Fácil verdad? Por último, para salir de la consola:

quit;
Logo Cassandra

Cassandra y PHP para desarrolladores SQL: La consola

0

Cassandra dispone de una herramienta a través de la consola o shell para poder trabajar con ella. Parecida a la de MySQL.

Para acceder a la consola solo tendremos que escribir lo siguiente:

> cassandra-cli

Si todo va bien nos aparecerá algo parecido al siguiente texto:

Welcome to Cassandra CLI version 1.0.7

Type ‘help;’ or ‘?’ for help.
Type ‘quit;’ or ‘exit;’ to quit.

[default@unknown]

Ahora tenemos que conectar con la base de datos de la siguiente manera:

connect localhost/9160;

Fíjate que al final del comando hay un punto y coma. Hay que añadirlo, como si fuera una sentencia SQL, sino te aparecerán unos puntos suspensivos para que finalices el comando. Si te ocurre esto último, pon el punto y coma y pulsa enter. Te debería aparecer algo como lo siguiente:

Connected to: «Test Cluster» on localhost/9160

Hay una forma de resumir los pasos anteriores en una sola linea:

> cassandra-cli -h localhost -p 9160

Ahora vamos a mostrar los keyspaces que tiene la base de datos actualmente:

show keyspaces;

Recuerda poner el punto y coma.

Este comando te mostrará un listado de los keyspaces y sus column families que se encuentran en la BD, además de información relevante sobre las propiedades, tanto de los keyspaces como de sus column families correspondientes.

El objetivo de este post no es explicar con detalle cada propiedad de los keyspaces y las column families (he de admitir que muchas de ellas las desconozco), sino mostrar y enseñar la forma de trabajar por consola con Cassandra.

Vamos al lío.

 

CREAR UN KEYSPACE

Tan sencillo como la siguiente sentencia:

create keyspace my_keyspace;

Después de dos o tres segundos te mostrará algo como esto:

b511da50-88c0-11e1-0000-242d50cf1fff
Waiting for schema agreement…
… schemas agree across the cluster

 

ACCEDER A UN KEYSPACE

Igual de sencillo:

use my_keyspace;

Ahora que ya estamos dentro de nuestro keyspace, toca añadir column families.

 

CREAR COLUMN FAMILIES

Muy sencillo:

create column family my_column_family;

Añadamos datos.

 

AÑADIR DATOS A UNA COLUMN FAMILY

En MySQL utilizaríamos una sentencia INSERT para añadir información a una tabla concreta, en la que anteriormente habremos creado sus columnas. En Cassandra no hay que crearlas con antelación. (En realidad se puede utlizar un archivo para configurar el esquema del keyspace dando las propiedades adecuadas a cada column family y sus respectivas columnas, pero para iniciarnos en Cassandra y aprender su funcionamiento no es necesario).

Para no complicarnos mucho primero vamos a configurar la column family.

Las column families disponen de diferentes codificación de datos para guardar los datos, es decir, si guardamos información en UTF-8 y nuestra column family está configurada como ASCII o Bytes nuestros datos se guardarán, sí, pero al recuperarla solo veremos un batiburrillo de número y letras.

Para evitar esto configuramos la column family para que guarde los datos en UTF-8:

assume my_column_family keys as utf8;
assume my_column_family comparator as utf8;
assume my_column_family validator as utf8;

Ahora ya podemos crear nuestro primer registro:

set my_column_family[‘1’][‘nombre’] = ‘pepito’;
set my_column_family[‘1’][‘edad’] = ‘120’;

Si ejecutamos el siguiente comando:

get my_column_family[‘1’];

Nos devolverá las columnas que tuviese la fila con id = 1, junto con los correspondientes valores de esas columnas.

Esto es el funcionamiento básico de la consola de Cassandra. Hay muchos más comandos para obtener información de Cassandra y realizar algunas tareas más, para obtener la ayuda y ver estos comandos solo tienes que escribir lo siguiente:

help;

¿Fácil verdad? Por último, para salir de la consola:

quit;

Optimización de WordPress

Consumo de memoria en distintas versiones de WordPress

2

Como comenté hace unos días realicé varias pruebas para averiguar cuanta memoria consumía WordPress en versiones posteriores a la actual. Aquí os dejo los datos para que podais compararlos con el consumo de vuestro WordPress.

  • Versión 2.2: 5488.4 KB
  • Versión 2.3: 6287.9 KB
  • Versión 2.5: 7164.6 KB
  • Versión 2.6: 9161.2 KB
  • Versión 2.7: 10442.1 KB
  • Versión 2.9: 14215.9 KB
  • Versión 3.0: 15666.1 KB

Las pruebas se han realizado con AppServ 2.5.10 (PHP 5.2.6, Apache 2.2.8, MySQL 5.0.51b) bajo Windows.

Optimización de WordPress

Mi última pesadilla: Optimizar el VPS para WordPress

16

Pesadilla… de tres semanas y pico. Anoche soñé con la lista de procesos del comando top de Linux. Apache consumía cada vez más y más memoría. Por consumir, consumió el Kernel de Linux y se transformó en el Kernel de Windows. Y no se porqué antes de despertarme entre sudores fríos apareció Bill Gates descojonandose a moco tendido. Dios, ¡Qué imagen!, no se me quita de la cabeza.

Durante este tiempo me he didicado a «intentar» optimizar tanto el VPS como WordPress para reducir el consumo de memoría. Aunque he hecho algunas mejoras (pocas por desgracia) sigue cayendose Apache; pero comenzaré por el prinicpio:

¿Porqué un VPS?

  1. Por el precio: Ví un VPS más o menos al mismo precio que un hosting y apliqué el dicho «burro grande ande o no ande».
  2. Por aprendizaje: Nunca había probado un VPS y quería saber como poder administrarlo, que se puede hacer con él. No jodes tantas cosas como con un dedicado y hasta cierto punto tienes menos responsabilidad y es mucho más barato. Y es el paso lógico antes de administrar un dedicado, en el que ahí estas solo completamente.
  3. Por unificar mis proyectos web: Dispongo de cinco dominios. Para cada uno tengo planes para crear una web con ellos,o en algunos casos ya está creada y online, en otro, estoy esperando a ver que pasa con el VPS y otros solo estan proyectados. Disponer de todas las webs en un solo servidor, ya que no tienen muchas visitas, es muy pero que muy cómodo, además de económico.
  4. Por ahorar costes: Cinco dominios, cinco hostings. Aunque los hay muy baratos (desde un euro) siempre te limitan alguna cosa y no me convencian.
  5. Por libertad: La posibilidad de hacer y deshacer a mi antojo, en definitiva, de tener el control de la máquina (virtual) es una gozada.

Características del VPS

  • Memoría RAM: 256 MB
  • Espacio en disco: 5 GB
  • Transferencia mensual: 150 GB
  • Sistema operativo: CentOS 5
  • Panel de control: Plesk
  • Y obviamente el resto de características habituales: Perl, PHP, MySQL, etc, etc, etc.

El principio

Cuando contraté este VPS, era un puto ignorante, así de claro, desconocía muchas cosas sobre la administración de servidores, su optimización, y sobre todo, las características que había que observar detenidamente antes de contratar nada (en VPS. En hosting, tengo bastante idea). Menos mal que era el más barato xD.

Desde el tercer o cuarto día comenzó a fallar Apache. Los datos que obtenía tanto de Plesk como de Virtuozzo me indicaban que la memoría se saturaba y paraba los servicios. Claro, como un ignorante creé un ticket al proovedor. La respuesta fué rápida (y ahora la más lógica), «actualice su VPS a uno superior». No comprendía como me podían decir eso. ¡Que sólo es un blog! ¡Que el día que llega a 100 visitas monto la fiesta padre! !Coño, que no es Digg, ni el Mundo! ¿Cómo podía ser que con solo al acceder a la página principal de la administración (el escritorio de WordPress), Apache ya se viniese abajo? ¿Cómo era posible?.

Sólo había una idea en mi cabeza: «Estos del hosting quieren sacarme más pasta» (Viendolo ahora, en cierto sentido, tenía razón). Pero esa idea no soluciona el problema, aunque mi cabezonería la convirtió en  mantra y como con levantar Apache o reiniciar el contenedor volvía todo a funcionar, se quedo así durante meses.

Primeros intentos

No soy una persona que se rinda fácilmente. Yo siempre digo que en informática no hay nada imposible, sino poco presupuesto. Así que comencé a informarme sobre VPS, WordPress, Apache, etc. De esto puede dar fe mi navegador (uso Opera) que ahora mismo tengo abiertas unas 50 pestañas.

Lo primero fue buscar una forma para averiguar cuánta memoría consumía WordPress. Encontré el siguiente código:

$memoria_usada = round(memory_get_usage(1) / 1024,1);
echo ‘Memoria usada: ‘ . round(memory_get_usage() / 1024,1) . ‘ KB de ‘ . $memoria_usada . ‘ KB’;

Este código indica la memoría que había antes de ejcutar el script (que se guarda en la variable $memoria_usada y se pone al inicio del archivo) y la memoría consumida después de ejecutar el script (que se pone al final). Los datos en local que saqué fueron los siguientes:

9 plugins: Memoria usada: 27462 KB de 67.1 KB
Sin plugins: Memoria usada: 20468.8 KB de 67.2 KB
Actualizando el theme: Memoria usada: 21049.1 KB de 67.1 KB (Utilizando el theme que tengo en el blog actualmente, sustituyendo al theme por defecto)

Siento no tener los datos del VPS, pero no varían mucho. Ahora mismo consume 29,5 MB con ocho plugins activos (no son los mismos plugins han variado desde entonces) más el theme.

Las pruebas las realicé con WordPress 3.0.1 con la base de datos tal cual se instala, bajo Windows con la suit de AppServ sin modificaciones.

Yo, cuando ví las cifras, me quedé alucinado: ¡Wordpress consume casi 20,5 MB!. Realicé pruebas con otras versiones de WordPress para verificar que esto era así, es decir, comprobar que con el paso de las versiones el consumo de memoria había aumentado. Que no era cosa mía, sino que es así de chupón. Aunque aquí puede variar el consumo de memoría dependiendo de las reglas de mod_rewrite de Apache, de como esté optimizado PHP y MySQL, etc. El único culpable no es WordPress, pero acojona.

Viendo lo visto, era hora de actuar.

WordPress a dieta

Sabía que existian varios plugins que permitian cachear las páginas del blog y reducir el consumo de memoria y procesador, pero simpre lo había visto en blogs con miles de visitas, no en uno cutre con theme gratuito que no llega a las cien visitas diarias (triste pero cierto).

El primero en activar en el blog, wp-cache, me costó un poco instalarlo, más por mi inexperiencia con cachés que otra cosa (mira que es sencillito el plugin). Al final no se lo que me paso, no lo recuerdo, que lo desactivé. Busqué otro.

WP Super Cache, no mienten los que hablan bien de él, funciona estupendamente, es un poco más complicado de configurar que wp-cache pero el resultado es magnífico. Pero el blog seguía consumiendo casi 30 MB de memoría y Apache se caía. Mejoró la estabilidad del blog un poco, al menos de cara al visitante sí. Pero seguía con el mismo problema: en cuanto entraba en el Escritorio Apache se escoñaba.

Antes de esto probé cada uno de los plugins para ver cual era el que hacía que Apache se cayera nada más entrar en las administración del blog. WordPress.com Stats era el culpable, la establidiad mejoró sustancialmente teniendo este plugin desactivado. Durante unos días pensé que estaba solucionado el problema, nada más lejos de la realidad. Aunque el blog consumia menos memoría, en cuanto hacía algo que requiriese más esfuerzo por parte de la RAM, Apache se venía abajo. Simplemente con entrar varias veces en el escritorio del blog o activar un plugin, Apache caía. Fue frustrante.

Un plugin del que no conocía su existencia es DB Cache Reloaded. Como su nombre indica, permite cachear las consultas a la base de datos, evitando que se conecte a la base de datos cada vez que haya una petición a esta. Reduce el consumo de recursos. Bien. Activado está y funciona de maravilla, aunque de momento no termina de cachear todas las consultas. Tendré que mirar porqué.

Pero el problema continuaba, Apache se caía. Había que entrar en el servidor.

SSH

Tengo que admitir que no me había conectado nunca a otro ordenador a través de SSH, si a través de VNC y VPNs.

Trabajo con Windows XP SP3 principalmente, pero no le hago ascos a las distribuciones linux, todo lo contrarío: en VirtualBox tengo instalados Debian, CentOS, Ubuntu y ChromeOS, y excepto para el tema de configurar la tarjeta gráfica que aun no he conseguido (creo que VirtualBox es el que no la reconoce y por algún motivo envía al SO una tarjeta gráfica compatible con la que tengo, pero me obliga a estar con una resolución de 800×600).

Bien, ¿porqué cuento esto?. Además de por que quería contarselo a alguien xD, por que así comprenderás que después de varios intentos por conectarme al servidor con varios programitas para Windows, arrancase una máquina virtual para conectarme por la consola de linux. ¡Bendita seas!. Hasta que descubrí que lo que me fallaba era el puerto para poder acceder. ¡La ignorancia da la felicidad!.

Una vez conectado al servidor lo primero que hice fue un top de la máquina para conocer el consumo de RAM (la leche no) en tiempo real.

Me indicaba que tenía 512 MB de RAM total y la memoría consumida oscilaba entre los 170 y los 220 MB, aunque en algunos podía llegar a 270 MB. El problema radica en que el VPS no tiene 512 MB de RAM sino 256 MB; los otros 256 es memoría compartida, con lo que no puedo contar con ella para realizar el cálculo.

También hice un free -m para comprobar la memoria, pero top me ofrece más datos.

Observé que cuando se pide al servidor una página apache ejecuta cuatro procesos de sí mismo llegando en varios casos a consumir un 12 por ciento de memoría RAM. Lo normales un 10 por ciento.

A por Apache

Optimizar Apache. Me costó un huevo y medio encontrar la ubicación de los archivos de configuración, pero cuando me enpeño… (/etc/httpd/conf en CentOS). Bien, leí que si realizaba ciertas modificaciónes en el archivo httpd.conf de Apache podría reducir el consumo de memoría. Por defecto la configuración de Apache era la siguiente:

<IfModule prefork.c>
StartServers                     8
MinSpareServers              5
MaxSpareServers            20
ServerLimit                   256
MaxClients                   256
MaxRequestsPerChild   4000
</IfModule>

Se quedo así:

<IfModule prefork.c>
StartServers                      5
MinSpareServers               5
MaxSpareServers             10
ServerLimit                     30
MaxClients                     30
MaxRequestsPerChild 40000
</IfModule>

No solucionó mucho, o por lo menos yo no lo noté. Reduje también varios parámetros más, como el tiempo que espera Apache para cerrar una conexión permanente, etc.

Esto seguía sin mejorar. Probemos con la base de datos

MySQL

Poca optimización realicé aquí, la verdad. Me limite a añadir la configuración para habilitar la caché de la BD, pero no ha hecho mucho. También puede deberse a que el plugin de WordPress que cachea las consultas ya lo está haciendo. No sé. La configuración quedo del siguiente modo:

query_cache_type = 1
query_cache_limit = 1M
query_cache_size = 8M

PHP

Para optimizar PHP necesitaba instalar en el VPS Eaccelerator y el Zend Optimizer, mis pocos intentos me han llevado a pensar que no puedo instalar nada que no sea a través de Plesk o que necesite el comando yum. Por tanto, a día de hoy, PHP está sin optimizar, habrá que enviar un ticket a ver si ellos me lo isntalan…

VPS

CentOS consume memoría, como todos los SO, las veces que he podido ver el consumo de memoría sin Apache, está rondaba entre 60 y 80 MB. Pero no sólo es el sistema operativo el que consume RAM, Plesk también consume lo suyo (unos 50 MB), he deshabilitado el antivirus que me consumía 70 MB cada vez que se iniciaba. Pero aunque el VPS se ha estabilizado hay momentos en los que Apache tiene cuatro procesos abiertos de 50-60 MB cada uno (según el comando top). Excesivo.

Intenté crear un archivo SWAP pero el comando swapon no lo tengo permitido, al menos por SSH.

CONCLUSIONES

  • Sigo valorando distintas opciones respecto a la optimización del VPS, ahora mismo mi mejor baza es Eaccelerator y que me lo instalen en el VPS para reducir la memoría.
  • Seguiré probando con algunnos plugin de WordPress a ver que tal.
  • Si estas interesado en la contratación de un VPS andate con ojo con la RAM.
  • Me he planteado incluso cambiar de VPS o ampliarlo con la misma empresa o marcharme a otra, ya se verá en septiembre.
  • Lo mejor de todo esto: lo aprendido por el camino. No solo conozco un poco mejor los sistemas Linux, sino también Apache, PHP, MySQL y Plesk, y su administración.
  • Bueno, ¿Y vosotros?¿Qué experiencia habeis tenido con los VPS?¿Qué consejos podeis darme? o simplemente ¿Qué opinais? Los comentarios son vuestros… mientras Apache lo permita xD.

LINKS

Os dejo unos links y así libero al navegador de carga, pobre.

Optimización del VPS

Optimización de WordPress

Optimización de PHP

Optimización de Apache

    Instalar Symfony + WAMP

    26

    Una de las cosas más entretenidas de un programador (al menos para mí), es la de reciclarse cada poco tiempo para no quedarse estancado. Yo estoy en este proceso y después de varios días intentando instalar Symfony junto con WAMP al fin lo he conseguido (Sí, me ha costado un huevo, ¡que pasa! xD); para que otros desarrolladores no tengan que dedicarse a buscar información sobre como instalar Symfony junto a WAMP voy a explicar como realizarlo, los fallos que me ha dado, como solucionarlos, etc. Vamos allá.

    (más…)

    Ocho cheat sheets para webmasters

    0

    Listas de funciones, palabras clave, clases, atributos, etiquetas, etc. más usadas en programación web: HTML, entidades HTML, CSS, JavaScript, JQuery, PHP, Mysql y uno muy especial para el módulo modrewrite para reescritura de URL en Apache:

    http://yensdesign.com/2008/12/cheat-sheets-pack-for-webmasters/
    http://www.emezeta.com/articulos/emezeta-card-modrewrite-cheat-sheet

    Y un «bonus», también de emezeta.com, otro cheat sheet de PHP: http://www.emezeta.com/articulos/emezeta-card-php-cheat-sheet

    A disfrutarlo XD

    PHP: eregi_replace() y UTF-8 (Problema y solución)

    0

    Esto creando una nueva web, y como ya deberíais saber, los desarrolladores de PHP decidieron que la versión 6 funcionaría, por defecto, con el charset utf-8. Los que esteis ya implementando estos cambios en vuestros proyectos, conocereis los quebraderos de cabeza que dan tanto mySQL como PHP sino están bien configurados (uno de ellos lo comente hace un tiempo aquí).

    Pues bien, hoy me he topado con otro, que me ha tenido todo el día dandome cabezazos contra la mesa, hasta que por fin he descubierto que leches pasaba.
    (más…)

    Appserv 2.5.10 y 2.6.0

    0

    Hace unos días se han publicado dos nuevas versiones de está suite de programación de PHP (Apache, PHP, phpmyadmin y MYSQL). La novedad radica en que la nueva versión 2.6.0 trae la versión 6 de PHP aun en desarrollo, lo que nos permitirá probar las nuevas características de esta versión del lenguaje.

    Appserv 2.5.10

  • Apache 2.2.8
  • PHP 5.2.6
  • MySQL 5.0.51b
  • phpMyAdmin-2.10.3
  • http://prdownloads.sourceforge.net/appserv/appserv-win32-2.6.0.exe?download

    Appserv 2.6.0

  • Apache 2.2.8
  • PHP 6.0.0-dev
  • MySQL 6.0.4-alpha
  • phpMyAdmin-2.10.3
  • http://prdownloads.sourceforge.net/appserv/appserv-win32-2.6.0.exe?download

    Ir arriba