Uno de los principales problemas que nos hemos encontrado este año ha radicado en una deficiencia en el control del consumo ejercido por las páginas webs residentes en los servidores. Hasta hace unas semanas, no se controlaba el consumo individual de cada página web, sino el consumo global del servidor. Este tipo de gestión nos ha acarreado muchos problemas ya que al no tener monitorizadas las webs, al aumentar las visitas y consecuentemente el consumo de éstas, provocaba pérdidas de rendimiento en el servidor afectando el resto de usuarios.
Así pues el control realizado a nivel global que hasta la fecha nos había sido útil, se había convertido en un espejismo que no mostraba la realidad en los procesos afectados.
El control se hace necesario para poder mantener unos índices de calidad, en el caso de servidores web los índices de calidad son la velocidad de carga, la estabilidad del servicio y la seguridad. Para poder ejercer un control han de existir límites. Sin límites marcados el control se vuelve estéril y carente de significado.
Por ejemplo, cuando freímos un huevo controlamos el tiempo y la temperatura. De manera consciente limitamos la potencia de cocción y ajustamos el tiempo de exposición para que el huevo quede correctamente cocido. Si nos pasamos de tiempo o el fuego está muy fuerte, el huevo se quemará: Los límites se han originado como producto de la voluntad de ejercer un control de la situación.
Era evidente que se debía cambiar la relación de control con el servidor, pasando de un control global a un control individual de los consumos de cada web. El dilema que se nos presentó era, si el control de cada cliente debía recaer sobre la empresa, haciendo ésta de “policía” del consumo o bien si debía ser el mismo usuario que controlara su consumo dotándole de las herramientas necesarias y marcando unos límites en el consumo.
Nos encontramos hoy en día en un mercado muy globalizado en que la reducción de costes se hace importante para poder competir con otras empresas. La primera opción en que la empresa ejercía de “policía” del consumo nos empujaba a un incremento en los costes, y además que tampoco era la opción más lógica ya que la comunicación entre servidor / administrador de sistemas / cliente al ser asimétrica genera insatisfacción.
La segunda opción nos pareció más razonable ya que el usuario, después de ser informado por los nuevos límites marcados y dándole las herramientas de control necesarias como son estadísticas de consumo, podrá sentir que es él quien controla la situación: optando por ampliar el servicio a uno superior o restringiendo el consumo de su página web mediante optimizaciones. La comunicación se vuelve simétrica entre las tres partes.
Limites del servicio web
Los límites marcados han sido obtenidos en base a una relación consumo/coste de cada servicio. Intervienen tres factores clave que delimitan el consumo del servicio web:
- Conexiones HTTP simultáneas: Es el número de conexiones apache que puede tener abiertas cada página web. Este límite evita saturaciones por exceso de peticiones en el global del servidor.
- Solicitudes HTTP diarias: Es el número de solicitudes que una visita ha realizado al servidor. El consumo de solicitudes por persona vendrá delimitado por el número de elementos a mostrar en una página web. Por ejemplo si se tiene una página html con tres imágenes, las solicitudes por visitante serán tres. El número de solicitudes por visita puede variar mucho entre páginas web, normalmente este valor fluctua entre 15 y 90 solicitudes por visita. Por ejemplo un Plan web podrá servir con una garantía de calidad entre (900 y 5.000 visitas diarias) dependiendo de la carga que suponga al servidor.
- Conexiones MySQL simultáneas: Es el número de conexiones simultáneas a la base de datos que puede tener una web. El valor de 15 conexiones es un valor muy elevado ya que una consulta suele tomar muy pocos milisegundos.
| Servicio |
Conex. HTTP simul. |
Solic. HTTP diarias |
Conex. MySQL simul. |
| Miniplan |
15 |
50.000 |
15 |
| Plan X |
15 a 30 |
50.000>100.000 |
15 |
| Plan Web |
25 |
75.000 |
15 |
| Plan Pro |
25 |
85.000 |
15 |
| Plan 10 |
30 |
100.000 |
15 |
| Cada alojamiento de un multidominio |
15 a 30 |
50.000>100.000 |
15 |
En el caso del Plan X, el volumen de solicitudes HTTP diarias irá en función del coste global del servicio. Equiparando los límites con las tarifas de los planes profesionales.
Nuevo servicio para planes profesionales
Para poder satisfacer las necesidades de recursos de aquellos usuarios que superan los límites del Plan 10, hemos desarrollado un nuevo servicio llamado Preserver.
La principal ventaja de este servicio es que se dispone de un producto que se encuentra entre un alojamiento compartido y un servidor dedicado. Obteniendo el beneficio de cada parte: La gestión y administración de un servicio compartido y la potencia de un servidor dedicado a un precio intermedio entre los dos servicios.
Se han desarrollado tres tipos de servicio que pueden visualizarse en la siguiente tabla:
| Servicio |
Conex. HTTP simul. |
Solic. HTTP diarias |
Conex. MySQL simul. |
| Preserver 50 |
50 |
150.000>250.000 |
20 a 80 |
| Preserver 75 |
75 |
250.001>350.000 |
20 a 80 |
| Preserver 100 |
100 |
350.001>450.000 |
20 a 80 |
Consideramos que a partir de un Preserver 100, las necesidades ya empiezan a ser más específicas y al usuario ya le sale más rentable estar en un servidor dedicado. Llegados a este punto, nos ponemos en contacto con el cliente para realizarle un presupuesto a medida y pueda seguir con el crecimiento de su web en Internet.
Límites en el servicio de correo
El servicio de correo se ha convertido en una necesidad importante en la actualidad. Hoy en día los usuarios de este servicio exigimos que el correo ya no sea lo más rápido posible si no que éste sea instantáneo. Lejanos quedan los recuerdos del correo postal dónde una carta urgente tardaba hasta 24 horas en llegar al destino (si este se encontraba cerca); se supone que por ello triunfaba el fax, porqué era instantáneo y por eso ha triunfado el correo electrónico. Hoy en día las empresas ya no pueden vivir sin el correo electrónico, suponiendo una gran pérdida de productividad si éste no funciona como debiera.
CDmon es consciente de todo ello, el servicio ha de ser rápido y estable al 100%, sin colas de espera y sobretodo, limpio de SPAM (correo no deseado). Ese es el compromiso de CDmon, pero por otra parte el usuario también ha de tener un compromiso con el servicio de correo y es hacer un uso racional dentro de los límites que nos ofrece tanto el software como el hardware. Lo que parece que no cuesta nada, como es enviar o recibir un correo electrónico se puede convertir en un problema si no existe un control. Como hemos comentado en la parte web, CDmon no controlaba hasta ahora el consumo individual de cada cuenta sino el consumo global de todo el servidor, a raíz de ello se ha generado incidencias que han provocado una deficiencia en el servicio. Al cambiar la gestión global por la individual nos ha sorprendido varias cosas:
- Un 2% de los buzones totales, contenían en la carpeta principal una media de más de 4.000 mensajes almacenados. Hemos encontrado usuarios con más de 40.000 correos electrónicos almacenados en la carpeta principal.
- Un 80% de los usuarios se validan mediante POP3 (un protocolo que tiene más de 20 años y sobrecarga el sistema si se realiza un mal uso), el 20% restante mediante IMAP (un protocolo de correo adaptado a los nuevos tiempos). El 95% de los usuarios que tienen más de 1000 mensajes almacenados en la carpeta principal, lo hacen mediante POP3. Se ha de mencionar para los que no lo sepan y es que POP3 nunca fue diseñado para almacenar los mensajes en el servidor.
- De los usuarios que usan POP3, hay un 2% que se conecta al servidor más de 3 veces por minuto.
Desde CDmon nos gusta dar el máximo de posibilidades a cada cliente, si quieres usar POP3, úsalo pero éste ha de tener unos límites. Encontrarte una cuenta de correo electrónico con más de 5.000 mensajes almacenados y que se conecta al servidor cada minuto, representa una carga al servidor equivalente a mil cuentas de correo que se conecten mediante POP3 una vez cada diez minutos y que no almacenen los mensajes en el servidor. El mal uso por desconocimiento (a nadie le gusta tirarse piedras encima de su propio tejado) provoca pérdidas importantes de rendimiento en el servicio.
No se puede controlar una situación si no existen límites marcados. Los límites marcan también las normas de uso, cada usuario sabiendo cuales son, le será más fácil adaptarse al sistema.
Los límites que hemos marcado son topes muy altos para un uso normal y frecuente del correo. Con ellos podemos garantizar la calidad requerida por los usuarios del servicio. Estos son:
- Espacio de la carpeta principal: El espacio de la carpeta principal queda limitado a un máximo de 999MB. Si se desea almacenar más correos en el buzón, se tendrán que mover a una carpeta secundaria dentro de la cuenta de correo mediante IMAP.
Número de mensajes almacenados en la carpeta principal: Se limita a un máximo de 1000 mensajes en el buzón principal. Si se desea almacenar más correos en buzón, se tendrán que mover a una carpeta secundaria dentro de la cuenta de correo mediante IMAP.- Número de correos enviados por día: Hay un límite de 500 mensajes enviados por día/ cuenta. Si se desea enviar más correos porque hay usuarios que disponen de listas de distribución, se puede usar el Mailman que dispone de sus propios límites. En el supuesto de que haya usuarios que utilicen otros sistemas, se deben poner contacto con el departamento Técnico, que estudiará el caso al margen.
Número de logins por hora en una cuenta POP3: Se debe limitar a un máximo de 10 logins por hora una cuenta pop3. Si necesita comprobar el correo cada minuto deberá hacerlo sobre IMAP, pero no sobre POP3 ya que sobrecarga el sistema.
Estos son los límites marcados para el servicio de correo en régimen compartido. Paralelamente estamos desarrollando un nuevo servicio de correo para aquellos usuarios que requieran de las ventajas que ofrece un servicio dedicado. En las próximas semanas presentaremos el producto, para todos aquellos usuarios que tengan una previsión de contratar este servicio pueden ponerse en contacto con el departamento comercial e iremos informando del estado del nuevo producto.
Este mediodía hemos desactivado la opción de solicitar nuevos pre-registros para los dominios .es IDN, tal y como describimos en nuestras condiciones.
© 2001-2007