Как лучше обработать 10 млн. гет запросов? | Потоки обрываются

[Tuw]

Нужно в общем сделать 10 млн. гет запросов.
Шаб такой: Есть список текстовой(список состоит из 10 млн. строк 7-значных чисел от 0000000 до 9999999. Из него берется строка и вставляется в гет запрос. Ответ пишется в другой файл. Сейчас протестил 100к строк, и обработалось только 96к строк. Сейчас добавил bad регулярку и надеюсь, что это исправит ситуацию.
P.S. Может есть способ лучше, обработать 10 млн. гет запросов?

 

[ol1ver]

Разбей файл на маленькие части по 10k через тот же keywordkeeper, дергай рандомно файл из папки и удаляй файл когда 0 строк, перед этим проверяй кол-во файлов в папке и если что стопай. Так по циклу с good/bad

 

[7make]

Зачем в файле хранить, если на лету можно генерить числа?

 

[Tuw]

Зачем в файле хранить, если на лету можно генерить числа?

Можно сделать конеч

Зачем в файле хранить, если на лету можно генерить числа?

Примерно вот так? Но при таком же варианте я не смогу контролировать потоки, если я нажму стоп проекта и рандом сгенерировавшиеся числа остановятся например 0001321, то когда я начну заново, то и генериться числа будут заново с 0000001, а не с 0001321. Или я не так думаю?

 

[Tuw]

Разбей файл на маленькие части по 10k через тот же keywordkeeper, дергай рандомно файл из папки и удаляй файл когда 0 строк, перед этим проверяй кол-во файлов в папке и если что стопай. Так по циклу с good/bad

В общем разбил большой файл, берет рандом файл и строку, но скорость жуть какая маленькая

 

[ol1ver]

Зачем в файле хранить, если на лету можно генерить числа?

лол когда я пытался сохранить глобальую переменную последнего id - еще та работка

 

[Mikhail B.]

Можно попробовать БД использовать.
Ты лучше объясни, что конкретно ты хочешь.

Например можно сделать счетчик который будет +1 прибавлять и будет записывать контрольное число в список, типо сохранения, и когда ты начнешь вновь, то он просто возьмет это число со списка и дальше продолжит счетчик.

Другой вопрос, почему обработалось 96к вместо 100к. И тут ответ почему то не должен быть, либо ты ищешь причину ошибки, либо делаешь иначе. Могу предположить, что некоторые запросы просто не прошли. Нужно сделать лог в который будешь записывать результаты работы, а потом уже анализировать его.

 

[Tuw]

Можно попробовать БД использовать.
Ты лучше объясни, что конкретно ты хочешь.

В диапазоне 10 млн. юрлов(простые гет запросы) содержатся сотни, тысячи юрлов, в которых есть данные, которые мне нужны. Если на юрле ничего нет, то выдает ответ 404, а если есть, то 200. Я думал, что регулярка на проверку 404 или 200 загружает шаб, убрал их и оставил лишь запись ответов сервера в файл, но результат все тот же, все происходит довольно медленно.

Например можно сделать счетчик который будет +1 прибавлять и будет записывать контрольное число в список, типо сохранения, и когда ты начнешь вновь, то он просто возьмет это число со списка и дальше продолжит счетчик.

Оп, а это идея, спасибо! Попробую.

Можно попробовать БД использовать.

Тоже попробую, спасибо. Если взять строчку из бд с ее удалением берет в разы меньше ресурсов, то думаю, должно сработать.
Есть такой перехватчик запросов, Burp Suite, в нем есть Intruder, вот через него пробовал, вообще шик, все быстренько делает с нужным диапазаном, но там немножко не то, что мне нужно, там видимо так быстро все делает, ибо наверное весь диапазон сгенерированных чисел как-то хранится в оперативке, вот бы в Зенке такое(сейчас ищу по всему форуму это, если кто-то знает можно ли хранить в RAM-e, киньте пожалуйста ссылку, буду благодарен)

 

[ol1ver]

Можно попробовать БД использовать.
Ты лучше объясни, что конкретно ты хочешь.

Например можно сделать счетчик который будет +1 прибавлять и будет записывать контрольное число в список, типо сохранения, и когда ты начнешь вновь, то он просто возьмет это число со списка и дальше продолжит счетчик.

Другой вопрос, почему обработалось 96к вместо 100к. И тут ответ почему то не должен быть, либо ты ищешь причину ошибки, либо делаешь иначе. Могу предположить, что некоторые запросы просто не прошли. Нужно сделать лог в который будешь записывать результаты работы, а потом уже анализировать его.

у меня порой из за 70 потоков прерывалась запись и обнулялся глобальный счетчик и id записывался рандомного последнего потока

 

[emel]

Используй метод HEAD . Делаешь чек на 200. Потом нормальные парсишь. После парсинга сравниваешь с удалением отработанных. То что осталось, снова парсишь. Оптимально БД, но можно и на таблицах.