Комментарии 3
Достойная статья. Заодно раскрывает вопрос «как посадить средний компьютер офисного планктона в лужу», для этого достаточно всего лишь…
В реальности у пользователей тоже пинг <1ms?
Для собственной структуры тестирования, легко создать условия плохого интернета — включите раздачу со смартфона в режиме Wi-Fi hot-spot, а сам телефон переведите в ручном режиме в 2G. Это более реальный (в абсолютных числах) сценарий, чем некая баба Фрося на Dial-up'e.
Пытаясь уменьшить число запросов, мы объединяли почти все js модули с лишними зависимостями в один большой файл. И вот на одной странице этот файл стал весить аж целых 3 МБ
В реальности у пользователей тоже пинг <1ms?
Для собственной структуры тестирования, легко создать условия плохого интернета — включите раздачу со смартфона в режиме Wi-Fi hot-spot, а сам телефон переведите в ручном режиме в 2G. Это более реальный (в абсолютных числах) сценарий, чем некая баба Фрося на Dial-up'e.
Согласны, чем ближе к реальности тестирование тем лучше, т.к. вылезают такие кейсы, про которые никто и никогда заранее не подумал бы. Правда, с таким подходом тоже свои огрехи есть. Например, нельзя изменять характеристики канала, нет контроля и точной воспроизводимости результата (в зависимости от расстояния и железа результаты могут сильно колебаться). Ну и если у вас сотрудники раскиданы по всей стране и даже в одном здании на разных этажах сидят — массово такое не организуешь.
Для локальной симуляции каналов с любыми характеристиками делается traffic shaping — например включается встроенный dummynet (в iptables или в ipfw). Это позволяет симулировать канал с любыми пингами, скоростями и потерями пакетов. Можно настраивать несколько разных шейперов одновременно и тестировать сайт с разными параметрами канала.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сложно о простом: как измерить время открытия страницы и не нажить себе врагов