idhttp + memo - вопрос быстродействия

[InternetStranger]

for i := 1 to 100 do
memo1.lines.Text:=idhttp1.Get('url');

Ууу. Как все круто )) Так жить определенно нельзя.)) Вы отправляете последовательно 100 соединений. Можно даже не замерять.

Попытайтесь получить всю информацию как можно за меньшее число запросов (это на веб-сервере) нужно менять (т.е. без цикла). Если не получится ищите способ выполнять их асинхронно, т.е. параллельно. Возможно это в какой-то из упомянутых библиотек реализовано.
Если не ошибаюсь типичный веб-сервер (в зависимости от настроек) позволяет одновременно до 20-35 соединений. Т.е. ваши 600 запросов можно разбить на пачки, скажем, по 25 запросов и так их выполнять. В несколько раз ускорите.

----
PS: в прошлом сообщении я дописал пост, если Вы не обратили внимания ))

[Базиля]

PS: в прошлом сообщении я дописал пост, если Вы не обратили внимания ))

Наверное так бы и не углядел

И не поймете пока не поймете какой из этапов занимает большую часть времени. Замерьте время выполнения отдельных шагов и сформулируйте конкретный вопрос.

Ну уж теперь я понял в чем проблема
Благодарю!

Кстати "600 строк" это сколько в мегабайтах ?

Полагаю вы имели ввиду страниц?
С 1-ой странички:


Я не знаю, как вообще принято, много ли это информации? (я конечно же имею ввиду в сравнении получения кода других сайтов)
С 600 страниц будет порядка 63мб.
Полагаю для уменьшения объема получения информации нужно применять сжатие, но это пока что не столь важно, в дальнешем попробую разобраться, после решения текущей проблемы.

Попытайтесь получить всю информацию как можно за меньшее число запросов (это на веб-сервере) нужно менять (т.е. без цикла).

Немного не понял вашей мысли

Если не получится ищите способ выполнять их асинхронно, т.е. параллельно. Возможно это в какой-то из упомянутых библиотек реализовано.

Искал - искал, кроме потоков, вроде как других вариантов и нет....
Самое что интересное, такое чувство что подобная проблема только у меня возникла или я так и не научился пользоваться поиском.
Я с потоками честно говоря мало знаком - пока еще не было необходимости ими пользоваться. Но вот так навскидку, если я правильно понимаю вашу мысль и то для чего потоки предназначены - они здесь не нужны. Или я ошибаюсь ?

Т.е. ваши 600 запросов можно разбить на пачки, скажем, по 25 запросов и так их выполнять. В несколько раз ускорите.

Можно пожалуйста пример?

P.S. Опробовал только что Synapse. Также запихал в цикл (хоть и знаю что не правильно, но так, для сравнения) - по времени вышло даже больше.

[s-andriano]

Базиля, советую еще раз внимательно перечитать тему, особенно то, что пишет InternetStranger.
И обратите внимание на следующие моменты:
1. Если полный цикл состоит из:
- получения информации,
- ее обработки,
- передачи дальше (например, в memo),
то для того, чтобы хоть как-то соптимизировать, нужно иметь четкое представление, на котором именно из перечисленных этапов происходят наибольшие задержки.
Например, если 1-й этап занимает 98% времени, а остальные по 1%, пытаться ускорять 2 и 3 этапы совершенно бессмысленно.

2. Единица информации "страница" применяется исключительно в бумажном делопроизводстве. В программировании принято использовать байт и его производные.
Это необходимо для постановки диагноза. А без диагноза, как известно, лечение невозможно.

3. Судя по Вашим оценкам, 21 Мбайт информации (200 страниц) Вы получаете за 18 секунд, что соответствует скорости передачи 1.2 Мбайт/с или около 10 Мбит/с.
Если у Вас скорость соединения 10 Мбит/с, то, по сути Вы достигли потолка пропускной способности канала. В этом случае единственное, что может помочь - сжатие информации.
Если же ширина канала много больше 10 Мбит/с, то можно говорить об оптимизации какими-то другими средствами. Например, о сокращении количества запросов или их асинхронной обработке.

4. Кроме получения из И-нет тормоза могут быть и в других местах. Но для этого нужна диагностика.

[Базиля]

s-andriano
Благодарю за отзыв!

И обратите внимание на следующие моменты:
1. Если полный цикл состоит из:
- получения информации,
- ее обработки,
- передачи дальше (например, в memo),
то для того, чтобы хоть как-то соптимизировать, нужно иметь четкое представление, на котором именно из перечисленных этапов происходят наибольшие задержки.
Например, если 1-й этап занимает 98% времени, а остальные по 1%, пытаться ускорять 2 и 3 этапы совершенно бессмысленно.

Уже с 99% вероятностью могу сказать - проблема в 1-ом подпунтке (получение информации).

3. Судя по Вашим оценкам, 21 Мбайт информации (200 страниц) Вы получаете за 18 секунд, что соответствует скорости передачи 1.2 Мбайт/с или около 10 Мбит/с.
Если у Вас скорость соединения 10 Мбит/с, то, по сути Вы достигли потолка пропускной способности канала. В этом случае единственное, что может помочь - сжатие информации.
Если же ширина канала много больше 10 Мбит/с, то можно говорить об оптимизации какими-то другими средствами. Например, о сокращении количества запросов или их асинхронной обработке.

Только что производил сжатие получаемой информации.
В итоге получил такой резкий прыжок вниз со 107кб до 15 кб
И скорость загрузки 100 страниц упала на 2 секунды

Но все-таки, вот хотелось бы ознакомиться с:

Например, о сокращении количества запросов или их асинхронной обработке.

