Научный консалтинг
Главная
Контакты
Номер телефона
Как мы работаем
Гарантии
Условия
Цены

Изучаем скорость работы хостинга

Хостинг – это услуга, в рамках которой предоставляется место на сервере для хранения файлов сайта. Одновременно хостингом иногда называется и сам сервер.

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

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

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

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

Один из способов тестирования хостинга

Т.е. можно, конечно, использовать тот же webpagetest раз 100…1000 подряд – и так на протяжении многих недель. Однако, во-первых, это утомительно (правда, можно написать парсер – но это тоже работа или затраты). Во-вторых, вероятно, при достаточно высоком объеме работы на сервисе сработают некие ограничения, поэтому придется вносить оплату. Ну, а очень частую проверку, видимо, не разрешат.

Поэтому – какой выход? Выход – использовать для этого… роботов поисковых систем. Они, собственно, и так посещают сайты (с разной периодичностью, но, чем популярнее сайт, тем чаще и больше сканируют файлов). К тому же, скажем, в Google, в Вебмастере накапливается аналитика, в частности, динамика таких показателей, как время, затраченное на загрузку страницы (в миллисекундах), количество килобайтов, загруженных за день, количество сканированных страниц в день. Этой информацией и можно воспользоваться для того, чтобы провести анализ.

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

В настоящее время в Вебмастере Гугл дается аналитика (максимум – на 90 дней), выглядящая примерно следующим образом:

На рисунке показаны данные из Вебмастера Гугл

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

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

Как быть?

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

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

И что, мол, такую информацию мне не получить.

А выход-то простой

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

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

Понятно, что (по крайней мере, в рамках законодательства России) подобное заявление звучит некорректным. Скажем, если открыть исходный код Вебмастера и посмотреть там информацию – это будет нарушение условий использования, в соответствии с этим?

Нет, не будет. В этой части условия противоречат российскому законодательству. Ибо, во-первых, посмотреть – это не означает «взламывать» или «использовать» (а, тем более – копировать, распространять и т.д.). Практически любой браузер дает возможность свободного просмотра исходного кода веб-страницы (ибо это – открытый исходный код), это не является нарушением законодательства; нарушением может быть лишь использование ее таким образом, которым не разрешает лицензия. Во-вторых, если из этой всей информации будет использоваться та и только та информация, которая касается пользователя лично, но которую он не имеет возможности увидеть в интерфейсе Вебмастера (или если возможность есть, но она затруднена)? Естественно, пользователь должен получить беспрепятственный доступ ко всей той информации, которая касается его (и/или его сайта) лично.

То есть, в сухом остатке, здесь можно подать в суд иск против Google за несоответствие условий пользования Вебмастером законодательству той страны, на территории которой такое пользование осуществляется. И разбирательство будет происходить вовсе не по законам Калифорнии. Но, как видится, это все – лишние потери времени. Да и попросту не хочется с этим связываться.

Поэтому поступаем сложнее, в соответствии с условиями использования. По очереди подносим указатель мыши к КАЖДОЙ точке графика, как-то так:

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

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

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

В общем, как уже договорились, из исходного кода Вебмастера Гугл мы не копируем. Поэтому из тетрадки переносим данные в Excel и располагаем рядом друг с другом – в виде столбцов. Делать анализ-то Гугл нам запрещает. Да и не может запретить.

Что, впрочем, является весьма смелым предположением. На самом-то деле, раз уж в настоящее время многими правительствами стран мира (Россия – отнюдь не исключение) проводится политика по отуплению населения…, то, вполне возможно, что в будущем проводить анализ тех или иных показателей (а то и вообще заниматься анализом) будет запрещено под угрозой административного или уголовного преследования. Вполне может появиться такая статья в уголовном кодексе, скажем. В самом деле, ведь уже есть нормы, предусматривающие наказание за некоторые высказывания (их еще именуют экстремистскими). Собственно, что… даже марганцовку теперь в аптеках не продают – по тем же причинам. Поэтому, вполне возможно, что и проведение анализа чего-нибудь мало-мальски серьезного тоже будет запрещаться законами, за исключением разрешенных законом случаев. Ладно, продолжим.

Как итог наших потуг, получится что-то в таком роде:

