rPman

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

Чтобы на стороне клиента мониторить события, которые им хочет сообщать сервер, вам нужны websocket или хотя бы long pooling (устаревшая технология на тот случай, если вебсокеты не доступны).

Первое очень просто - клиент держит специальное подключение к специальному websocket серверу, который вы должны поднять на сервере (реализация вебосокет есть на всех популярных языках, начиная с php).
Пример сервера - https://reactphp.org/
На клиенте - штатный https://developer.mozilla.org/en-US/docs/Web/API/W...

Второе - специальный запрос к бакенд серверу на файл, который сервер не отдает до тех пор пока ему не понадобится что то сообщить клиенту (причем каждому клиенту сервер по своему отдает это файл), это реализуется на любом языке очень просто, но не так эффективно как через вебсокет сервер.
Пример -https://github.com/panique/php-long-polling

лучший способ контроля за кешем на стороне клиента - это менять имя/ссылку на контент

т.е. вместо подключения main.css пиши main.css?x=1 (в следующий раз сменишь 1 на 2 и т.п.), вебсервер статику вернет ту же самую но на стороне клиента это будет совершенно новый файл

Самое верное, автоматизировать процесс, в момент выкладывания файла на веб сервер, менять ихимя (и во всех местах его использования) на содержащее хеш сумму от его содержимого, например: 3f90ee1b.main.css

p.s. чтобы на клиенте файл был принудительно запрошен игнорируя кеш, можно нажать ctrl+f5

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

Советы:
* не используйте http rest с генерацией html на сервере (устаревший подход, но много готовых фреймворков его используют, у этого подхода только одно достоинство - дешевая горизонтальная масштабируемость), ваш бакэнд должен выглядеть готовым веб сервером и не должен на каждый запрос делать лишние инициализации.
* переносите все что только можно на сторону клиента, всякие single page application, в идеале бакэнд должен быть чем то типа прослойки к базе данных и авторизация, все остальное пусть работает на клиенте
* уменьшайте количество запросов (т.е. запросить 1 мб в виде одного файла менее ресурсоемко чем запросить сто по десять килобайт), никаких периодических запросов на сервер для проверки статусов, пользуйтесь вебсокетами
* все что неизменно или редко меняется должно быть статикой, на ее поддержку тратится несравнимо меньше ресурсов сервера
* не перебарщивайте с использованием готовых фреймворков, да это соблазняет простотой и получением готового результата путем комбинации решений как в конструкторе, но начиная с какого то момента ограничения подхода и борьба с особенностями и даже багами превысят затраты на самостоятельную разработку решения. Знаменитый анекдот 'как программист заваривает чайник' отличная иллюстрация того что готовые решения увеличивают затраты ресурсов и по простому это не исправить.
Готовые репозитарии решений это конечно отлично но вы должны понимать что не вы их поддерживаете а значит становитесь заложником чужих решений и разработчиков, на которых вы не влияете. А уж когда у вас критичная и финансовая информация, чужие готовые решения становятся огромной дырой в безопасности.

готовые приложения аудио видео чатов смотреть talky.io а опенсорсное jitsi.org
вообще гугл выдает простые и отличные примеры webrtc audio chat example

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

Для меня такие сайты минус 5 из 10 к личному рейтингу, стараюсь избегать всеми способами.

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

Готовые реализации есть у популярного веб сервера ngnix (в гугл nginx reverse proxy - миллион примеров конфигурации, в вашем случае придется покумекать, как интегрировать в вашу систему аутентификации).

Нажимаешь в браузере F12, закладка networks, потребуется нажать на круг/reload чтобы запустить аналитику, оно перезагрузит сайт и покажет подробно какой элемент как долго и в каком порядке загружается с миллисекундной точностью

Гадать что именно тормозит бессмысленно.
30 секунд это выглядит как таймаут на доступ к какому то ресурсу, вот и определите что недоступно.

Много мелких запросов к серверу?

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

