3. Desarrollo
En esta fase se desarrollan los gráficos, el código HTML y los scripts
necesarios. Aquí aparece el problema, los responsables de proyectos buscan que
todo esto se haga con una sola aplicación.
Es un error buscar ese tipo de integración, no solamente por cuestiones de
independencia tecnológica, sino porque el código generado suele ser ofuscado,
dependiente de varios ficheros "desconocidos" y muy difíciles de
optimizar.
Es mejor dividir el desarrollo en dos partes claramente diferenciadas y que
se podrán desarrollar en paralelo.
- Desarrollo gráfico y HTML
- Desarrollo de programas
3.a Desarrollo gráfico y HTML
Con las herramientas existentes, normalmente es el mismo diseñador el que se
encarga del diseño gráfico y la maquetación (sobre todo en proyectos
pequeños). Cada diseñador tiene sus propias herramientas y distintas
plataformas (Dreamweaver sobre Windows y Mac principalmente). Esto no debe
servir de excusa para diseñar los programas del servidor en aquellos lenguajes
y recordsets soportados por la herramienta (i.e. ASP y SQL Server,
o Cold Fusion).
Lo mejor que se puede hacer es que el o los diseñadores desarrollen todas
las páginas con HTML estático y texto falso con su herramienta
favorita, luego el texto falso se reemplazará por
las partes de código (PHP) que generen la salida deseada. Para evitar problemas
de integración, es mejor que los diseñadores trabajen asistidos por los
programadores para decidir que tipo de texto salida se puede poner en cada
página.
Para facilitar la posterior integración con los programas, a la hora de la
maquetación en HTML hay que tener en cuenta lo siguiente:
- Poner comentarios en HTML del tipo de salida o consulta en cada sección.
- Usar desde el principio nombres de fichero con las extensiones
correspondientes que se usarán en la versión definitiva (php, phtml, pl,
cgi, etc.). De esta forma se evitarán problemas de enlaces por
inconsistencia en los nombres.
- Usar siempre enlaces relativos, de esta forma se podrá mover fácilmente
los programas a distintos directorios o servidores virtuales.
- Poner todo lo que sea código JavaScript o imágenes en subdirectorios y
usar referencias relativas.
- Grabar todos los ficheros en formato UNIX y con hora GMT.
3.b Desarrollo de programas
Al mismo tiempo que el o los diseñadores preparan el código HTML, el o los
programadores deben preparar los programas usando HTML muy simples para probar
la base de datos y ejecución de los programas.
Las herramientas que se usen en estas fases serán normalmente aquellas que
use el programador y que son básicamente un editor de texto y acceso al
servidor por medio de TELNET (o SSH). La ventaja principal es que permiten a los
programadores libertad de horarios y de
ubicación, ya que la mayoría de este trabajo puede ser realizado
remotamente.
En caso de trabajo en grupo se recomienda el uso del CVS, ya que permitirá el
control de concurrencia, cambios, parches y versiones con mucha facilidad.
Lo más importante es tener acabada la mayor parte de la programación antes que se acabe el
diseño e integrar paulatinamente los módulos acabados en aquellas páginas ya
finalizadas por los diseñadores. Además se debe controlar periódicamente que
los enlaces y referencias de las páginas HTML sean válidos y
relativos.
Pruebas
Cuando el desarrollo ya está en un estado avanzado se pone on-line para que pueda ser
consultado por un grupo de gente (cliente y desarrolladores) que evaluará o propondrá cambios y
comenzarán las pruebas definitivas de tiempos de respuesta y de descarga.
Además de los cambios inevitables que surgirán cuando el cliente vea como
funcionan las páginas hay que ir realizando pruebas para verificar que
los tiempos de respuesta, retorno y de descarga son adecuados y controlar que el
sistema soporta la cantidad de conexiones simultáneas que pueden haber.
Para realizar estas pruebas no hacen falta herramientas muy sofisticadas, con
el ab (del ABuse Benchmarker, que viene con la distribución del Apache)
podemos realizar la mayoría de las pruebas y obtener datos con una precisión
suficiente (para más informacion, ver optimización del Apache y
del PHP).
Pruebas de tiempos de respuesta y retorno
En esta prueba nos interesa saber cuanto tiempo tarda el servidor en generar
la salida HTML. Podemos tener una aproximación bastante buena si medimos el
tiempo total que tardan en bajarse las páginas en una red local (como el ancho
de banda es elevado, el tiempo de descarga es prácticamente igual al tiempo de
retorno).
El siguiente ejemplo lo haremos sobre el servidor de Bulma y obtendremos el tiempo de
retorno para 10 (-n 10) de conexiones en serie (-c 1). Es importante que las
pruebas se hagan desde un ordenador distinto al servidor para obtener datos mas
fiables.
$ /usr/sbin/ab -c 1 -n 10 http://bulma.net/
...
Document Path: /
Document Length: 28073 bytes
Concurrency Level: 1
Time taken for tests: 0.433 seconds
Complete requests: 10
Failed requests: 0
Total transferred: 284050 bytes
HTML transferred: 280730 bytes
Requests per second: 23.09
Transfer rate: 656.00 kb/s received
Connnection Times (ms)
min avg max
Connect: 0 0 0
Processing: 42 42 43
Total: 42 42 43
Los resultados nos indican que el tamaño del HTML es de 28.073 bytes, y que
el tiempo total para las 10 conexiones ha sido de 0.089 segundos, por lo que el
tiempo de descarga de cada conexión es de 0.0433 segundos (si hacéis 1/0.0433
veréis que el valor es muy cercano a 23.09 indicado por el valor Requests
per second).
Hay otro dato importante, Transfer rate nos indica el tráfico que ha
sido capaz de generar el servidor en Kilobytes por segundo. Si llevamos eso a
kilobits por segundo (multiplicar el valor por 10 para obtener una aproximación
debido a los overhead del TCP/IP), veremos que el servidor (un
Linux PIII, 500 Mhz, con Apache, PHP y MySQL) es capaz de
saturar una línea de ¡6 mbps!. En este caso no habrá problemas de saturación
de CPU a menos que tengamos una línea de Internet con una capacidad
superior.
El segundo parámetro a investigar es la cantidad de conexiones simultáneas
que puede soportar. La estimación de conexiones simultáneas es compleja e
incierta, pero una buena aproximación sería estimar las conexiones promedio
por día y multiplicar ese valor por 3 a 5 para obtener los picos que veríamos
en el servidor.
Si calculamos que se servirán unas 200.000 páginas diarias (en España es
un servidor bastante importante), tendremos que por segundo puede haber unas 2.3
conexiones (200.000/86.400 segundos día). Si multiplicamos ese valor por 5 nos
queda unas 11.5 conexiones por segundo de pico.
Con las pruebas hechas anteriormente ya sabemos que el sistema soporta el
doble (23.09), pero ahora haremos una mejor aproximación con mayor cantidad de
conexiones simultáneas. Lo más sencillo para calcular la cantidad de
conexiones simultáneas es usar el mismo valor de conexiones por segundo.
En
nuestro caso redondeamos a 12 la cantidad de conexiones simultáneas y subimos
la cantidad de pruebas a 100. Así la prueba será:
$ /usr/sbin/ab -c 12 -n 100 http://bulma.net/
...
Concurrency Level: 12
Time taken for tests: 4.450 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 2886876 bytes
HTML transferred: 2852680 bytes
Requests per second: 22.47
Transfer rate: 648.74 kb/s received
Connnection Times (ms)
min avg max
Connect: 0 0 6
Processing: 41 501 1973
Total: 41 501 1979
En este caso observamos que el sistema soporta perfectamente esas conexiones
simultáneas sin casi degradación en los tiempos de retorno (0.0445 segundos).
Tiempos de descarga con conexiones diversas
La siguiente tabla los resultados de la ejecución de ab -c 1 -10 http://bulma.net/.
| Tipo de
conexión |
Tiempo de
descarga (seg) |
Solicitudes por
segundo |
Transferencia
de datos (KB/seg) |
| LAN (100 mbps) |
0.04 |
23.00 |
656.00 |
| Internet WAN (2mbps) |
0.36 |
2.82 |
79.88 |
| Internet WAN (2 mbps) |
0.39 |
2.57 |
72.74 |
| Internet WAN (4 mbps) |
0.49 |
2.07 |
58.65 |
| ADSL compartida NAT (2 mbps) |
0.57 |
1.74 |
49.33 |
| ADSL (2 mbps) |
0.62 |
1.60 |
45.33 |
| ADSL (512 kbps) |
0.85 |
1.17 |
33.18 |
| ADSL (2 mbps) |
0.90 |
1.11 |
31.56 |
| Internet WAN (256 kbps) |
0.91 |
1.10 |
31.55 |
| ADSL (256 kbps) |
1.29 |
0.78 |
21.95 |
| ADSL (256 kbps) |
1.43 |
0.71 |
20.16 |
| RDSI (64 kbps, compresión PPP) |
3.05 |
0.32 |
8.96 |
| RDSI (64 kbps) |
3.99 |
0.25 |
7.18 |
| Modem (56 Kbps) |
4.01 |
0.25 |
7.16 |
| Modem (56 Kbps) |
6.01 |
0.17 |
4.70 |
| RDSI compartida NAT (64 kbps) |
11.43 |
0.10 |
2.48 |
Tabla de tiempos de descarga para Bulma
Puede observarse que con la conexión más lenta, el tiempo total de descarga
es de 11.43 segundos. Sin embargo, si analizáis el HTML generado por
bulma.net, veréis que una vez leídos los primeros 1498 caracteres
(cabeceras y METAs incluidos), el navegador ya puede mostrar el logo
superior,
por lo que el tiempo de de pre-visualización para el caso más lento queda en:
Tvis = (1498 Bytes/1024) / 2.48 KBs =~ 0.6
segundos
Hemos bajado el tiempo de respuesta "percibido" por el usuario de
11.43 a 0.6 segundos! sólo cambiando la estructura de las tablas (principalmente
evitando una sólo tabla que engloba a todo el contenido de la página).
Si tomamos en cuenta el caso mayoritario hogareño (modem de 56kbps), los
tiempos serán:
Tvis = (1498 Bytes/1024) / 4.70 KBs =~ 0.31
segundos
En este caso se logra una mejora de 6 a 0.31 segundos.
En ambos casos los tiempos son muy buenos, pero una página web, sobre todo
si se trata de páginas genéricas, no debería superar los 2 segundos.
- No confiar en la velocidad de la red local: la moraleja más
importante de la tabla anterior, es que aunque la estructura de las páginas
esté muy mal definida, el tiempo de visualización
será ínfimo comparado con los mejores tiempos que se puedan obtener a
través de Internet. En el caso de pruebas de red local, la página
estará descargada en menos de la mitad de una décima de segundo (0.04 seg),
que está muy lejos de los 6 segundos del caso "normal". No
olvidar que hay que hacer pruebas y estimaciones no sólo en la red local
donde se hace el desarrollo, sino con también con una
navegador estándar y conexiones con modem. Las diferencias son
enormes y pueden generar sorpresas desagradables.
Cálculo del ancho de banda necesario
Hasta ahora hemos hablado de temas de tiempos de respuesta y mejoras en el
diseño de las tablas, pero queda pendiente un tema importante y a menudo
olvidado, tanto por los clientes como por los desarrolladores, el ancho de banda
necesario para un sitio web.
La forma más común (y empírica) para calcular los requerimientos máximos es tomar el
promedio de tráfico diario y multiplicarlo por 3 (como mínimo) para obtener el
tráfico máximo aproximado. En el ejemplo mencionamos 200.000 páginas por día
(2.3 por segundo). Si el promedio de cada página es de unos 28.000 bytes
(suelen ser un poco más debido a las imágenes que se descargan una vez),
entonces el tráfico promedio y máximo serán:
Trafpromedio = 2.3 páginas/seg * 28.000 * 10 = 644
kbps
Trafmaximo = 2.3 páginas/seg * 28.000 * 3 * 10 = 1.932 kbps =~
2 Mbps
Esto nos da una idea del tipo de línea a Internet (o ancho de banda) que
tendremos que contratar para atender adecuadamente los picos de tráfico. Esto
significa, en España, entre 600.000 y 1.500.000 de Ptas. mensuales (€ 3.600 y
€ 9.000 respectivamente). El coste del ancho de banda no es nada despreciable
en España y Europa en general. Y mucha gente se olvida de hacer estas
estimaciones a priori, y luego se encuentran que la calidad que ofrecen es muy
mala por falta de previsión.
4. Producción
El sitio ya entra en producción y su acceso es público. Aunque esta parece
la más sencilla de las fases, es la más cara y difícil de conseguir. Hay que
actualizar los datos para que el sitio sea interesante y visitado y además
asegurase que funcione las 24 horas del día, los 7 días de la semana (24x7).
Si habéis usado Linux, Apache, MySQL/Postgres y PHP/Perl oPython (LAMP), no
tendréis ningún problema en sobrevivir muy tranquilamente a esta fase. Y
quedarás como un gurú super-profesional ;-)
Ricardo Galli
gallir@uib.es
Todos los derechos reservados
Los copyright de los sistemas mencionados son propiedad de los respectivos dueños. | 