Дата Время, затраченное на загрузку страницы (в миллисекундах) Количество килобайтов, загруженных за день Количество сканированных страниц в день
07.08.2016 371 7 677 340
08.08.2016 338 5 220 333
09.08.2016 345 7 395 500
10.08.2016 333 17 584 691
11.08.2016 347 4 921 315
12.08.2016 371 3 730 245
13.08.2016 389 1 563 95
14.08.2016 138 12 461 273
15.08.2016 222 3 287 203
16.08.2016 368 10 367 218
17.08.2016 293 3 316 133
18.08.2016 207 3 645 222
19.08.2016 200 4 335 134
20.08.2016 182 10 346 246
21.08.2016 167 3 949 251
22.08.2016 241 2 488 164
23.08.2016 172 12 146 240
24.08.2016 139 2 644 174
25.08.2016 197 3 466 214
26.08.2016 352 3 267 217
27.08.2016 292 13 394 163
28.08.2016 216 2 999 160
29.08.2016 330 3 148 184
30.08.2016 247 11 199 191
31.08.2016 208 2 862 147
01.09.2016 199 1 302 71
02.09.2016 337 1 738 91
03.09.2016 256 13 086 303
04.09.2016 141 569 52
05.09.2016 224 345 17
06.09.2016 282 9 232 81
07.09.2016 177 776 45
08.09.2016 284 612 22
09.09.2016 232 174 16
10.09.2016 327 296 22
11.09.2016 255 9 644 117
12.09.2016 168 1 019 51
13.09.2016 225 373 28
14.09.2016 472 9 499 111
15.09.2016 213 6 946 300
16.09.2016 175 7 988 508
17.09.2016 187 10 745 707
18.09.2016 172 19 528 800
19.09.2016 208 9 828 652
20.09.2016 217 5 267 286
21.09.2016 225 12 808 284
22.09.2016 192 3 944 223
23.09.2016 205 4 019 221
24.09.2016 221 5 035 220
25.09.2016 240 13 764 262
26.09.2016 217 2 710 124
27.09.2016 234 2 379 117
28.09.2016 289 2 639 143
29.09.2016 349 4 818 245
30.09.2016 353 13 698 253
01.10.2016 236 2 466 142
02.10.2016 221 1 696 93
03.10.2016 223 3 177 116
04.10.2016 242 11 247 216
05.10.2016 209 1 622 92
06.10.2016 236 1 497 66
07.10.2016 345 8 761 72
08.10.2016 197 4 796 220
09.10.2016 229 5 485 95
10.10.2016 242 2 083 106
11.10.2016 263 8 049 102
12.10.2016 173 1 687 88
13.10.2016 216 3 448 120
14.10.2016 228 6 103 155
15.10.2016 306 1 877 51
16.10.2016 271 507 23
17.10.2016 253 2 116 82
18.10.2016 211 3 204 164
19.10.2016 235 3 135 57
20.10.2016 249 1 976 39
21.10.2016 236 1 848 90
22.10.2016 206 1 790 55
23.10.2016 216 2 534 62
24.10.2016 219 2 268 111
25.10.2016 224 4 290 223
26.10.2016 340 4 282 239
27.10.2016 260 3 534 150
28.10.2016 337 3 950 114
29.10.2016 493 2 642 122
30.10.2016 453 3 971 241
31.10.2016 388 1 131 36
01.11.2016 428 2 242 63
02.11.2016 224 6 540 190
03.11.2016 214 2 216 102
04.11.2016 441 2 305 63

Хотя, повторимся, все эти данные есть в исходном коде Гугл-Вебмастера, но копировать их оттуда Гугл запретил.


Проводим анализ

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

Показатель Время загрузки Загруженные килобайты Количество сканированных страниц
Время загрузки 1 0,002098 -0,07277
Загруженные килобайты
1 0,693488
Количество сканированных страниц

1

Кстати, величина коэффициента корреляции в программе Excel рассчитывается при помощи функции, навроде

=КОРРЕЛ(D2:D91; C2:C91)

Здесь D2:D91 и С2:С91 – первый и второй массивы данных, соответственно (диапазоны), в которых хранятся столбцы с числами.


Итак, что видим?

Два рассчитанные парные коэффициенты линейной корреляции имеют чрезвычайно малые значения, не превышающие по модулю 0,1. Это означает, что соответствующие линейные корреляционные связи являются очень слабыми, практически отсутствующими. Т.е. взаимосвязь между динамикой количества килобайт информации, загруженной роботом Google с сайта и среднего времени загрузки страницы – практически отсутствует.

Точно также отсутствует взаимосвязь между количеством просканированных в день страниц и средним временем загрузки каждой из них.

Это означает, что, по крайней мере, на данных масштабах загрузки (до 15928 кБ в день) время загрузки страниц не зависит от объема загружаемых данных. Т.е. производительность сервера, по крайней мере, на таких объемах загрузки, можно считать хорошей.

Видно также, что коэффициент корреляции между динамикой количества загруженных страниц и объемом загрузки в килобайтах составляет 0,693488, что примерно равно 0,7. Такое значение характеризует корреляционную взаимосвязь средней степени тесноты, ближе к сильной.

