¿Ha comprobado la velocidad de su sitio web recientemente con host-tracker.com? Si no, ¡deberías!

Nos complace anunciar que finalmente hemos lanzado la herramienta "Comprobación del tiempo de respuesta" para diagnosticar el mal rendimiento del sitio web. La velocidad es una de las cosas más importantes en el flujo de trabajo del sitio web, ya que afecta no solo a los rankings de Google, sino también a las conversiones de sus visitantes. Aquí en este artículo:

▶​ ¿Qué componentes componen el tiempo de carga de la página?

▶​ Optimización de velocidad del sitio web.

▶​​ ¿Cómo medir el tiempo de respuesta de su sitio web con HostTracker?

Nos complace anunciar que finalmente hemos lanzado la herramienta "Comprobación del tiempo de respuesta" para diagnosticar el mal rendimiento del sitio web. La velocidad es una de las cosas más importantes en el flujo de trabajo del sitio web, ya que afecta no solo a los rankings de Google, sino también a las conversiones de sus visitantes. Un estudio reciente muestra que los visitantes no están dispuestos a esperar más de 3 segundos para cargar una página. Y, de verdad, todos sabemos que esperar un sitio web de carga lenta puede parecer una eternidad cuando estás tratando de obtener información vital. En realidad, un sitio web vago puede costarle a su negocio. Lo que realmente importa es que simplemente dar algunos pasos para optimizar el rendimiento del sitio web puede marcar una gran diferencia. Entonces, veamos algunas causas comunes de un sitio web lento y cómo puede acelerar estas cosas.

¿Qué componentes componen el tiempo de carga de la página?

  1. DNS lookup tiempo - la cantidad de tiempo que lleva asignar un nombre de dominio a una dirección IP equivalente que se va a encontrar.
  2. Tiemppo de conección (TCP) - cuánto tiempo lleva establecer una conexión con el servidor web.
  3. Tiempo para obtener byte primero (TTFB) - el tiempo que lleva obtener la respuesta del servidor, así como el intervalo, ya que el servidor recibe una solicitud HTTP hasta que el servidor devuelve el primer byte de la respuesta.
  4. Tiempo para descarga (Tiempo de contenido) – el lapso de tiempo entre el inicio y el final de la carga de contenido.

Nota: Si usa el Certificado SSL para una conexión segura, necesitará un tiempo adicional para la autenticación, lo que significa tiempo adicional para establecer un vínculo entre su servidor web y un navegador.​

Todos estos componentes juntos representan el tiempo de respuesta de la página. Vea, es muy posible que su sitio web sea lento debido al problema con una de las cinco cosas mencionadas anteriormente.

Optimización de velocidad del sitio web​

La velocidad de carga del sitio web depende de varios factores y cada uno de ellos puede contener las cosas. Descubramos los motivos más comunes por los que la velocidad de su sitio web puede ser lenta.

Cuando algo está mal con el sitio web en sí:

  1. Objetos de manos terceros.​ Los diferentes complementos de terceros alojados en la página pueden ralentizar su sitio web. Aunque los servicios más potentes como Google Analytics integran estos scripts de manera sincronizada y sin interrupciones para el rendimiento del sitio web, aún colocar complementos de terceros provocará un retraso en la carga ya que cada uno de ellos suma la cantidad total de solicitudes que se envían. Aunque la velocidad del sitio web se ve afectada por varias cosas, sin embargo, se ve afectada principalmente por la cantidad de solicitudes HTTP que realiza su sitio web. Entonces, la regla de oro de la optimización es el sitio web de menos peso para llevar, más rápido funciona.

  2. Medios de otras fuentes.​ Cuantos más archivos de medios externos haya en la página, más tardará en cargarse su sitio web. Este contenido voluminoso no solo tiene un impacto negativo en la velocidad de la página web, sino que también es una de las formas más seguras de hacer que los visitantes se vayan. ¿Cómo se puede evitar? Primero, coloque los medios de otra persona con moderación; En segundo lugar, use formatos de archivos gráficos adecuados; En tercer lugar, aproveche el almacenamiento local confiable. Si haces un par de estas cosas, ¡verás mejoras significativas en muy poco tiempo!

  3. Código voluminoso/SQL ineficiente. Un código ineficaz o consultas de bases de datos no optimizadas pueden tener un efecto realmente degradante en el rendimiento de su sitio web. Considere hacer algo de optimización de código, como editar algunos scripts, HTML, código CSS, etc. o la optimización de la base de datos, como agregar algunos índices, alterar las consultas, modificar la estructura, etc. Los problemas con el código suelen ser los culpables de reducir el rendimiento de su sitio web.

    Cuando su hosting está matando su velocidad:

  1. DNS – el destino de su sitio web depende de la elección del servidor DNS que realice. Cuanto más rápido sea su servidor DNS, más rápidamente se entregará el contenido en su página.

  2. La ubicación del centro de datos. No descuides la geografía Es importante asegurarse de que sus visitantes accedan al centro de recopilación de datos más cercano. Comprender el tiempo empleado en la transmisión de información le permite tener una mejor idea de la experiencia del usuario que está brindando, porque sabe que lleva tiempo que se entreguen los datos. Si el sitio es un recurso global, se recomienda utilizar CDN (Content Delivery Network), es decir, una red de servidores web distribuidos globalmente que se utiliza para entregar contenido del sitio web a los usuarios finales locales lo más rápido posible. Básicamente, aloja sus archivos en toda la red de este servidor y los entrega desde la ubicación más cercana. Vale la pena señalar que en los últimos años la popularidad del alojamiento en la nube se ha disparado. No es de extrañar, ya que cuesta menos, ofrece más y ofrece la oportunidad de beneficiarse de una flexibilidad infinita.

  3. Elegir el servicio de alojamiento web equivocado. La realidad es que a veces el mayor problema con el rendimiento de su sitio web es que requiere simplemente más recursos de los que puede proporcionar su servidor web. Considere la posibilidad de buscar una empresa de alojamiento web que mejor se adapte a sus necesidades. No hace falta decirlo: elegir una buena empresa de hosting es la clave del alto rendimiento del sitio web.

