- Регистрация
- 22.03.2012
- Сообщения
- 2 406
- Благодарностей
- 1 473
- Баллы
- 113
Часто, при выполнении задач люди ошибаются— не всегда больше, значит лучше.
У меня была задача— спарсить данные с сайта. Стандартно отдается только 10 строк данных в формате JSON.
Методом тыка было выявлено, что сайт может отдавать от 0 до 1500 строк за один раз.
Ну и сразу же пришла гениальная мысль в голову - "Будем парсить только по 1,5к, если меньше не будет требоваться!"
Воспользовавшись стандартным кубиком разбора JSONа я был немного огорчен. Такой объем данных он разбирал по 15 минут. А стандартные 10 строк "разбирало" моментально. Да и запросы очень глючили на моем билде( JSON— долго принимает и разбирает и Запрос VS Браузер. 0:1 ).
И тут пришла в голову вторая гениальная мысль— нужен эксперимент! Прям лабораторная работа, как в универе Так как делать было нехрен( голова отказывалась работать в нужном русле), был оформлен такой себе отчет
ЗенноЛаб
Лабораторная работа №1
Тема: "Парсинг сайта на запросах. Получение данных в формате JSON"
Цель работы: Определение необходимого числа строк для оптимальной работы парсера, учитывая время запроса к сайту, а так же сохранения полученных данных в таблицу.
Оборудование и материалы: Zennoposter Pro 5.10.7.0 ( позднее 5.10.5.1), yandex.ru, Asus ZenBook.
Ход работы
Вводные данные:
Так что эксперимент будет не таким красочным, как планировалось
Во время работы было выявлено, что такими параметрами как "время запроса" и "время сохранения в таблицу" можно пренебречь, они актуальны только на первых шагах итерации, когда время "разбора" сопоставимо им. Собственно, только благодаря им не был наилучшим вариант отправки запроса на минимальное количество строк.
Ниже, в таблице, приведен красочный наглядный пример результатов эксперимента
Из таблицы видно, что оптимальным является запрос на 75 строк( в данных н.у.).
При таком наборе параметров мы можем спарсить 10к строк за 12 минут.
Если бы послушали свое внутреннее "Я" которое хотело все и сразу— пришлось бы ожидать 2 часа 05 минут.
К тому же, на разбор 75 строк у нас ушло 3,8 сек, а на 1000 - 742 сек — что при увеличении количества строк "всего" в 10 раз, увеличило время выполнения более чем в 200 раз.
Ниже представлена диаграмма ( ну куда ж лабораторная работа без диаграммы )
Выводы. Ставить правильный билд, слушать @DmitryAk и переводить разбор JSON из стандартного кубика в C#, не гнаться за большими цифрами, они не всегда оптимальны.
Не парсь за раз то, что не сможешь распарсить быстро
Конфуций, 489 год до н. е.
У меня была задача— спарсить данные с сайта. Стандартно отдается только 10 строк данных в формате JSON.
Методом тыка было выявлено, что сайт может отдавать от 0 до 1500 строк за один раз.
Ну и сразу же пришла гениальная мысль в голову - "Будем парсить только по 1,5к, если меньше не будет требоваться!"
Воспользовавшись стандартным кубиком разбора JSONа я был немного огорчен. Такой объем данных он разбирал по 15 минут. А стандартные 10 строк "разбирало" моментально. Да и запросы очень глючили на моем билде( JSON— долго принимает и разбирает и Запрос VS Браузер. 0:1 ).
И тут пришла в голову вторая гениальная мысль— нужен эксперимент! Прям лабораторная работа, как в универе Так как делать было нехрен( голова отказывалась работать в нужном русле), был оформлен такой себе отчет
ЗенноЛаб
Лабораторная работа №1
Тема: "Парсинг сайта на запросах. Получение данных в формате JSON"
2017
Цель работы: Определение необходимого числа строк для оптимальной работы парсера, учитывая время запроса к сайту, а так же сохранения полученных данных в таблицу.
Оборудование и материалы: Zennoposter Pro 5.10.7.0 ( позднее 5.10.5.1), yandex.ru, Asus ZenBook.
Ход работы
Вводные данные:
- Отправляем запрос с параметром, указывающим количество возвращаемых строк. От 0 до 1000 с шагом 25.
- В каждой полученной строке— около 160 переменных(значений), которые затем сохраняем в таблицу.
Так что эксперимент будет не таким красочным, как планировалось
Во время работы было выявлено, что такими параметрами как "время запроса" и "время сохранения в таблицу" можно пренебречь, они актуальны только на первых шагах итерации, когда время "разбора" сопоставимо им. Собственно, только благодаря им не был наилучшим вариант отправки запроса на минимальное количество строк.
Ниже, в таблице, приведен красочный наглядный пример результатов эксперимента
Таблица №1
Из таблицы видно, что оптимальным является запрос на 75 строк( в данных н.у.).
При таком наборе параметров мы можем спарсить 10к строк за 12 минут.
Если бы послушали свое внутреннее "Я" которое хотело все и сразу— пришлось бы ожидать 2 часа 05 минут.
К тому же, на разбор 75 строк у нас ушло 3,8 сек, а на 1000 - 742 сек — что при увеличении количества строк "всего" в 10 раз, увеличило время выполнения более чем в 200 раз.
Ниже представлена диаграмма ( ну куда ж лабораторная работа без диаграммы )
Выводы. Ставить правильный билд, слушать @DmitryAk и переводить разбор JSON из стандартного кубика в C#, не гнаться за большими цифрами, они не всегда оптимальны.
Последнее редактирование: