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

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

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

P.S. Ботнет это вообще не из той оперы, это не сервера в основном, а пользовательские компьютеры-рабочие станции, зараженные ПО для удаленного доступа, для любой полезной работы не используются, так как заведомо это противозаконно.

Взято отсюда:

1) Войдите в MySQL
mysql -u your_user -p

2) Посмотрите список залоченых таблиц:
show open tables where in_use>0;

3) Посмотрите список процессов (один из них лочит вашу таблицу):
show processlist;

4) Убейте этот процесс (процессы)
kill <put_process_id_here>;

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

<?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 сайте :)

Думаю проблема в document_root, в openserver его необходимо сменить на /web, а исполняемый файл указать не index.php, а app.php (или app_dev.php). Альтернативно - web/app.php можно переименовать в web/index.php, тогда поменяв document_root все должно работать

Думаю главная проблема бесплатного хостинга - невозможность сменить document_root, для symfony document_root должен указывать на подпапку web и искать файл app.php, а по дефолту хостинги ищут index.php в корне папки. Если web/app.php еще можно переименовать, то с document_root необходимо найти хостинг, позволяющий его менять

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