У меня на одном из объектов информация об операциях на удаленных точках в онлайне передается в БД путем обыкновенных запросов к веб-серверу. (Так нужно было). При этом на большинстве точек единственно возможным каналом связи является сотовая связь (GPRS). Понятно, что в общей скорости работы такой канал является самым "узким" местом.
Для того, чтобы "выжать" из него максимум, имеем следующие возможности:
- Выбрать одного из трех операторов мобильной связи (впрочем, у некоторых счастливчиков их больше).
- Определить место размещения веб-сервера, который принимает запросы от удаленных объектов - это может быть сервер, предоставленный хостинговой компанией или свой собственный сервер
- В случае использования сервера хостинга - выбрать этот самый хостинг
- В случае использования своего собственного сервера - выбор интернет-провайдера, который обеспечит нам связь.
Данные условия необходимо рассматривать во взаимосвязи. Сравнивать два хостинга имеет смысл не абстрактно, а путем измерения скорости ответов непосредственно на том компьютере, откуда будут направляться запросы. Даже формально "более медленный" хостинг может показать худшие результаты например в случае, если он предоставлен тем же провайдером, что и канал связи.
При условии, что сами по себе запросы относительно небольшие, по сути все, что нам требуется - получать ответ максимально быстр. Разумеется это "максимально быстро" должно быть еще и "максимально стабильно". То есть тестирование необходимо проводить в течение длительного време
С таким заявленными функциям существует много программ и веб-сервисов, но почему-то ничего подходящего я не нашел:
- или тестируется тупо скорость соединения (скачивание большого количества информации). В моем случае совершенно не показательно, т.к. запросы и ответы на них очень маленькие (несколько сотен а то и десятков байт)
- тестируется "пинг". По момему такие тесты годятся только для того, чтобы определить отсутствие связи (но не наоборот - не однократно встречал ситуацию. когда пинг отличный, а связи нет).
- большинство тестов - "мгновенные". Это приятно конечно, когда результат получаешь сразу, но такой результат ни о чем не говорит. Так как через 5 минут он может оказаться совершенно другим.
- нет нормального анализа результатов. Среднее время ответа в 1 сек может означать, что ответ занял по 1 сек на каждый из 10 запросов, или 8 запросов по 0,1 сек и 2 запроса по 4,6 сек. - это очень существенно.
В итоге написал обработку, которая и решает вышеуказанные задачи. При этом:
- Никаких синтетических показателей. Делаем самые что ни на есть обыкновенные http запросы. Можно запрашивать файлы как по фиксированному списку, так создавать запросы на основании имеющегося справочника. Например, если в конфигурации есть справочник "номенклатура", то можно перебирать справочник и делать запросы вида http://mysite.com/catalog/item.php?code=[код номенклатуры].
- Обработка предназначена для сбора статистики в течение длительного времени. Для этого настраиваем расписание работы. Например, можно настроить расписание с 9 до 18 по рабочим дням в течение недели. Можно настроить несколько расписаний и получить отдельные результаты по рабочим дням и по выходным.
- Результаты работы сохраняются в обычном текстовом файле, который можно загрузить в Excel или использовать любую программу для статистического анализа.
- Кроме того, обработка предоставляет возможность формирования 2 диаграмм - частотной (распределение скорости ответов по частоте) и временная (распределение скорости ответов по времени). На диаграммах можно сравнить результаты нескольких тестов.
- Обработка может использоваться в любой конфигурации.
А вот теперь немного примеров использования обработки:
Внимание! Эти результаты приведены в качестве примера использования обработки и справедливы только для конкретного места, где проводилось измерение, кроме того они могут изменяться во времени. (Установка операторами новых базовых станций или открытие рядом офиса крупной компании где у большинства сотрудников телефона на корпоративном контракте одного из операторов). На надо экстраполировать их на всю Россию. Проводите измерение в конкретном интересующем Вас месте.
Сравним двух операторов: МТС и Мегафон
Это - интервальная диаграмма, показывает как распределяется время на получение ответа сервера по частоте.
В данном случае:
При подключении через оператора МТС 60% ответов уложились в 1,6 сек. У Мегафона за этот интервал времени пришло только 6% ответов. Большая часть ответов (опять же 60%) пришла через Мегафон в интервале 1,59-2,41 сек.
Некоторый процент запросов обрабатывался длительное время (более 8,81 сек.) У Мегафона таких оказалось меньше. То есть, время ожидания ответа хотя и выше, чем у МТС, но более стабильно.
Запросов, на которые ответы вообще не пришли, при работе через МТС оказалось около 1%, а при работе через Мегафон - около 4%.
Проанализируем работу через оператора Мегафон в течение дня
Эта диаграмма состоит из двух частей. Сверху отбражается время обработки запросов. Тонкая черта соединяет абсолютные минимум и максимум. Так, в интервале 10.00-10-30 это время колебалось в интервале от ~2-53 сек. Толстый прямоугольник показывает, интервал времени, в который уложился выбранный процент (в данном случае - 70) запросов. Этот интервал составил ~ 2,2-4,5 сек.
Снизу отображается количество запросов, оставшихся без ответа. Как видим, пик пришелся на 10.00-10.30 (~44 запроса).
В целом результаты вполне понятны - наибольшая загрузка в момент начала рабочего дня, и чуть большая - после обеда.
Однако, выводы делать рано - ведь кроме оператора связи на скорость обработки запросов влияет хостинг. А наш график был построен на основании тестирования в течение 2х дней, первый день хостинг был один, второй день другой.
Сравним два хостинга
Диаграмма аналогична предыдущей. Как видим, большой процент ошибок в интервале 10.00-10.30 целиком "на совести" хостинга aha.ru. А вот колебания увеличения процента времени ответов уже на совести оператора.
А таки диаграмма нам однозначно показывает, что, по крайней мере при работе через оператора Мегафон хостинг nichost.ru с точки зрения времени ответа сервера предпочтительнее.
