PHP MySQLi Singleton для Ajax-запросов заканчивается многими процессами

Я бы порекомендовал вам опубликовать код вашего одноэлементного и ajax-сервера. Трудно сделать заявление о том, что ваш синглтон или серверная часть ajax виноваты, если мы не можем на это посмотреть.

Я бы, вероятно, рассматривал количество подключений как более вероятную причину. Если это не локальное приложение, нередко фактические запросы занимают более 0,5 с. Таким образом, один запрос может не быть выполнен до того, как вы вызовете другой. Это может со временем создать очередь, которую серверная часть SQLi не сможет обработать достаточно быстро, и количество процессов начнет расти, поскольку новые запросы добавляются в очередь каждые 0,5 с для каждого подключенного клиента.

Как выглядит серверная часть ajax? Он сразу запускает запрос? Запускает ли он другой экземпляр php? На сколько одновременных подключений настроены веб-сервер и база данных? Все эти вещи во многом определяют поведение вашего приложения. Также, как указано. Обратите внимание, что даже если вы используете синглтон, он НЕ продолжает выполняться после выполнения вашего ajax-вызова. Каждый раз, когда вы делаете вызов, ваше php-приложение запускается с нуля, и ваш синглтон снова создается с нуля.

Вы можете настроить приложение (написанное на PHP или другом), которое будет работать все время и использовать основной цикл. Затем вы можете либо заставить это слушать определенный сокет, либо другими способами передать данные вашего внутреннего интерфейса ajax в это приложение. Затем работающее приложение могло бы обрабатывать серверную часть базы данных и возвращать данные серверной части ajax, которая возвращала бы ответ. Таким образом, обработчик базы данных не будет постоянно воссоздавать ваш синглтон. Но вы, скорее всего, все равно столкнетесь с проблемами очереди, если есть много клиентов, делающих запросы, требующие поиска в базе данных каждые 0,5 с.

Удачи!

Это не имеет ничего общего с вашим синглтоном, так как вы отправляете запрос на сервер каждые 0,5 секунды, страницы, делающие запросы, доступны для пользовательской базы, тогда вам также нужно умножить это на количество пользователей, у которых есть страницы ) открытые, которые делают запросы. ЕСЛИ вам действительно нужно вытащить сервер с такой скоростью, возможно, вы захотите изучить некоторые другие технологии, такие как Комета.

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

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

Лучшим подходом является то, что называется длинным опросом. Это процесс, при котором клиентский браузер отправляет запрос, но не ожидает немедленного ответа. Вместо этого сервер зависает на этом запросе до тех пор, пока ему не нужно что-то отправить обратно клиенту. Это намного эффективнее, и именно его использует проект APE (Ajax Push Engine — http://www.ape-project.org/).

Посмотрите, что они делают. Готов поспорить, что это будет правильно для того, чего вы пытаетесь достичь. И это уменьшит потребление ресурсов.

Я не уверен, что правильно понял...

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

Вы можете взглянуть на постоянные соединения, хотя я предпочитаю их не использовать; и я не уверен, что они вообще доступны в MySQLi.