¿Cómo medir el tiempo de respuesta de su sitio web con HostTracker?​

En la ventana Comprobación del tiempo de respuesta, ingrese su URL, nombre de la tarea y especifique el valor de Timeout.

Nota: cada vez que su valor de velocidad exceda este umbral, recibirá una notificación.

Armado con esta herramienta, siempre estará actualizado sobre la carga de su sitio web: las estadísticas del sitio web y el historial de eventos siempre están disponibles en un formato conveniente (consulte la imagen anterior).

Espero que disfrutes este articulo! Recuerde que lo más difícil en la optimización a menudo es simplemente comenzar.

more blog
¡Gracias por su atención!
 
Iniciar sesión
Crear una cuenta
Precios y planes
Nuestra red
Home > Blog
Host-Tracker under Windows Azure (English)

Those, who actively involved with the Web, should know HostTracker, a company from Ukraine, which has been supporting one of the leading global web monitoring services since 2004. Its goal is to monitor site health and accessibility in near-real-time access. Using alert message system, HostTracker allows to reduce downtimes, to improve quality of service for users, to quickly localize troubles...

​Those, who actively involved with the Web, should know HostTracker, a company from Ukraine, which has been supporting one of the leading global web monitoring services since 2004. Its goal is to monitor site health and accessibility in near-real-time access. Using alert message system, HostTracker allows to reduce downtimes, to improve quality of service for users, to quickly localize troubles, and etc.

Architecturally, HostTracker includes a server-based hub, acting both as a data collector and control center, and a series of software agents, launched in various regions – typically using the equipment operated by major providers, hosters and affiliates. The geographically distributed architecture provides common system reliability and also allows collecting data in terms of access speed, bandwidth and other key performance characteristics on regional level – a critically important feature for the international business.

The first version of HostTracker, which is still functioning and providing services for tens of thousands of customers, was Linux based. Today, it is supported by nine control servers, located and organized in two DPCs on collocation principle, and few dozens of agents. Considering that the final objective of web monitoring is focused on increasing the uptime of client-based web resources – whereas 95% of HostTracker customers were able to increase it up to 99% – then, performance and accessibility of the service itself are not just critical, but rather fundamental parameters that influence the whole business. Theoretically, HostTracker should demonstrate accessibility close to 100%. However, an extensive growth of the service made this task hard to solve.

HostTracker was facing constantly increasing network traffic – a problem for seamless operation of the service. Inability to add new control servers on-the-fly, difficulties when maintaining not uniform and multiple-aged hardware was another limiting factor. Moreover, the desire to develop the service through wider protocol and network service support was meeting certain obstacles. “Unfortunately, for Linux there was a limited choice of ready-to-use solutions and libraries, while inventing something completely new was difficult”, says Artem Prisyazhnyuk, HostTracker director. “We had an idea of reviewing the stack of technologies we used for a more sophisticated one and after taking a closer look at the .NET platform, its potential in terms of scalability and network support, I realized that was exactly the thing we had been looking for.”

It was sure that migrating to a completely different platform should be a complex task – the project extended over three years. However, it was like blessing in disguise: during this period, the world has seen the cloud computing that seemed an ideal tool for solving both the scalability problem and putting aside one’s own whole infrastructure. Besides, the PaaS model allowed to remove most of the effort in terms of administering the solution and to control the application as a self-contained entity, to the extent of complete automation, and thus, Windows Azure had in fact no alternatives.

As a result, the second version of HostTracker, commercial operation of which started in May 2012, is already functioning under Windows Azure. Its central ingredient is realized as Web Role and associated with SQL Azure Database – it provides external portal, analytics and report generation, control of monitoring applications. The latter are ensured with instances of Worker Role, which also use SQL Azure Database to store their data and to provide the service scalability depending on the network loading. Agents are functioning as they did before, with the viability of their transfer to Windows Azure being considered.
Now, HostTracker uses HTTP/HTTPS and ICMP protocols to monitor specific ports, including various methods (HEAD/POST/GET), and etc.
 

