Владислав Ивасик

Так как olx не имеет api - нужно писать софт, который залогинится от реального пользователя и get-post запросами будет поочередно постить обьявления одно за одним, только могут быть подводные камни (не исследовал систему безопасности olx, детальнее не скажу) в виде CSRF токенов на формах, капч, порога обьявлений на единицу времени.

Без уменьшения качества - никак, главное чтобы уменьшение качества не повлияло на саму картинку (ее восприятие), вот есть небольшой гайд, (отсюда):

<?php 
	function compress($source, $destination, $quality) {

		$info = getimagesize($source);

		if ($info['mime'] == 'image/jpeg') 
			$image = imagecreatefromjpeg($source);

		elseif ($info['mime'] == 'image/gif') 
			$image = imagecreatefromgif($source);

		elseif ($info['mime'] == 'image/png') 
			$image = imagecreatefrompng($source);

		imagejpeg($image, $destination, $quality);

		return $destination;
	}

	$source_img = 'source.jpg';
	$destination_img = 'destination .jpg';

	$d = compress($source_img, $destination_img, 90);
 ?>

Если нюансы HTTP редиректов еще можно учесть - то javascript редиректы - проблема, там в коде может и не быть ссылки редиректа, а она может получаться с другого хоста аякс запросом (рекламные сети, например так делают). Чтобы пройти по всем редиректам - необходимо качественно выполнять все js на страницах (используя какие-то движки рендера js, например v8 (https://developers.google.com/v8/?hl=ru)

Я бы делал следующим образом: сделал бы систему ивентов, например - создалась страница, добавлен коммент, и когда происходит одно из этих собитый - тригерится ивент, обработчик его ловит, пишет основные данные в отдельную таблицу (что-то типо EventLog), поля, которые содержит эта таблица - user_id(int), date(datetime), event_type(tinyint), triggered_on(int), где user_id айди юзера, с привязкой его в энтити напрямую, date - дата события, event_type - константа типа ивента (описать можно константами или другим удобным способом, я бы, например, делал дискриминатором по полю event_type с под-сущностями, каждая из которых будет иметь привязку на свой ожидаемый тип сущности, наследуя геттеры, тут есть большое пространство для улучшения взаимодействия), triggered_on - id записи в базе, которая была создана-обновлена etc. После этого имеем список всего, что делал юзер, таблица достаточно простая, логирование можно расширять.
Данный этап вносит некую денормализацию данных, чтобы упростить их поиск.

Этап второй - выборка. Тут строится нехитрый запрос, который исключает данные, что этому пользователю не надо.
Джойном подгружается сущность юзера, остальные данные можно получить на момент рендера этого списка (если есть дискриминатор, предложенный выше, запросив что-то типо {{ eventLog.triggeredOn.title }}).

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

В любом случае, построение эффективной бизнес-логики - зависит от всех нюансов задачи, того финальный результат составлять Вам, такие задачи никто не решит в ответ на вопрос на Question-Answer сайте :)

Можно использовать Power Shell (что-то на подобии терминала linux в windows), там есть комманда tail, которая как раз позволяет читать лог в реальном времени. Документацию можно найти тут - https://blogs.technet.microsoft.com/rmilne/2016/06...

Смотрите и другие строковые функции.
www.softtime.ru/bookphp/gl3_3.php
Уверен, вы для себя найдете там немало интересного. Конечно, способ покруче - так preg_match с регуляркой, но если такое проделать сложно пока - пользуйтесь строковыми функциями.