Асинхронная передача GET/POST

[workoles]

Привет! Есть вопрос к знатокам и админам. Скажите, пожалуйста, можно ли в ZP отправить несколько GET/POST запросов одновременно и положить ответы в несколько переменных или список? Интересует реализация на C#.

 

[etyipin]

Было на в конкурсной статье http://zennolab.com/discussion/threads/parallelnye-zaprosy.19609/

 

[workoles]

Было на в конкурсной статье http://zennolab.com/discussion/threads/parallelnye-zaprosy.19609/

Да, это решение я уже изучил. Спасибо. Но по большей части интересуют POST запросы и в идеале при помощи стандартных методов ZP (чтобы была возможность менять UserAgent и добавлять пользовательские HTTP заголовки).

 

[etyipin]

А что мешает заменить GET на POST https://help.zennolab.com/en/v5/zennoposter/5.15.0.0/webframe.html#topic609.html ?

 

[workoles]

А что мешает заменить GET на POST https://help.zennolab.com/en/v5/zennoposter/5.15.0.0/webframe.html#topic609.html ?

Спасибо. Разобрался.

 

[workoles]

Возникла проблема при работе с асинхронным GET/POST. Опишу её суть на примере. Мне необходимо скачать 100 страниц с целевого сайта в асинхронном режиме. Но при этом это надо сделать так, чтобы необходимая информация с этих страниц сохранилась в список по порядку, т.е. сперва сохранилась информация со страницы 1, потом со страницы 2, потом 3... и т.д. Но при запуске парсинга в асинхронном режиме поток 90 может отработать раньше, чем поток 10. Соответственно данные с со страницы 90 лягут в список выше, чем со страницы 10 и получится каша. Пауза между потоками не решает задачи (проверил на практике), да и использование паузы — это плохое решение, т.к. пауза сводит на «нет» всё преимущество параллельного выполнения. Соответственно нужно нечто асинхронной очереди, чтобы запросы отправились последовательно, но результат обрабатывался одновременно.

P.S.
Или, быть может, есть аналог вот этой опции:

но для кубиков GET/POST запросов? Т.е. чтобы можно было было отправить несколько GET/POST запросов один за другим без ожидания ответа.

 

[doc]

по ссылке, что давали выше в цикле есть индекс. ЧТо мешает сохранять последовательность за его счёт?

 

[workoles]

по ссылке, что давали выше в цикле есть индекс. ЧТо мешает сохранять последовательность за его счёт?

Изначально я так и реализовал, после чего и столкнулся с проблемой. Дело в том, что потоки в рамках данного цикла стартуют одновременно, но код выполняют с разной скоростью (в основном за счет разной скорости ответа удаленного сервера), поэтому к финишу они приходят в разное время даже если каждый индекс умножить на секундную паузу.. Конечно, чем дольше пауза, тем выше вероятность последовательного завершения, но тем дольше и общее время выполнения. Настолько дольше, что весь смысл параллельности теряется.

 

[doc]

не надо ничего умножать. Нужно создать массив с количеством элементов равному количеству ссылок и записывать в цикле ответы по индексу

 

[workoles]

не надо ничего умножать. Нужно создать массив с количеством элементов равному количеству ссылок и записывать в цикле ответы по индексу

Буду благодарен, если покажете на примере того кода, который дан по ссылке выше.

 

[workoles]

Буду благодарен, если покажете на примере того кода, который дан по ссылке выше.

Хотя в общем-то я смысл понял, предложение имеет место быть, но в данном случае все осложняется тем, что каждый запрос должен содержать параметр в виде порядкового номера обращения к серверу и нельзя допустить, чтобы сперва обращение было сделано к 90 странице, а затем к 10 (если вернуться к примеру), т.е. по факту сами запросы должны быть сделаны последовательно, но без задержки на ожидание ответа.

 

[amyboose]

Хотя в общем-то я смысл понял, предложение имеет место быть, но в данном случае все осложняется тем, что каждый запрос должен содержать параметр в виде порядкового номера обращения к серверу и нельзя допустить, чтобы сперва обращение было сделано к 90 странице, а затем к 10 (если вернуться к примеру), т.е. по факту сами запросы должны быть сделаны последовательно, но без задержки на ожидание ответа.

Такое сделать нереально в многопоточном режиме. Ты никогда не можешь сказать какой из списка потоков будет выбран процессором следующим. Но можно примерно одновременно начать отправлять запросы

 

[doc]

Хотя в общем-то я смысл понял, предложение имеет место быть, но в данном случае все осложняется тем, что каждый запрос должен содержать параметр в виде порядкового номера обращения к серверу и нельзя допустить, чтобы сперва обращение было сделано к 90 странице, а затем к 10 (если вернуться к примеру), т.е. по факту сами запросы должны быть сделаны последовательно, но без задержки на ожидание ответа.

это в рекламный раздел)

 

[workoles]

Такое сделать нереально в многопоточном режиме. Ты никогда не можешь сказать какой из списка потоков будет выбран процессором следующим. Но можно примерно одновременно начать отправлять запросы

Понял. Жалко, конечно. Параллельность хорошая штука, но, видимо, не универсальна.

 

[workoles]

@nuaru Скажите, пожалуйста, есть ли возможность сделать аналогичную опцию:

но не для браузера, а непосредственно для кубиков GET/POST запросов? Т.е. чтобы можно было отправить несколько GET/POST запросов последовательно один за другим без ожидания ответа.

 

[TeslaCo]

Спасибо. Разобрался.

Выложите код что получилось, пожалуйста.