Добавить в "Избранное" Вам нужно авторизоваться. Забыли пароль? Регистрация Сентябрь чт. 21 2017 г. в 21:41
Навигация
Хостинг от наших партнеров
Поиск
Рассылка



Отписаться
Статистика


Статьи

Медленная загрузка сайтов: основные причины, как с ними бороться

Источник: www.zenon.net
Добавлено: 2008-07-19 01:15:37

Передача данных по коммутируемой линии

Первая (и самая очевидная) причина медленной загрузки сайта - низкая скорость передачи данных от сервера клиенту. Обычно так происходит в том случае, если используется соединение с сетью Интернет по коммутируемой (телефонной) линии, то есть по обычному Dial-Up'у. Как правило, скорость соединения по такой линии не превышает 57600 Кбит/сек, но такая скорость скорее является идеальной и в условиях работы российских телефонных линий практически не достижимой.

Дело в том, что скорость свыше 33600 Кбит/сек определяется протоколами X2, k56flex, V.90, V.92, которым для работы нужно очень хорошее качество телефонной линии. Медная пара, на основе которой существуют большинство российских телефонных линий, проложена зачастую в малопригодных условиях для ее эксплуатации и не может обеспечить качественное прохождение сигнала. И даже если первоначальное соединение было установлено на скорости 57600 Кбит/сек, большинство модемов автоматически переходят на передачу данных по протоколу V.34 и понижают скорость, если определяют, что пропускная способность линии стала хуже. Поэтому реально можно рассчитывать на скорость соединения примерно 33600 Кбит/сек. Нетрудно подсчитать, что скорость передачи данных по такой линии будет 4.2 Кбайт/сек, соответственно, страница размером 10 Кбайт будет загружаться более 2 секунд. Конечно же, практически всегда используется сжатие данных, предусмотренное протоколом, что несколько увеличивает скорость. Однако, как минимум, нужно учитывать тот факт, что передается не только сама страница сайта, но и некоторые дополнительные служебные данные (например, http-заголовки).

Если же при передаче информации модем пытается подобрать оптимальную скорость, то данные в этот момент не передаются, и время загрузки страницы может затянуться до нескольких десятков секунд.

Передача данных по выделенной линии

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

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

Посмотреть маршрут и время задержки прохождения пакетов на различных участках от клиентского компьютера до сервера, на котором расположен сайт, можно с помощью утилиты traceroute (в *nix-системах) или tracert (в Windows), которая показывает список хостов, через которые проходят пакеты от локального компьютера до сайта.

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

Передача данных по ADSL

Проблема с загрузкой канала передачи данных также может возникать на выделенной линии, работающей по технологии ADSL. Аббревиатура ADSL (Asymmetric Digital Subscriber Line) расшифровывается как "Асимметричная цифровая абонентская линия", что подчеркивает изначально заложенное в этой технологии различие скоростей обмена данными в направлениях траффика к абоненту и от абонента. Как правило, скорость передачи от абонента ниже, чем скорость к абоненту. Ничего плохого в этом нет, поскольку большинству пользователей, подключенных по ADSL, скорость как раз нужна для того, чтобы быстро загружать на свой компьютер данные из сети Интернет.

В этом случае передача служебной информации (например, подтверждение принятия данных) от абонента к источнику создает траффик, который составляет малую часть от общей пропускной способности канала, большая же часть траффика в этом случае идет к абоненту. Если во время загрузки файла или страницы необходимая информация от абонента перестает поступать к источнику, то последний, как правило, на какое-то время прекращает передачу данных клиенту. Такое может случиться, если канал в направлении от абонента к серверу полностью загружен.

Динамические страницы, скрипты

Теперь рассмотрим причины медленной загрузки сайта, которые имеют непосредственное отношение к серверной стороне.

Очень часто низкая скорость загрузки сайта обусловлена медленным выполнением скриптов, формирующих динамический контент сайта. Как правило, это связано с ограничениями на использование ресурсов в рамках предоставляемых тарифных планов. Другими словами, пользователь хостинга не может использовать все ресурсы физической машины, на которой расположен его сайт. Такой механизм, реализованный теми или иными средствами, используют практически все хостинговые компании для предотвращения перегрузки или отказа всей физической машины из-за некорректно написанных скриптов отдельного пользователя.

Иными словами, каждый пользовательский процесс получает в свое распоряжение лишь часть ресурсов физической машины: часть оперативной памяти, определенное количество процессорного времени и т.д.