HostTracker instant check



Alarm reporting is available via email, SMS and instant messages. The customer can receive reports with statistics about resources being controlled and their performances. You can spend only 6 minutes to make monitoring settings for five sites, while the average response time in case of failure is limited by a couple of minutes, and it takes 1-3 minutes more to inform the customer about the problem. Using this service, anyone can check any site, including access from various regions.

 As a result, if on the one side the transfer to the .NET platform itself gave us the potential to modernize HostTracker, to optimize the application architecture and realize new internal functions, then, on the other side, the migration to the cloud allowed to refuse from less important, though time consuming activities such as administering the solution, and, first of all, to reach necessary performance indicators. Microsoft, for all basic Windows Azure services, declares 99,9% accessibility and guarantees monthly refunds, should this indicator be lower. This creates a firm ground for operating such services like HostTracker, as the accessibility is the most critical parameter for these applications. Using the cloud infrastructure also provides a better protection for the service: unauthorized access to the application and many types of attacks are effectively excluded, while the data safety is ensured by triple reservation.

HostTracker received another advantage from abandoning its own infrastructure. The service’s performance characteristics are also rather critical, for they directly affect the failure reporting system operation. In this respect, Windows Azure is virtually a drainless source of computing power. This means that by timely starting additional monitoring instances you can support HostTracker functioning parameters on the necessary level. Moreover, the cloud environment is exactly what you need in order to make this process almost fully automatic, excluding further need for direct control.

more
Host Tracker: оповещение о падении сайта только по делу (Русский)

Ни один человек не способен круглосуточно осуществлять мониторинг работоспособности сайта. Более того, ресурс может быть недоступным в другом регионе, и это руководитель никак не отследит.
И именно для решения этих задач предназначен сервис ХостТрекер, который мониторит доступность сайта. Он фиксирует «падение» сайта, анализирует проблему и отправляет тревожный сигнал администратору или руководству ресурса...

Разумеется, одной из первоочередных задач для любого руководителя сайта является обеспечение бесперебойной работы ресурса. Однако периодические «падения» сайта неизбежны, и главное тут — вовремя отследить и решить проблему.
Очевидно, что ни один человек не способен круглосуточно осуществлять мониторинг работоспособности сайта. Более того, ресурс может быть недоступным в другом регионе, и это руководитель никак не отследит.
И именно для решения этих задач предназначен сервис ХостТрекер, который мониторит доступность сайта. Он фиксирует «падение» сайта, анализирует проблему и отправляет тревожный сигнал администратору или руководству ресурса.
При этом очевидно, что ложная тревога никому не нужна, и принцип «лучше перебдеть, чем недобдеть» — не лучшая стратегия в данном случае. Поэтому в работе сервиса необходима исключительная точность и адекватность в оценке проблем.

Таким образом, перед ХостТрекером стоит ряд важнейших задач: отследить возникновение проблемы и вовремя уведомить об этом клиента, при этом исключив ложную тревогу, и рассчитать uptime, исходя из наилучшего и наихудшего варианта развития событий.

Каким же образом регистрируется непосредственно «падение» ресурса?

Как только клиент добавляет свой сайт, с заданным интервалом в диапазоне от минуты до часа система посылает ему запрос. При этом такая проверка совершается с независимых серверов, разнесенных по всему миру, для осуществления географически распределенного мониторинга. На данный момент таких серверов более пятидесяти. Случайным образом выбирается конкретный агент.
 

моментальная проверка


В случае возврата ошибки при проверке, перепроверка запускается для еще пяти-семи независимых агентов. Если в большинстве случаев наличие проблемы подтверждается, ресурс считается «упавшим». Если же остальные агенты не зафиксировали неполадок, считается, что локальная проблема возникла на конкретном агенте.
В случае необходимости определить, «поднялся» ли сайт, действует тот же алгоритм. Он практически исключает возможность ложной тревоги, таким образом, оберегая покой клиентов сервиса. Недоступность ресурса устанавливается лишь после многократных проверок с определенным интервалом.

Конечно, гарантировать на сто процентов, в каком именно состоянии сайт был между проверками, невозможно. Однако, все же с наибольшей вероятностью в промежутке между выдававшими ошибку проверками сайт «лежит». Правда, если после ошибки начинается восстановление, между проверками ресурс может и работать. Собственно, данный сценарий ложится в основу расчета оптимистичного uptime. Вариант же «лежания» сайта между проверками становится отправной точкой для расчета пессимистичного сценария.
Оптимистичный вариант берется в расчет при статистических исследованиях, а вот при уведомлении клиентов данные указываются по пессимистичному.
Таким образом, благодаря расчету всех вариантов и тщательному всестороннему мониторингу, клиент получает своевременные уведомления только в случае настоящих проблем и может получить полную и достоверную картину происходящего.

more
Compartir:
Enviar a Twitter Enviar a  Facebook Enviar a LinkedIn Compartir en Google+
Blogs:
HostTracker blog HostTracker page on Facebook