Dreamhost y Rails: recomendaciones

En este post Fernando nos enlaza dos artículos interesantes a la hora de preparar nuestra aplicación Rails y lanzarla desde Dreamhost, el hosting que, como puede verse a la izquierda, recomendamos desde esta bitácora.

<p>Iba a extenderme algo en la respuesta, pero al final me he liado y me ha dado para un post completo, así que creo que sería de recibo explicar con un poco más de detalle qué me ha sucedido con Dreamhost.</p>


<p>En Dreamhost tengo, como sabreis, mi blog SobreRailes.com y algunas aplicaciones de juguete como el SudokuOnRails y el Diccionario Malacitano, que me sirve para aprender a desplegar aplicaciones y jugar a ser webmaster :)  También tengo PlanetaMalaga.net, un wiki privado para mis cosillas, las hojas de estilo de mi otro blog (Yogur Griego) y un script de rotación de imágenes en <span class="caps">PHP</span>.  Tengo además un servidor de Subversion y hago copias de seguridad semanales usando <code>rsync</code>.  Mi uso de <span class="caps">CPU</span> diario debe de haber venido siendo de unos 20 minutos de <span class="caps">CPU</span> _diarios, minuto más, minuto menos.</p>


<p>Pues bien, resulta que en mi infitia sabiduría, se me ocurrió hacer dos aplicacioncitas de juguete en Rails, una de ellas es la que mencionaba en SobreRailes que pinta una especie de &#8216;fortune&#8217; de Brian Eno y la otra es una que, dependiendo de la <span class="caps">URL</span> de procedencia, inhabilita los objetos <span class="caps">DOM</span> del formulario de Blogalia (script que usé para cerrar los comentarios de una historia mía en Yogur Griego).  Dado que Blogalia no permite modificar la plantilla para las historias, lo puse en la única plantilla, que es la misma para comentarios y página principal.  Conclusión: cada <strong>carga</strong> de mi página en Yogur Griego suponía varias invocaciones a mi cuenta de Dreamhost: la hoja de estilo, la imagen de la cabecera, el script para la estrategia oblicua de Brian Eno y el comprobador de si se deben cancelar los comentarios o no en la historia.</p>


<p>Al cabo de un par de días, recibí un correo de Dreamhost Support diciendo que mi uso de <span class="caps">CPU</span> estaba excediendo los límites permitidos de 60 minutos de <span class="caps">CPU</span> al día: ¡exactamente 140 minutos de <span class="caps">CPU</span>!  (Debo decir que Yogur Griego no es un blog especialmente concurrido pero sostiene una media de 300 visitas diarias, lo que supone 600 invocaciones a distintas aplicaciones Rails, más el uso de Sobrerailes&#8230;)  En definitiva, que analizando los logs el proceso ruby se estaba adueñando toda la <span class="caps">CPU</span>.  Investigué los environments y una de ellas, para más inri, estaba en modo <em>development</em>, lo que no cabe duda de que agravaba el problema.</p>


<p>Debo decir que el correo de Dreamhost incluía enlaces a su wiki donde uno puede informarse de la política de uso de <span class="caps">CPU</span> y cómo activar las estadísticas, y el tono del mismo era más de aviso que de amenaza (aunque no me cabe la menor duda de que de haber seguido así la cuenta habría sido cancelada o migrada a un servidor para apestados)</p>


<p><strong>Por eso, a la hora de desplegar aplicaciones Rails, conviene activar las estadísticas de uso de <span class="caps">CPU</span> antes y después, para poder estar al tanto de lo que pueda ocurrir</strong>.</p>


<p>Nuevamente, me reafirmo en mi opinión acerca de Dreamhost: en relación calidad/precio es más que correcto (por 8 dólares al mes tengo un montón de webs alojadas y además espacio en disco más que de sobra), pero definitivamente <strong>no</strong> lo recomendaría para alojar webs destinadas a recibir mucho tráfico (no tengo muy claro si existe algún alojamiento compartido que pueda recomendarse para una web de mucho tráfico con Rails, de todas maneras)</p>
blog comments powered by Disqus