На низкую скорость выполнения скриптов могут влиять следующие факторы:

  • Использование неэффективных приемов программирования.

  • Обработка больших объемов данных

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

  • Обработка данных из медленных внешних источников.

    Предположим, что скрипт должен соединиться с внешним хостом и получить какие-то данные по http. Чем дольше будут передаваться данные из внешнего источника скрипту, тем дольше он будет выполняться.

  • Объем кода скрипта.

    Очевидно, что интерпретатор, выполняя скрипт, должен прочитать весь его код с диска. Соответсвенно, скрипт размером 10 Кбайт будет прочитан быстрее, чем скрипт объемом 1 Мбайт.
    Нужно также помнить о том, что скрипт сам по себе может иметь небольшой размер, но в то же время содержать в себе вызов (include) другого файла или нескольких файлов, которые в свою очередь также могут обращаться к другим скриптам. В результате такая вложенная структура скриптов может иметь внушительный объем.

  • Интерпретируемость.

    Практически любой скриптовый язык (Perl, PHP) почти всегда будет работать заведомо медленнее, чем программа, спомпилированная и оптимизированная непосредственно под инструкции процессора, на котором она будет исполняться.

    Конкретно в случае работы с PHP проблему во многом решает использование PHP-оптимизаторов (например, Zend Optimizer или Turck MMCache). Основная их задача - оптимизация и ускорение выполнения PHP-скриптов (компиляция скрипта в байт-код и кэширование результатов для последующего вызова именно скомпилированного варианта).

    Пример использования PHP-оптимизатора Turck MMCache

    Рассмотрим способ диагностики с помощью Turck MMCache.

    Создайте в пределах каталога ~/www php-файл с вызовом функции:

    <?php mmcache() ?>
    

    Вызвав этот скрипт из браузера, вы увидите таблицы, в которых содержится информация о работе Turck MMCache:

  • таблица с параметрами MMCache support отображает текущие настройки Turck MMCache;
  • параметр Memory Size отображает общий объем выделяемой для Turck MMCache памяти;
  • параметр Memory Allocated указывает объем памяти, который используется в данный момент для кэширования скриптов;
  • Cached Scripts - количество скриптов, которые Turck MMCache смог закэшировать.

    Во второй таблице представлен список всех выполненных скриптов, а также такие параметры, как размер (Size) каждого скрипта и количество удачных загрузок (Hits) из памяти Turck MMCache. Если параметр Hits имеет значение 0, то это означает, что Turck MMCache не смог закэшировать этот скрипт.

    Чтобы определить объем загружаемых файлов для выполнения одного скрипта, нужно сначала очистить память Turck MMCache от уже закэшированных скриптов. Для этого необходимо нажать кнопку Clear и убедиться, что кэш-память очищена - в списке скриптов должен остаться только один созданный нами скрипт. После этого нужно вызвать конкретный скрипт через браузер и после завершения его работы обновить страницу с таблицами Turck MMCache. В результате этих действий вы получите список файлов, которые вызываются при выполнении данного запроса. Общий объем этих файлов можно подсчитать, просуммировав все показанные скрипты по полю Size.

    Сразу же отметим, что это - далеко не единственный оптимизатор PHP. Более того, развитие данного проекта остановилось, последняя версия - 2.4.6 - была выпущена в ноябре 2003 года. Позднее на базе исходного кода Turck MMCache был создан новый продукт - eAccelerator. В нем, в основном, исправлены некоторые ошибки Turck MMCache. По принципам работы эти оптимизаторы практически идентичны. Для совместимости скриптов на нашем хостинге сейчас поддерживаются одновременно и Turck MMCache, и eAccelerator, однако в дальнейшем будет поддерживаться только eAccelerator.

    Где использовать оптимизаторы PHP

    Ощутимый прирост производительности PHP-оптимизаторы дают в работе форумов (например, phpBB, vBulletin), CMS - систем управления контентом (например, Битрикс (Bitrix), PHP-Nuke, Mambo).

    В принципе, практически любая большая система, написанная на PHP, будет работать быстрее при использовании оптимизаторов PHP. Но, тем не менее, стоит помнить о том, что не всегда те скрипты, которые корректно работали без оптимизаторов, будут на 100% совместимы с дополнительными модулями к PHP. При подключении того или иного модуля постарайтесь убедиться в том, что написанный вами код совместим с ним.

    Работа с базой данных

    Еще одним "узким" местом в работе сайта зачастую является неоптимальное использование базы данных.

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

    На виртуальном хостинге в качестве базы данных чаще всего используется MySQL. И одной из наиболее частых причин медленного выполнения SQL-запросов является отсутствие индексов в таблицах MySQL. Если база содержит таблицы с большими объемами данных, то выполнение запросов типа SELECT по полям такой таблицы без индексов может занять достаточно продолжительное время, что в конечном итоге скажется на времени формирования страницы. Именно поэтому рекомендуется периодически отслеживать и оптимизировать такие запросы. Это можно делать с помощью команды MySQL SHOW FULL PROCESSLIST, которая выводит таблицу всех выполняющихся в данный момент запросов. Колонка Time указывает, как долго выполняется каждый запрос. Если время выполнения запроса составляет более одной секунды - есть повод проверить количество просматриваемых этим запросом строк в таблице. Для этого нужно использовать команду EXPLAIN, которая также выдаст таблицу с результатами. Значение в столбце Rows покажет, сколько строк в таблице просматривается при выполнении данного запроса. Если количество строк более 1000, то нужно попробовать построить индексы для тех полей, по которым идет выборка. Как правило, в большинстве случаев после построения индексов удается добиться уменьшения числа просматриваемых строк в десятки раз, что положительно сказывается на времени выполнения запроса.

    Рассмотрим конкретный пример:

    mysql> SELECT title FROM products WHERE id = 123212;
    +-----------+
    | title     |
    +-----------+
    | Product N |
    +-----------+
    1 row in set (0.60 sec)
    
    mysql> EXPLAIN SELECT title FROM products WHERE id = 123212;
    +----------+------+---------------+------+---------+------+--------+-------------+
    | table    | type | possible_keys | key  | key_len | ref  | rows   | Extra       |
    +----------+------+---------------+------+---------+------+--------+-------------+
    | products | ALL  | NULL          | NULL |    NULL | NULL | 175246 | Using where |
    +----------+------+---------------+------+---------+------+--------+-------------+
    1 row in set (0.00 sec)
    
    Мы делаем запрос из таблицы 'products' с условием по полю 'id', для которого не построен индекс. Запрос выполняется 0.60 сек., и при его выполнении MySQL "просматривает" 175246 строк в таблице. Можно построить индекс по полю 'id' и сравнить результаты.
    mysql> CREATE INDEX id_index ON products (id);
    Query OK, 175246 rows affected (2.05 sec)
    Records: 175246  Duplicates: 0  Warnings: 0
    
    mysql> SELECT title FROM products WHERE id = 123212;
    +-----------+
    | title     |
    +-----------+
    | Product N |
    +-----------+
    1 row in set (0.00 sec)
    
    mysql> EXPLAIN SELECT title FROM products WHERE id = 123212;
    +----------+------+---------------+----------+---------+-------+------+-------------+
    | table    | type | possible_keys | key      | key_len | ref   | rows | Extra       |
    +----------+------+---------------+----------+---------+-------+------+-------------+
    | products | ref  | id_index      | id_index |       5 | const |    1 | Using where |
    +----------+------+---------------+----------+---------+-------+------+-------------+
    1 row in set (0.00 sec)
    
    После построения индекса по полю 'id' тот же запрос выполняется практически мгновенно, так как MySQL фактически "просматривает" только одну строку.  

    Передача файлов большого объема по HTTP

    Еще одная частая проблема, приводящая к медленной загрузке сайта, связана с объемом информации, скачиваемой с сайта, и частотой запросов на скачивание файлов. Допустим, у Вас на сайте расположено много файлов очень большого объема (по несколько мегабайт). Посетители сайта могут скачивать эти файлы, но на обработку их запросов будет уходить ощутимое время из-за того, что файлы имеют большой объем. В случае, если запросов приходит сразу несколько, то велика вероятность того, что сайт будет открываться с большими задержками или не открываться вовсе, поскольку сервер будет занят исключительно обслуживанием этих запросов. Часто такая проблема может возникнуть и из-за использования посетителями специальных программ, предназначенных для загрузки файлов (менеджеры загрузки) - некоторые такие программы скачивают большие файлы в несколько потоков, в результате чего количество работающих на виртуальном сервере процессов множится и очень быстро достигает лимита.

    В случае, если у Вас действительно имеется необходимость постоянно предоставлять для скачивания файлы большого объема, то лучше всего воспользоваться дополнительной услугой "Виртуальный FTP-сервер". В этом случае вы сможете предоставить доступ к файлам по протоколу FTP, тем самым разгрузив веб-сервер Apache и переложив работу по обработке запросов на скачивание файлов на FTP-сервер.


  • Понравилась статья? Поделись с друзьями!
    Facebook Опубликовать в LiveJournal Tweet This


    Оглавление   |  На верх

    Оглавление        Вернуться к статье

    Тема страницы:

    Медленная загрузка сайтов: основные причины, как с ними бороться : FAQ 2017-09-21 21_41_11 ( тариф, услуги, виртуальный )

    Мы решим Ваши проблемы с выбором хостинга
    Вход
    Логин:

    Пароль:


    Запомнить меня
    Вам нужно авторизоваться.
    Забыли пароль?
    Регистрация
    На сайте
    Гостей: 1
    Пользователей: 0


    Статьи
    FAQ
    10 статей
    Использование материалов разрешается только при наличии ссылки на источник информации: www.sevhosting.net!
    Для интернет-ресурсов наличие прямой активной гиперссылки www.sevhosting.net - обязательно ! © 2006-2015
    Работает под управлением WebCodePortalSystem v. 6.2.01