Этот результат очевиден. В самом деле, чем больше страниц сканируется, тем больше килобайтов загружается. Однако, так как все страницы имеют разный, неодинаковый объем и, кроме того, вероятно, каждый день сканируются РАЗНЫЕ страницы – то большие, то маленькие, то средние – поэтому зависимость не характеризуется стопроцентной теснотой (которая означала бы функциональную взаимосвязь) или близкой к тому.

Наконец, вполне возможно (см. ниже), что робот Гугла сканировал сайт, периодически меняя свою стратегию.

Если бы Googlebot сканировал каждый день ОДНИ И ТЕ ЖЕ СТРАНИЦЫ, очевидно, соответствующий коэффициент корреляции был бы близок к 1.

Уточнение

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

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


Корреляционное поле зависимости количества килобайт, загруженных роботом Google от их времени загрузки

Итак, видим, что корреляционное поле зависимости количества загруженных байт от времени, потраченного на загрузку одной страницы, в самом деле, представляет собой практически равномерно разбросанную совокупность точек. Правда, можно видеть небольшое их скопление в левой его части внизу. Т.е. в большинстве случаев робот загружал страницы за 180…220 мс, что, на наш взгляд, является ОЧЕНЬ хорошим результатом.

Очень часто робот загружал в день примерно по 4000…5000 кБ информации.

Следующее корреляционное поле имеет аналогичный вид.

Корреляционное поле зависимости количества загруженных страниц от среднего времени, затрачиваемого роботом Google на загрузку каждой

Т.е., в самом деле, никакой зависимости (ни линейной, ни нелинейной) между количеством просканированных страниц в день и временем, потраченным на загрузку, нет.

Наконец, рассмотрим третье корреляционное поле

Корреляционное поле зависимости количества сканируемых страниц от количества килобайт, загруженных роботом Гугл

Здесь видим как бы ДВЕ характерные тенденции (тренда), поднимающиеся примерно под углом 45о вверх (отмечены на рисунке прямыми цветными линиями – синей и зеленой).

Строго говоря, синюю линию надо было нарисовать не линейной, а в виде возрастающей ветви параболы, идущей из начала координат.

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

Rсиней = 0,906381;

Rзеленой = 0,925294.

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

Выяснилось, что в течение указанного периода робот Гугла сканировал сайт, применяя ОДНУ из ДВУХ стратегий: «маломасштабную» и «крупномасштабную», если так можно выразиться. Объемы килобайтов, загруженных за день, для этих двух стратегий различаются примерно на 7000 кБ или, ориентировочно, на 70…300%. (!)

Интересно, что же вызывает необходимость столь существенного (в разы) прироста объема загруженных килобайт в день? Почему такая необходимость возникает лишь периодически?

Характерно, что углы наклона обоих линий трендов практически идентичны. Это означает, что наблюдается прямая пропорциональность между количеством скачанных за день страниц и количеством килобайтов, загруженных за день (на уровне степени тесноты, составляющей не менее 0,9, выражаемой коэффициентом линейной корреляции).

Однако, некие факторы иногда понуждают робота при сканировании страниц реализовывать «крупномасштабную» стратегию, загружая ГОРАЗДО БОЛЬШЕ килобайт (в разы), чем в режиме «маломасштабной» стратегии. Причем, если обратить внимание на даты перехода к «крупномасштабной» стратегии, то в первых 2/3 части исследуемого периода интервал между днями ее применения составлял 1…2…3, редко – 4 дня. В последней 1/3 части периода робот почему-то довольствовался только «маломасштабной» стратегией. Несмотря на то, что материалы на сайт добавлялись в обычном режиме. Происходило также обновление уже имеющихся материалов, в частности, земельного законодательства (ибо оно в последние лет 10 в России, как известно, меняется очень часто). Поэтому приходится следить за обновлениями и вовремя вносить изменения в статьи, с учетом законодательных нововведений, но, это, повторимся, делалось в обычном режиме.

Стало быть, можно предположить нехватку ресурсов Google для полноценного сканирования интернета.

