О файловой системе |
|
Вопрос: зачем нужны дополнительные тесты на производительность файловой системы, ведь уже есть характерное время, уходящее на gzip-сжатие определенных размеров файлов? Ответ: во-первых, любой веб-сервер и так берет файл из файловой системы и архивирует уже в памяти, а потом пишет в сокет. Это время уже учтено при установлении соединения с сервером до получения первого байта. Нам лишь нужно понять, насколько оно увеличится, если сервер произведет еще некоторые операции с данными в оперативной памяти. Во-вторых, не все серверы читают прямо с диска. У высоконагруженных систем и прокси- серверов (например, 0W, squid, nginx, thttpd) данные могут храниться прямо в оперативной памяти, поэтому время доступа к ним существенно меньше, чем к файловой системе. Соответственно, его и нужно исключить из полученных результатов. Что быстрее: gzip или канал?Модель хорошо аппроксимирует полученные данные, поэтому примем ее за основу для следующих вычислений. Нам нужно, на самом деле, установить, насколько процессорные издержки на сжатие превосходят (или, наоборот, меньше) издержек на передачу несжатой информации. Для этого мы построим ряд графиков, приняв за эталон полученные коэффициенты для однопроцессорного сжатия на Dual Xeon 2,8 Ггц. Так как с пользовательской стороны уходит некоторые время на распаковку архива, то ограничим его временем сжатия на машине с CPU в 1 Ггц. Это ограничение сверху: естественно, что распаковка экономичнее сжатия, да и пользовательские машины имеют процессоры, в среднем, мощнее, чем 1 Ггц. Однако, нам нужно получить лишь качественные данные (ограничение снизу), поэтому ограничимся таким уровнем точности. Итак, ниже приведены издержки на передачу дополнительного количества информации (в миллисекундах) для двух разных каналов (100 Кб/с и 1500 Кб/с) и двух разных серверов (280 МГц и 1 Ггц). Видно, что график для gzip на 1000 Mhz идет практически вровень с передачей данных для канала в 1500 Кб/с (одна линия перекрывает другую).
Рис. 6. Накладные издержки на сжатие и передачу информации для 100Кб и 1500Кб и 280МГц и 1000МГц Исследование степени gzip-сжатия и загрузки процессораРассмотрим далее, насколько сильно издержки на gzip зависят от степени сжатия, и как их прогнозировать с учетом всех остальных параметров. Новая серия тестов была направлена на установление зависимости между степенью сжатия, процессорными издержками и уменьшением размера файла, чтобы на основе этих данных построить более точную модель, определяющую рациональность использования архивирования «на лету». Как и ранее, на сервере проводились серии тестов по 10000 итераций в каждом. Замерялось время работы gzip при различных степенях сжатия. Затем оно усреднялось по серии, и из него вычитались издержки на работу с файловой системой. Также замерялось достигнутое уменьшение размера файла. Для зависимости «процессорное время - степень сжатия» был получен следующий график. По оси абсцисс идет степень сжатия, по оси ординат - затраченное время (среднее по серии):
Рис. 7. Издержки на gzip от степени сжатия Далее график эффективности полученного сжатия (в % от оригинального размера файлов) от степени сжатия:
Рис. 8. Эффективность различных степеней gzip-сжатия Окончательные выводыСобственно, картинки говорят сами за себя. Если у вас HTML-файлы, в среднем, больше 4 Кб, то появится ощутимый выигрыш для большинства пользователей при включенном gzip на сервере (даже если этот сервер находится на весьма «слабенькой» машине). В случае маленьких файлов и(ли) медленного в вычислениях сервера, стоящего, однако, на быстром канале, будет экономичнее не сжимать файлы. Хочется также обратить внимание на то, что, отдав пользователю данные быстрее (через gzip-сжатие), мы тем самым освободим часть серверных ресурсов, что может оказаться существенным подспорьем для высоконагруженных проектов. В общем случае, gzip-сжатие позволяет существенно ускорить доставку HTML-файла до пользователя, не увеличивая нагрузку на сервер. Если же использовать статическое архивирование (готовые архивы хранить на сервере и обновлять только в случае необходимости), то выгода просто очевидна.
|
Алгоритм Снежинск10 ноября 2009 года Яндексом была анонсирована новая версия поискового алгоритма – Снежинск. Коренные изменения произошли в алгоритме расчета релевантности – представители Яндекса написали следующее: «Нам удалось создать более точную и гораздо более сложную математическую модель, которая привела к существенному приросту в качестве поиска. Благодаря переработке архитектуры ранжирования в... Читать полностью |
Как работают поисковые машиныПоисковый запрос принимается и проверяется на наличие специфических команд и ошибок (в случае ошибок, как правило, предлагается правильный или наиболее подходящий вариант). По поисковому запросу подбираются страницы из индекса и выводятся в порядке релевантности. Запрашивается список текущих рекламных объявлений, удовлетворяющих поисковому запросу, и выводится в блоке рекламы.
Читать полностью |
Алгоритм Магадан14 апреля 2008 года адресу buki.yandex.ru начала тестироваться новый поисковый алгоритм «Магадан». Кроме того, что увеличилось вдвое количество факторов ранжирования, был также добавлены следующие нововведения: Читать полностью |
Продвижение сайта и уникальность контентаВы, наверное, не раз попадали на разные сайты с совершенно одинаковым содержанием. А тем временем Яндекс продолжает настаивать на уникальности контента и призывать к этому владельцев сайтов и веб-мастеров. Уникальный контент способен сделать результаты поиска более объективными и более разнообразными по содержанию. Тут возникает вопрос: кто же наиболее заинтересован в оригинальности содержания:... Читать полностью |



