Как можно симулировать тормозящий браузер?
В веб разработке встречаются такой момент, когда у клиента с очень медленным интернетом и старой медленной системой во время открытия в веб страницы видны ее дефекты, которые на быстрых машинах не видны так как их человек не успевает заметить. Как можно симулировать вот такую медленную загрузку, что бы увидеть подобные дефекты при веб разработке? да это дубликат вопроса: Изменить скорость загрузки сайта но там нет решения моей проблемы:
- веб-программирование
- тестирование
Отслеживать
задан 23 янв 2018 в 13:20
9,971 14 14 золотых знаков 53 53 серебряных знака 117 117 бронзовых знаков
Купить за копейки такой комп))) Ну или на виртуалке сделать virtualbox например. урезать все ресурсы
23 янв 2018 в 13:23
запустите в торренте на скачивание фильмографию Джеки Чана)
23 янв 2018 в 13:23
Купить старую медленную машину и поставить ограничение трафика в роутере?
23 янв 2018 в 13:24
@pepsicoca1 ) и остановить работу всей организации?
23 янв 2018 в 13:25
Точно видел такую штуку в Хроме, где-то рядом с эмуляцией мобильных устройств. Не надо никаких виртуалок и тем более нового старого (кхм?) железа.
Google готова замедлить браузер Chrome
Компания Google рассматривает возможность замедления фирменного браузера Chrome ради безопасности пользователей, говорится в блоге команды сервиса.
Согласно исследованиям Chrome, 70% уязвимостей связаны с безопасностью памяти. Эксперты рассмотрели три варианта, которые могут избавить пользователей от проблем — проверка времени компиляции, времени выполнения и использование более безопасных языков программирования.
Первый способ оказался нереализуемым из-за особенностей языка C++. При этом разработчики отметили, что для проверки времени выполнения можно использовать MiraclePtr, благодаря чему избавиться от 50% уязвимостей в Chrome. Если компания решит выбрать этот вариант, то безопасность пользователей усилится, но это также может привести к некоторым проблемам производительности и стабильности работы браузера.
Кроме того, сотрудники Google рассматривают возможность использования языка программирования Rust, чтобы реализовать проверку компиляции.
Ранее «Газета.Ru» рассказывала, что Chrome собирает большое количество пользовательских данных для продажи.
Подписывайтесь на «Газету.Ru» в Новостях, Дзен и Telegram.
Мы сообщаем главное и находим для вас интересное.
Эмуляция медленной работы браузера!
Подскажите, пожалуйста, есть ли какой-нибудь софт для того чтобы эмулировать медленную работу браузера? Посмотреть как будет вести себя при этом веб-приложение.
И вообще, кто-либо из вас делает такие проверки? Есть смыл вообще делать такую проверку?
«Не сломал — значит, не старался!»
#2 
Vasiliy
Отправлено 14 мая 2014 — 07:16
На VMWare есть опции скорости сети и потери пакетов. Это настройки сетевой карты.
Попробуйте развернуть браузер на виртуалке.
Или еще вариант — есть утилиты, которые «тормозят» сеть. Подробностей не скажу, мы в итоге пользовались настройками виртуалок.
#3 vuchenka
Отправлено 14 мая 2014 — 07:46
На VMWare есть опции скорости сети и потери пакетов. Это настройки сетевой карты.
Попробуйте развернуть браузер на виртуалке.
Или еще вариант — есть утилиты, которые «тормозят» сеть. Подробностей не скажу, мы в итоге пользовались настройками виртуалок.
Немного почитала про VMware. Как я поняла надо установить виртуальную машину VMware Workstation. И в ней уже настраивать? или нужно еще скачивать отдельные пакеты для настройки скорости сети и потери пакетов?
«Не сломал — значит, не старался!»
#4 Vasiliy
Отправлено 14 мая 2014 — 08:03
Если у вас есть образ с ОС, то достаточно VMPlayer, а не workstation.
В текущих версиях это встроенная опция.
Если нужно создавать образ с нуля и устанавливать ОС, то потребуется именно workstation.
#5 vuchenka
Отправлено 14 мая 2014 — 08:05
Если у вас есть образ с ОС, то достаточно VMPlayer, а не workstation.
В текущих версиях это встроенная опция.
Если нужно создавать образ с нуля и устанавливать ОС, то потребуется именно workstation.
спасибо, очень помогли, будем пробовать..
«Не сломал — значит, не старался!»
#6 ch_ip
- ФИО: Павел Абдюшев
- Город: Москва
Отправлено 14 мая 2014 — 14:54
Мы использовали для этих целей машину с двумя сетевухами и линухом на борту.
На ней через iptables настраивали маршрутизацию, через tc — ограничение траффика.
статья в помощь: http://habrahabr.ru/post/119611/
Если минарет, значит выше всех (с)
#7 vuchenka
Отправлено 15 мая 2014 — 05:44
Мы использовали для этих целей машину с двумя сетевухами и линухом на борту.
На ней через iptables настраивали маршрутизацию, через tc — ограничение траффика.
статья в помощь: http://habrahabr.ru/post/119611/
спасибо, статья то что надо.
«Не сломал — значит, не старался!»
#8 Сергей
Отправлено 15 мая 2014 — 05:56
TMeter: без заморочек, настройка за 5 мин.
«Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество.» © Стив Джобс
#9 vuchenka
Отправлено 15 мая 2014 — 06:06
TMeter: без заморочек, настройка за 5 мин.
я как поняла она только под Windows?
«Не сломал — значит, не старался!»
#10 Сергей
Отправлено 15 мая 2014 — 06:56
Да, ставится на клиенте или на сервере. Отличное ПО. В бесплатной версии 3 фильтра. Но это все синтетика, для первого приближения. Если по взрослому, на физ. уровне через спец аппарутуру резать нужно (нам админы настраивали и веб морду давали с настройками)
«Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество.» © Стив Джобс
#11 ch_ip
- ФИО: Павел Абдюшев
- Город: Москва
Отправлено 15 мая 2014 — 07:09
Мы использовали для этих целей машину с двумя сетевухами и линухом на борту.
На ней через iptables настраивали маршрутизацию, через tc — ограничение траффика.
статья в помощь: http://habrahabr.ru/post/119611/
спасибо, статья то что надо.
Инструкция по сетапу машины.
Настраиваем DHCP сервер для одного из интерфейсов :
Примечание: сейчас используются самые верхние входы, сверху-вниз: eth1 (целевая тачка), eth0 (вовне)
Редактируем файл /etc/network/interfaces, указываем статический IP для eth1
auto eth1 iface eth1 inet static address 192.168.11.1 netmask 255.255.255.0 network 192.168.11.0
Перезапускаем networking так
/etc/init.d/networking restart
Cтавим пакет isc-dhcp-server
apt-get install isc-dhcp-server
Делаем так, чтобы dhcp-server раздавал адреса только на eth1
Редактируем файл /etc/default/isc-dhcp-server
INTERFACES=»eth1″
Потом редактируем файл /etc/dhcp/dhcpd.conf
subnet 192.168.11.0 netmask 255.255.255.0
Если хочется, конкретным машинам в сети можно принудительно раздать адреса; в тот же файл добавляем такие строки:
host host1
Еще надо сделать так:
dhcpd -t -cf /etc/dhcp/dhcpd.conf
Перезапускам сервис так
sudo service isc-dhcp-server restart
Остановить сервис так
sudo service isc-dhcp-server stop
Гоним весь траффик с eth0 на eth1 при помощи магии iptables
Вписываем в /etc/sysctl.conf строку net.ipv4.ip_forward = 1
iptables —table nat —append POSTROUTING —out-interface eth0 -j MASQUERADE
iptables —append FORWARD —in-interface eth1 -j ACCEPT
iptables-save > /etc/somewhere
В /etc/network/interfaces добавляем строку
Итого, при перезагрузке будут применяться эти правила.
После этих манипуляций скорее всего нужно, например, рестартнуть сетку на целевой машине, чтобы она получила айпишник
Шейпим траффик при помощи tc
Чтобы замедлить траффик на интерфейсе eth1, например, на 200ms
sudo tc qdisc add dev eth1 root netem delay 200ms
Чтобы удалить правило
sudo tc qdisc del dev eth1 root netem delay 200ms
Чтобы ограничить скорость исходящего траффика используем скрипт shape.sh (код ниже), запускать его так:
sudo bash shape.sh -i eth1 -s 512
sudo bash shape.sh -i eth1 -k
NB: интерфейсы надо задавать последовательно, то есть нельзя сказать -i 2, если не запускали -i 1
При манипуляциях с iptables не забывать что данные проходят через chain FORWARD, а не INPUT. Например:
#дропать dns-траффик к целевой машине iptables -I FORWARD -p udp --sport 53 -j DROP #удалить правило iptables -D FORWARD -p udp --sport 53 -j DROP
Скрипт shape.sh для шейпинга траффика авторства Никиты Налютина и Жени Ли:
#!/bin/bash # set -x DEV_UP='ifb0' UNITS='kbit' # kbps: Kilobytes per second # mbps: Megabytes per second # kbit: Kilobits per second # mbit: Megabits per second # bps: Bytes per second usage() < cat [[ -n "$1" ]] || < usage; exit 128; >start() < BANDWIDTH="$1" # up modprobe ifb ip link set dev ifb0 up # redirect tc qdisc add dev $DEV_DOWN ingress tc filter add dev $DEV_DOWN parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev $DEV_UP # parents tc qdisc add dev $DEV_DOWN root handle 1: htb default 42 tc qdisc add dev $DEV_UP root handle 1: htb default 42 # child SPEED=$(echo "$BANDWIDTH$UNITS") tc class add dev $DEV_DOWN parent 1: classid 1:42 htb rate $SPEED ceil $SPEED tc class add dev $DEV_UP parent 1: classid 1:42 htb rate $SPEED ceil $SPEED # filters tc filter add dev $DEV_DOWN protocol ip parent 1:0 prio 1 u32 match ip src $IP flowid 1:42 tc filter add dev $DEV_UP protocol ip parent 1:0 prio 1 u32 match ip dst $IP flowid 1:42 echo $SPEED >stop() < tc qdisc del dev $DEV_DOWN root tc qdisc del dev $DEV_UP root tc qdisc del dev $DEV_DOWN ingress ip link set dev ifb0 down >while getopts "s:i:k" OPTION do case $OPTION in i) DEV_DOWN=$OPTARG [[ -n "$DEV_DOWN" ]] || < usage; exit 128; >IP=`ip addr show $(echo wlan0) | grep 'inet ' | egrep -o "[0-9]\.[0-9]\.[0-9]\.[0-9]" | head -n1` ;; k) stop ;; s) stop [[ -n "$OPTARG" ]] || < usage; exit 128; >start $OPTARG ;; h) usage exit 1 ;; esac done
Запуск: sudo bash shape -i 1 -s 512
Останов: sudo bash shape -i 1 -k
Хелп: sudo bash shape usage
NB: интерфейсы надо раздавать последовательно, то есть нельзя сказать -12, если не запускали -i1
Еще один вариант:
modprobe ifb ip link set dev ifb0 up tc qdisc add dev eth1 ingress tc filter add dev eth1 parent ffff: protocol ip u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb0 tc qdisc add dev ifb0 root handle 1:0 netem delay 2ms tc qdisc add dev ifb0 parent 1:1 handle 10: tbf rate 2000kbit buffer 1600 limit 3000
sudo tc qdisc delete dev ifb0 root — чтобы очистить правила
Сообщение отредактировал ch_ip: 15 мая 2014 — 13:24
Если минарет, значит выше всех (с)
#12 vuchenka
Отправлено 15 мая 2014 — 11:05
ch_ip , спасибо большущее, буду разбираться.
«Не сломал — значит, не старался!»
#13 ch_ip
- ФИО: Павел Абдюшев
- Город: Москва
Отправлено 15 мая 2014 — 13:26
ch_ip , спасибо большущее, буду разбираться.
Добавил еще полную инструкцию по настройке машины (выше) + упрощенный вариант скрипта для шейпинга.
Плюс у нас был также скрипт Жени Ли, позволяющий имитировать проблемы сети:
#!/bin/bash usage() < cat [[ -n "$1" ]] || < usage; exit 128; >RULES=() while getopts "shvr:ci:" OPTION do case $OPTION in v) set -x ;; i) INTERFACE=$OPTARG ;; c) ACTION="del" ;; h) usage exit 1 ;; r) RULES+=("$") ;; esac done if [ -z $INTERFACE ]; then echo "-i [interface] is required" exit 128 fi ADD_COMMAND="tc qdisc add dev $INTERFACE root netem " DEL_COMMAND="tc qdisc del dev $INTERFACE root netem " SHOW_COMMAND="tc qdisc show dev $INTERFACE" if [[ "$ACTION" == "del" ]]; then eval "$DEL_COMMAND 2>/dev/null" exit_code=$? eval $SHOW_COMMAND exit $exit_code fi argument_count_error () < echo "Arg error: $1" exit 128 >for rule in "$"; do case $(echo $rule | awk '') in delay) if [[ "$(echo $rule | wc -w)" != 2 ]]; then argument_count_error delay; fi DELAY_VALUE=$(echo $rule | awk '') shell_command_delay=" delay $ms " ;; delay_normal) if [[ "$(echo $rule | wc -w)" != 3 ]]; then argument_count_error delay_normal; fi DELAY_VALUE_MAX=$(echo $rule | awk '') DELAY_VALUE_MIN=$(echo $rule | awk '') shell_command_delay_normal=" delay $ms $ms distribution normal " ;; loss) if [[ "$(echo $rule | wc -w)" != 3 ]]; then argument_count_error loss; fi LOSS_MIN_PERCENT=$(echo $rule | awk '') LOSS_MAX_PERCENT=$(echo $rule | awk '') shell_command_loss=" loss $% $% " ;; double) if [[ "$(echo $rule | wc -w)" != 2 ]]; then argument_count_error double; fi DOUBLE_PERCENT=$(echo $rule | awk '') shell_command_double=" duplicate $% " ;; noise) if [[ "$(echo $rule | wc -w)" != 2 ]]; then argument_count_error noise; fi NOISE_PERCENT=$(echo $rule | awk '') shell_command_noise=" corrupt $% " ;; mixing) if [[ "$(echo $rule | wc -w)" != 4 ]]; then argument_count_error mixing; fi MIXING_DELAY_VALUE=$(echo $rule | awk '') MIXING_MIN_PERCENT=$(echo $rule | awk '') MIXING_MAX_PERCENT=$(echo $rule | awk '') shell_command_mixing=" delay $ms reorder $% $% " ;; esac done COMMAND="$$$$$$$" eval "$DEL_COMMAND 2>/dev/null" eval "$COMMAND" exit_status=$? eval "$SHOW_COMMAND" exit $exit_status
Если минарет, значит выше всех (с)
data:URI и производительность, или как замедлить Firefox в 10 (десять) раз
Собственно, из заголовка должно быть почти все понятно. Но картинка не очень в тему: на ней надо нарисовать Лису, ползущую вслед догоняющему IE.
Это пост является ответом на «За бугром», ибо нашлась пара свободных часов, и было, чем их занять.
UPD Был обнаружен плагин — Wappalyzer — который на порядок замедлял отображение data:URI в Firefox. Но даже с его отключением Firefox продолжает проигрывать почти всем браузерам.
Но все по порядку.
Предыстория
Несколько месяцев назад ко мне в скайп постучался какой-то американец (с русским именем вроде) и спросил, что я знаю про последние оптимизации от Yahoo! (ну, те, где они data:URI наконец внедрили) и особенно про производительность data:URI. Я сказал, что, наверное (поскольку data:URI — это картинка в base64), последние несколько медленнее работают, чем обычные фоновые картинки, и вроде как должны подтормаживать.
Я быстро собрал предварительное окружение и через полчаса выдал предварительные результаты: data:URI тормозят, но иногда — очень сильно тормозят. Мне самому такой расклад показался подозрительным, поэтому я задвинул идею до лучших времен. И вот они настали 🙂
Тестовое окружение
Если совсем коротко, то корректно измерять рендеринг страницы в браузере — задача весьма и весьма непростая. В данном случае она решена в очень грубом приближении (которого хватает для общей оценки ситуации, но его больше особо нигде не применить). В начало страницы вставляем таймер, на событие onload вешаем завершение отсчета времени. Работать весь механизм будет или на локальном компьютере (чтобы устранить сетевые задержки), или на сервере с жестким кэшированием (браузеры в ходе одной сессии не перезапрашивают ресурсы с заголовками условного кэширования: это проверено, может быть, выложу статью и на эту тему).
Отлично. В итоге у нас есть «локальная» страница (после первого запроса к странице закрывают вкладку с ней, открываем новую вкладку и открываем в ней исходную страницу: это создает необходимую «чистоту» для эксперимента), которая отображается в браузере с жесткого диска. После этого время рендеринга будет (на 99%) зависеть от особенностей браузера, а не от скорости получения ресурсов.
Дополнительно, естественно, все тесты прогонялись по 10 раз. 3-дельта выбросы не брались в расчет. В итоге общая точность не меньше 10% (т.е. все, скорее всего, погрешность 3-5%).
Тест первый: картинки против фона
Когда-то давно существовали рекомендации против использования обычных картинок. Рекомендовалось все в фоновых изображениях делать. Это не так (результаты отображения закэшированной страницы в мс).
| Тест | Chrome2 | Fx3.5 | Opera10 | IE8 | IE6/7 |
|---|---|---|---|---|---|
| «Чистые» картинки | 33 | 10 | 52 | 189 | 182 |
| Фоновые картинки | 124 | 11 | 47 | 181 | 130 |
Как мы видим, «оторвался» только Chrome (Safari в расчет не брался из-за дико оптимизированных таймеров, которые срабатывают «слишком быстро»), но на фоне основных браузеров это незаметно.
Вывод: разницы по существу нет. Особенно, если брать в расчет суммарную рабочую область изображений в 670000 квадратных пикселей (дальше будет пояснено, почему это немного).
Тест второй: производительность data:URI / mhtml
Едем дальше. Помним, что data:URI поддерживается только IE8, для IE6/7 нужно использовать mhtml. Дополнительно IE8 не поддерживает картинки, большие 24 Кб. Поэтому в таблице для IE результаты mhtml, для остальных — data:URI.
| Тест | Chrome2 | Fx3.5 | Opera10 | IE8 | IE6/7 |
|---|---|---|---|---|---|
| data:URI и mhtml | 56 | 162 | 70 | 225 | 442 |
Уже здесь заметны «некоторые тормоза». Для Firefox рендеринг одних и тех же картинок обошелся вообще в 10 раз тяжелее. Но мы же рассматриваем применением этих техник для фоновых изображений? А для них:
| Тест | Chrome2 | Fx3.5 | Opera10 |
|---|---|---|---|
| фоновые картинки в data:URI | 83 | 155 | 69 |
Общая тенденция, как видим, сохраняется. Но это еще не все
Вывод: data:URI тормозит в Firefox, mhtml тормозит в IE.
Тест третий: производительность большого количества data:URI / mhtml
Внимательные читатели уже давно заготовили вопрос: что же нам показывают одни и те же неправдоподобно большие картинки. На «реальных» же сайтах все по-другому! Спешу их разочаровать: CSS Sprites размером 1000 на 1000 пикселей (миллион квадратных пикселей) встречаются не так редко. В среднем, на каждом сайт 5-20% области страницы занимают фоновые изображения. На разрешении 1200х1024 это примерно от 60 до 250 тысяч квадратных пикселей (т.е. всего в 3-10 раз меньше исходных изображений).
Но чего там дело встало, давайте возьмем 80 различных изображений (общей площадью 160 тысяч пикселей) и посмотрим, как браузеры из отрисовывают. А вот так (IE8 использует data:URI):
| Тест | Chrome2 | Fx3.5 | Opera10 | IE8 |
|---|---|---|---|---|
| много картинок в data:URI | 65 | 105 | 85 | 99 |
Что-то напоминает, правда? Да, мы уменьшили суммарный размер изображений в 4 раза, но при увеличении числа объектов в 40 раз (с 2 до 80) ситуация, практически, повторилась. На реальных страницах несколько десятков, порой и пара сотен фоновых изображений. Т.е. наши тесты все ближе и ближе к реальности.
Вывод: медленный рендеринг base64 зависит не только от размера области, но и от числа объектов.
Тест четвертый: лицом к лицу лица не увидать
Но и тут опять имело место небольшое лукавство: ведь мы не знаем, как поведут себя браузеры, если увидят такое же количество обычных картинок на странице — как они будут «тормозить» в этом случае? С этой целью было собрано еще 2 идентичных окружения. Для каждого использовалось 2 различных изображений и 10 объектов, вырезающих из них фон.
| Тест | Chrome2 | Fx3.5 | Opera10 | IE8 | IE6/7 |
|---|---|---|---|---|---|
| фоновые картинки | 124 | 24 | 63 | 166 | 131 |
| фоновые картинки в data:URI | 41 | 140 | 73 | — | — |
Для IE6/7/8 можно экстраполировать результаты, полученные из mhtml-страниц, либо пересобрать окружения с mhtml фоновыми картинками. Но основные результаты можно сказать уже сейчас.
Берем статистику использования браузеров, множим доли браузеров на относительное ускорение при использовании CSS Sprites (т.е. фоновых картинок) против data:URI / mhtml-подхода. Получаем цифру в 100мс для нашей суммарной области в 5*670000 = 3,35 миллиона пикселей (и 10 объектов). Для «среднего» сайта с 50 объектами с фоновыми изображениями и 100 тысячами пикселей в суммарной области мы получим порядка 15мс задержки при отображении каждой страницы (не важно, какое количество ресурсов находится в кэше браузера, сетевые задержки уже отыграли свое). Если у нас будет несколько сотен объектов с фоновыми изображениями, и общая область в миллион пикселей (например, какой-либо сложный веб-интерфейс), то средняя задержка для пользователей может вырасти до полусекунды и более. Такие вот пироги.
Вывод: data:URI + mhtml может существенно тормозить.
Что делать?
Все было бы неплохо, если Firefox и IE позаботятся о быстром рендеринге страниц и смогут отображать base64-данные так же быстро, как и обычные картинки. В этом случае использование множества base64-изображений будет, в общем случае, не хуже, чем CSS Sprites. Сейчас же наиболее оптимальным выходом является предварительное использование CSS Sprites, а потом конвертации минимального числа изображений в base64-формат, таким образом все издержки будут сведены к минимуму.
P.S. Если кому-то уж очень не нравятся фотографии на тестовых страницах — скиньте, пожалуйста, ссылки на любые подходящие по размеру — заменю. Просто ничего больше под рукой не было 🙂
P.P.S. Все расчеты в данной заметке оценочные. Они призваны показать только «слабые места» изображений в base64-формате, а не дать четкий алгоритм расчета, когда их можно использовать, а когда нет.