Выводы

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

  1. При сканировании роботом объема информации до 19,528 МБ в день не наблюдается никакой зависимости между временем, затраченным на скачивание одной страницы и количеством килобайт, загруженных в день. Также не наблюдается никакой взаимосвязи между количеством сканированных страниц (вплоть до 800 в день) и временем, потраченным на загрузки одной страницы. Кроме того, максимальное время загрузки одной страницы не превысило 493 мс (такого показателя нам удалось добиться в результате оптимизации сайта, исключения ненужных функций). Это означает, что хостинг хорошо держал нагрузку в течение всего анализируемого периода времени. Т.е. хостингу НЕВАЖНО, каков будет объем загружаемой информации, если он не превышает, по крайней мере, 19,528 МБ. При этом хостинг не создавал проблем для робота Google при сканировании им сайта (кстати, этот вывод подтверждается и тем фактом, что никаких ошибок сканирования в течение этого периода не наблюдалось). Ну, а насколько этот хостинг сможет держать нагрузку и при дальнейшем возрастании объема загружаемой роботом информации, это неясно. Для этого необходимы дополнительные исследования, возможно, на другом, более объемном, сайте.
  2. Робот Гугл применял для сканирования данного сайта две стратегии» «крупномасштабную» и «маломасштабную», объемы скачиваемой информации при ТОМ ЖЕ количестве сканируемых страниц различались в разы (до трех раз). «Маломасштабная» применяется гораздо чаще, тогда как «крупномасштабная» - изредка. А бывают периоды, когда последняя не применяется совсем, т.е. робот ограничивается загрузкой существенно меньшего количества килобайт, при том, что число сканируемых страниц может быть тем же самым, что и при использовании «крупномасштабной» стратегии. Отсюда напрашивается следующий вывод: иногда робот сканирует страницу НЕПОЛНОСТЬЮ. Возможно, такое наблюдается даже не иногда, а часто. Вероятная причина тому – ресурсов Гугла не всегда хватает для полноценного сканирования интернета.

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

Что дальше?

Что дальше, если рост информационных потоков продолжится? А то, что это так будет, сомневаться не приходится.

Хотя… хотя, есть и иное мнение – об этом ниже.

Если, попутно с этим, возрастет плагиат (копипаст), хотя за последний поисковые системы, вроде как, жестко наказывают, начиная с исключения плагиата из результатов поиска и кончая – баном сайта?

Один, просящийся наружу, выход – СНИЗИТЬ, существенно снизить объем растровых графических изображений, находящихся в сети. Это относится как к картинкам, так и к видео – это, наверное, даже в первую очередь. Как и что можно сделать в этой связи – фантазировать не будем. Ибо пока об этом никто не спрашивал.

Другой потенциальный выход, причем, соответствующие попытки уже делаются – ограничить в сети показ контента, который не содержит в себе так называемой «добавочной полезности». Однако это, очевидно, пока обречено на провал. Хотя бы потому, что едва ли в ближайшее время будут разработаны соответствующие компьютерные программы; ведь, если по-хорошему, здесь потребуется ни много, ни мало – искусственный интеллект.

А разного рода «словоанализаторы» (работающие… методом перебора), «алгоритмы разбивки по слогам» и т.д. – так с ними мы и будем иметь то, что уже имеем. С ними суждено быть в выдаче, отчасти, тем сайтам, которые не столько обладают полезностью, сколько будут грамотно выполнены в плане плотности и расстановки ключевых слов, заполнения заголовков h1…h6, микроразметки (интересно, кто же придумал такую ненужную вещь - ведь микроразметку может быть заспамлена точно так же, как и заголовки, например), упоминания адресов и телефонов компании на шапке сайта, наличия страниц возврата товара и гарантий, умения не попасться на покупных ссылках и прочих манипуляциях, ну и т.п.

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

К тому же, нередки ведь в ТОПе поисковой выдачи и такие страницы…, которые ВООБЩЕ не содержат в себе никакой полезности, не говоря уже о добавочной, представляя собой просто несколько больших картинок (нередко, отнюдь не привлекательных) со скудными надписями на них или где-то рядом. Правда, такое оформление сейчас называется, вроде как, современным, но, строго говоря, на наш взгляд, это – современная вариация одного и того же, давно известного старого, под кратким названием ГС.

Выход у Гугла, пожалуй, пока один: серьезно взяться за борьбу с плагиатом. И вместо заявлений о «швабрах», с которыми они не намерены бегать за каждым спамером (до момента, пока на этого спамера не поступила жалоба), а САМИМ исследовать контент сети и качественно выявлять копипастеров. Да, это видится более простой, более решаемой (да и, к тому же, гораздо более полезной для интернета и для самого же Гугла) задачей, чем постоянно наращивать мощности, захлебывающиеся в потоке информации и что-то оптимизировать в своих поисковых алгоритмах (хотя это тоже необходимо, но, на наш взгляд, не первостепенно).

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

Иное мнение

Это мнение – по поводу прогноза роста информационных потоков. На самом деле, в недалеком будущем ситуация может стать обратной. Ибо люди попросту перестанут быть способными ориентироваться в хаосе наступающей на них информации. Ладно, раньше были книги. Затем – появились радио, телевидение. Затем – интернет. Активно развивается мультимедиа.

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

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

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

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

С уважением к Вам.

Вот что мы можем сделать для Вас:
Интересная и полезная
информация
Изменить размер шрифта:
?