Второе - объединяйте запросы в один, так не совсем правильно но переделать ваш текущий код будет просто - можно подменить ваши запросы ajax на асинхронные к вашему методу, т.е. вместо $('selector').text($.get('data_url')) делайте вызов метода по завершению запроса что то типа

my_async_get('data_url',function(result){$(selector).text(result);})

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

Еще вариант - он исходит из вопроса, чем вам не нравится множество отдельных ajax? если только из-за проблем в производительности, то подумафйте о смене протокола веб сервера, на http3 или к примеру websocket, у них на повторный запрос к вебсерверу не тратится лишнее время.

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

каждой соцсети свою колонку в таблице users если не хотите выносить это в отдельную

Судя по всему вы очень узкий специалист,.. если вариант с нанять знающего не катит, копайте сами.
Настоятельно советую выкинуть на помойку ms access и больше не вспоминайте это, когда то эта среда была одним из лидеров, но сейчас безнадежно устарела. В принципе можно использовать само хранилище mdb по назначению, без UI, но сейчас есть более удобный и быстрый инструмент sqlite

Общепринятые практики, которые можно использовать в вашем случае:
* 'разделяйте и властвуйте'
Отделите хранение данных от интерфейса работы с ней, это решит много проблем, уменьшит возможное количество ошибок и облегчит поддержку системы, так как для нее вам не потребуется на столько узкий специалист.

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

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

* задайтесь вопросом что есть надежность и безопасность, эти понятия очень много в себя включают

Разделение на независимые блоки с общением через стандартизированное api позволит вам вести разработку компонент независимо, и в некоторых случаях даже не привязываясь к языку программирования, фреймворку или использовании версий и типов серверов.

На странице форма с поиском отправляет запрос (на выбор http rest get или post либо лучше используя websocket, почему - ниже) на сервер.

Сервер ищет на основе запроса клиента, смотрит, онлайн ли он (в случае с http rest это определяют таймаутами с последнего запроса, а вот с websocket все нативно и в реальном времени без проблем) и если да, шлет на все его подключения (пользователь может открыть несколько закладок в браузере или на разных компах) сообщение (с http rest геморно, клиент должен периодически делать запросы на сервер с вопросом - нет ли для меня сообщений, которые не сразу отвечают, если нет сообщений, и висят до таймаута или вообще бес конечно, выдавая по 1 байту в минуту, который просто пустышка, ради поддержания соединения).

Если пришло сообщение, клиент его выводит.
---

Для работы websocket на сервере нужна его поддержка, обычно отдельный бакэнд выступающй в виде websocket сервера и обрабатывающий запросы. Есть плагины к веб-серверам, конвертирующие это в привычный http rest стиль, но это изврат.

Когда то давно, когда websocket не был стандартом, самым простым способом слушать события с сервера был запрос на сервер и ответ в виде javascript с вызовом функции, которая собственно и есть событие (т.е. запрос на страницу подключался простым тегом < script >), сервер ничего не отправляет в канал запроса (или просто пробел по 1 в минуту чтобы по таймауту не закрылся) пока не появится необходимость. Правда клиент должен отслеживать ошибки что бы повторять запрос.

Звалось это long poolling

пол секунды грузится http под 15кб, а потом автоматом столько же еще полторы секунды стартовая страница

При использовании европейской прокси, скорость загрузки первой страницы почти 3 секунды, разбирайтесь что там за тормоза, это нереально много.

В общем случае никак (в вашей схеме организации), так как ушлый пользователь может проксировать запросы к вашему серверу лицензий с любого количества установок.

Вы можете попробовать обусицифировать процесс установки и деинсталляции, привязывая ее к каким-нибудь внутренним идентификаторам системы, параметрам реестра и прочее прочее (в этом случае у вас будет по 1 запросу на установку и удаление), но опять таки ушлый пользователь может это отреверсить. системные вызовы отследить и симулировать одинаковые окружения, вам же объясняя что повторные активации - это у него винда слетела, диск помер и прочая лапша на уши.

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