Какими средствами это можно реализовать?

[InternetStranger]

Ну вот и выходные, погода прекрасная, попробую подытожить вышесказанное и кое-что пояснить (если где ошибусь, просьба поправить). Вдруг кто-то что-то новое для себя откроет ))
Во вложении пример как браузер запрашивает файлы для отображения текущей страницы (изображена временная шкала). Всего данная страница потребовала 41 запрос. Обратите внимание, что он шлет запросы "пачками" по ~5 штук (не всегда конечно). Пока пачка не прогрузилась, загрузка следующих блокируется (серая полоса).

На самом деле обычно сервера (как уже было сказано) поддерживают 20-35 запросов параллельно с одно адреса, браузер видимо перестраховывается, к тому же много соединений одновременно - это довольно большая нагрузка на веб-сервер (актуально при высокой посещаемости).
Более-менее продвинутый webdev-народ знает об этом, и обходит данное ограничение с помощью CDN.

Из картинки можно извлечь несколько полезных мыслей (попробую их структурировать):
1) Представьте, если бы браузер слал запросы последовательно (в цикле, как это делаете Вы), то ждать пришлось открытия страницы бы раз в 5 дольше как минимум (примерно).
2) Каждый запрос состоит из кучи действий, рекомендую изучить их внимательно. Видно, как файлы размера и 1 Кб, и 32 Кб загружаются почти одинаковое время. Скорость интернета позволяет получить их непосредственно чуть-ли не мгновенно. Зато при запросе каждого файла "Ожидание" и "Подключение" занимают ~ 0.5 сек. В данном случае 100 последовательных запросов длились бы минимум 50 сек.
3) Таким образом, скорость открытия данной страницы уже давно не упирается в скорость (широкополосного) интернета пользователей. В данном случае проблема сервера + неоптимизированность дизайна.

Основных выходов отсюда два:
1) Уменьшить количество загружаемых файлов. В случае веб-сайтов: css и js-файлы (где возможно и картинки тоже) объединяются в один. Общий размер остается тот же (иногда даже увеличивается), зато запросов требуется меньше.
2) Загружать данные параллельно. Готовых библиотек найти как-то не удалось. Реализовывать придется видимо только с помощью потоков.

PS:

Только что производил сжатие получаемой информации. В итоге получил такой резкий прыжок вниз со 107кб до 15 кб. И скорость загрузки 100 страниц упала на 2 секунды

Ну вот теперь и наверное понимаете, что большую часть оставшегося времени у Вас "Ожидание" и "Подключение" длятся.

[Базиля]

InternetStranger
Спасибо большое за информацию!
Уже пытаюсь решить свою проблему через потоки. Видимо, как вы уже и сказали, других способов нет

[Базиля]

В общем, вроде как начинаю разобираться с потоками.
И пришел к такому выводу. Или я не до конца все еще понял и не разобрался или же так оно и есть.
Я свою задачу не смогу выполнять многопоточным приложением.
У меня стоит цель считывать одну за другой 200 страниц, при этом мне необходимо последовательно в одном порядке забирать с них информацию.
Правильно ли я понимаю что потоки тут не применить для ускорения работы программы?
P.S. И еще, пользуяюсь случаем - хочу узнать (прощу прощения за оффтоп). Возможно ли реализовать, чтобы класс форма (гланый поток получается) пораждала два потока которые будут работать одновременно, в независимости друг от друга? (выполнять свои независимые от других потоков задачи) Не будет ли производить это нагрузку?

procedure TForm1.Button1Click(Sender: TObject);
var
  NewThread1: TNewThread1;
  NewThread2: TNewThread2;
begin
  NewThread1:=TNewThread.Create(true);
  NewThread1.FreeOnTerminate:=true;
  NewThread1.Priority:=tpLower;
  NewThread1.Resume;
 NewThread2:=TNewThread.Create(true);
  NewThread2.FreeOnTerminate:=true;
  NewThread2.Priority:=tpLower;
  NewThread2.Resume;
end;

Этот кусок не является бредом?

Благодарю

[bakanaev]

Сообщение от Базиля

У меня стоит цель считывать одну за другой 200 страниц

А с чем это связанно? Нельзя скажем загрузить сразу пять страниц и потом уже по порядку их обработать? И так далее..

[InternetStranger]

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

P.S. И еще, пользуяюсь случаем - хочу узнать (прощу прощения за оффтоп). Возможно ли реализовать, чтобы класс форма (гланый поток получается) пораждала два потока которые будут работать одновременно, в независимости друг от друга? (выполнять свои независимые от других потоков задачи) Не будет ли производить это нагрузку?

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

ps: Понимаю твои затруднения, не сразу удается переключить мышление с последовательных алгоритмов, на асинхронные, событийные. Сам, помню, не сразу воткнулся.

[Базиля]

bakanaev
InternetStranger

А с чем это связанно? Нельзя скажем загрузить сразу пять страниц и потом уже по порядку их обработать? И так далее..

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

Честно говоря не подумал о таком варианте
Но вот пока что слабо представляю как это реализовать, буду думать

InternetStranger

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

А вот такой момент, как я полагаю чем больше будет организованно потоков, тем ведь быстрее можно грузить страницы - например, создал я 6 потоков, они грузят 6 страниц и потом идет их обработка. Верно? Наверное, как я догадываюсь, большое количество потоков не рекомендуется, так как будет большая нагрузка на систему.

ps: Понимаю твои затруднения, не сразу удается переключить мышление с последовательных алгоритмов, на асинхронные, событийные. Сам, помню, не сразу воткнулся.

Да, действительно Пока еще не до конца все - таки понимаю весь процесс

Благодарю!