Я написал веб-скребок на Python, который очень хорошо работает на моем ноутбуке дома.После его установки на AWS EC2 производительность скребка ухудшается.Теперь я озадачен производительностью экземпляров EC2 (даже микро- и небольших экземпляров, см. Дополнительную информацию ниже).
Скребок в python: Как правило, внутренний цикл циклов выполняет следующее: (1)Скребок ищет URL-адреса на сайте (20 на сайт, один сайт = один "site_break").На втором этапе он (2) получает код soruce для каждого URL-адреса, на третьем этапе он (3) извлекает необходимую информацию в фрейм данных, а на четвертом шаге (4) сохраняет фрейм данных в виде pkl.После всех циклов он открывает и объединяет кадры данных и сохраняет их как csv.
Важнейшими (наиболее трудоемкими деталями) являются: (2) загрузка исходных кодов (ввод-вывод ограничен скоростью загрузки): программазаполняет ОЗУ исходным кодом (3) обработка исходных кодов (CPU 100%)
Чтобы полностью использовать ОЗУ и объединить похожие процессы, каждый цикл состоит из site_break = 100, то есть 100 сайтов * 20URL / сайт = 2000 URL.Это заполняет ОЗУ моего ПК до 96% (см. Ниже).Поскольку мне нужно ждать ответов сервера на шаге 1 и шаге 2, я реализовал многопоточность с maxWorkers = 15 (альтернативно 20-35 с похожими результатами).Эта реализация сокращает время выполнения на 80%.Я уверен, что мог бы получить некоторые другие.%, Реализовав asyncio.Тем не менее, я хочу начать с бережливого MVP.На шаге 3, потребляющем процессор, я не реализовал многопроцессорность (пока), потому что моей целью было экономичное / бесплатное внедрение на t2.micro (только с одним процессором).
Спецификация: Домашний ПК: Intel CoreПроцессор i7-6500, 2,59 ГГц (2 ядра, 4 логических процессора), оперативная память 8,00 ГБ, 64-разрядная, x64, 50 Мбит / с. Скорость загрузки (до 45 Мбит / с), Python 3.7.3, conda env
EC2 t2.micro: vCPUs = 1, RAM 1,0 ГиБ, производительность сети "от низкой до умеренной" (исследования на форумах говорят, что это может быть что-то выше 50 Мбит), Ubuntu 18.04, Python 3.7.3, conda env
EC2 t3a.small: vCPUs = 2, RAM 2,0 ГБ, производительность сети «от низкой до умеренной», но другой сайт AWS говорит мне: «до 5 Гбит / с», Ubuntu 18.04, Python 3.7.3,conda env
Поскольку объем оперативной памяти t2.micro составляет всего 1 ГиБ, я уменьшил site_break со 100 до 25. После этого объем оперативной памяти по-прежнему был заполнен, поэтому я уменьшил его в дальнейшем с 25 до 15,12, 10 и, наконец, 5. Для 12, 10 и особенно для 5 это работает претТы хорошо: мне нужно 5: 30 минут для на петле с site_break = 100 на моем ПК.t2.micro нужно 8-10 секунд для site_break = 5, что приводит к 3:00 минутам для 100 аналогичных сайтов, что удовлетворило меня в первый момент.К сожалению, возникает следующая проблема: после 20-30 циклов падение производительности.Время включения увеличивается быстро с 8 секунд до более 2 минут.Мое первое предположение было, что это низкий объем ОЗУ, во время маленьких циклов он, кажется, не работает полностью.После остановки и очистки ОЗУ производительность падает после второго или третьего цикла.Если я запускаю его через несколько часов, первый случай (с падением после 20-30 циклов) повторяется.
Поскольку я сначала подумал, что это связано с оперативной памятью, я запустил второй экземпляр на t3a.small сбольше ЦП, ОЗУ и производительность сети до 5 Гбит / с.Я нарезал взгляды на site_break = 25 и запустил скрипт.I все еще работает с постоянной скоростью 1: 39-1: 55 минут на цикл (что в половину меньше, чем у t2.micro в его лучшей фазе (10 секунд для 5 => 50 секунд для 25). Параллельно я началсценария с моего домашнего ПК с site_break = 25, и он постоянно работает быстрее: 1: 15-1: 30 минут на цикл (остановка по умолчанию приводит к замедлению загрузки на 10-15 секунд и обработке на 10-15 секунд).смущает меня.
Теперь мои вопросы: 1. Почему t2.micro детектирует после нескольких циклов и почему производительность так сильно меняется?2. Почему t3a.small на 50% медленнее, чем t2.micro?Я бы предположил, что «большая» машина будет быстрее во всех отношениях.
Это позволяет мне застрять:
Не хочу регулярно использовать мой домашний ПК(ежедневная очистка), так как соединение прерывается в 4 часа утра на небольшой промежуток времени и приводит к зависанию сценария).Более того, я не хочу, чтобы скрипт постоянно запускался вручную и на ПК и блокировал мой личный интернет-поток.
t2.micro: бесполезен, поскольку производительность после ухудшениянеприемлемо.
t3a.small: производительность на 10-20% ниже, чем у частного ПК.Я ожидал бы, что это будет лучше как-нибудь?Это позволяет моему сомнению отказаться от EC2.Более того, я не могу понять более низкую производительность по сравнению с t2.micro в начале.