TheDoctor

1) gpedit.msc - это не приложение. Приложение, открывающее эту оснастку - mmc.exe.
2) Насколько помню, в этой политике задаются не пути к приложениям, а имена исполняемых файлов.
3) Очень сомневаюсь, что из этой политики работают wildcard символы (я ни разу не пробовал).

Попробуйте вписать в список mmc.exe - после этого оснастка gpedit.msc должна открываться.

php.net/manual/ru/language.generators.syntax.php
yield - возврат из функции с сохранением текущего итерационного состояния этой функции.
При запросе следующего значения в цикле итерационном цикле - снова вызов этой функции с использованием сохранённого состояния, т.е. продолжение обработки данных с места возврата внутри этой функции.

Можно провести некую аналогию с "курсором" и местом обработки данных в позиции курсора.

set_error_handler(function ($err_no, $err_msg, $file, $line) {
    $telegram = new Telegram();
    $telegram->sendErrorToAdmin("\nerrNo: $err_no\ntext: $err_msg\nfile: $file\nline: $line\n\n");
});

:)

SELECT *
FROM `test`
WHERE date = operator_id

Потому что надо очень сильно потрудиться чтобы сделать приложение с 3-5 функциями тормозным.
Тем более что основной контент фото, а не какие-то "вычислительные процессы".

Да и сервер в обычном запросе отдает кусок верстки только: view-source:https://snapster.io/room-1
А вот аякс запросы уже далеко не такие шустрые.

Все файлы достаются из кеша (from memory cache).

это "заслуга" браузера, а не разработчиков сайта.

В целом сервис никому не упал вообще: https://snapster.io/room-1

1. То что приложение держится на основных серверах vk, а нагрузки большой у него нет.
Вот и они отдают 100% ресурсов.

Только как это влиять на скорость приложения должно? Это не проект на хостинге за 50 рублей, у него все ресурсы "свои", а не какая-то часть.
Естественно оно на серверах VK, более того оно скорее всего использует чуть более чем полностью функционал/инфраструктуру/апи ВК для работы. Достаточно увидеть ссылки на фото, авторизацию через ВК и т.д.

В общем если для вас 100-250мс это магия, то стоит посмотреть на свой код, а не на магическую работу kPHP или волшебные сервера VK.

Насколько знаю, при запуске "вручную" появляются переменные $_SERVER['argc'] и $_SERVER['argv'], также появляются другие переменные окружения пользователя.

Следовательно:

if (isset($_SERVER['argc']) && isset($_SERVER['argv'])) {
    define('SELFSERVICE', 1);
}

if (defined('SELFSERVICE')) {
    echo "I'm a service";
} else {
    echo "I'm a web-dispatcher";
}

Ну или запускать скрипт через http-запрос
curl "http://name.site/script.php?cron=1"

Передать ему входной параметр, например -cron.

В целом сразу вас расстрою, то что вы хотите нельзя "разобрать" за пару месяцев. На это уйдет пару тройку лет. И книги которые стоит по этой теме прочитать имеет смысл перечитывать. Ну и практика практика практика.

Так же хочу заметить что "архитектура" это не что-то эдакое, а общее понимание команды разработчиков о том как функционирует приложение. Если этого общего понимания нет - у вас нет архитектуры. У многих разработчиков понимание пропадает уже через пару месяце стихийной разработки. Так что помимо архитектуры важно еще и процессы/методологии разработки подтянуть.

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

но совершенно не имею представления о правильной архитектуре приложений на php

"Правильно" не бывает, все зависит от задачи. "Правильная" архитектура является:

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

Вот и все. Далее уже есть принципы SOLID (читать Роберта Мартина), GRASP (Крэйг Ларман), GoF (лучше тут почитать head first design patterns или даже начать с Мэта Зандстры, у него помимо паттернов еще про процессы мельком рассказано).

Ну и смысла в этом всем нет если вы еще до конца не осознали что есть инкапсуляция и полиморфизм. Многие могут рассказать что значат эти термины, но на практике эти знания они не могут применить (чаще всего страдает инкапсуляция)

или написании чего-то своего с нуля на чистом php

Такое решение может принимать только разработчик у которого уже есть за плечами хотя бы пяток лет опыта работы с различными (не одним) фреймворком и языками. В противном случае вы только будете заниматься бесполезным велосипедостроительством.

идеально было бы вообще подробно расписанное сравнение внутреннего устройства нескольких фреймворков

Берете Symfony или Zend и вперед. Все остальные фреймворки "проще". То есть скрывают больше от разработчика. После них уже можно брать что угодно.

p.s. еще прочитайте тут: www.phptherightway.com

1U? Дома? Он же турбинами будет выть катастрофически...
По задачам, вам подойдет неттоп на атоме.

iframe, который постоянное держит подключение с сервером по websocket.
Сайт обнавляется в ifreme который не трогает подключение, как закрется окно — сессию можно удалять.

Из плюсов вижу возможность передавать всю информацию о клиенте: куда нажал, сколько грузится страница.

С IE 6 можно подружить

habrahabr.ru/post/94921/

Прежде всего декомпозиция. Причем многоуровневая. Берёте весь проект, делите на основные части (сервер, БД, клиент). Каждую часть снова делите. На каждом уровне компонентов должно получаться немного.

Далее прототип каждого компонента.

Потом либо прототип превращаете в приложение, либо пишите с нуля с учетом опыта прототипа. Последнее намного лучше, но краткосрочно затратнее