Живой чат с PHP и jQuery. Где хранить информацию? Mysql или файл?

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

Когда дело доходит до хранения данных, количество данных, скорость доступа к ним и несколько других факторов определяют наилучшую платформу хранения.

Некоторые люди предложили использовать memcached. Теперь, хотя это правильный ответ (вы можете его использовать), я не думаю, что это хорошая идея, основанная исключительно на том, что memcached хранит данные в памяти вашего сервера.

Ваша память не предназначена для хранения данных, она предназначена для использования в реальных приложениях, операционной системе, совместно используемых библиотеках и т. Д.

Хранение данных в памяти может вызвать множество проблем с другими выполняемыми в настоящее время приложениями. Если вы храните слишком много данных в своей ОЗУ, ваши приложения не смогут выполнить назначенные им операции.

Хотя это быстрее, чем дисковая платформа хранения данных, такая как MySQL, она не такая надежная.

Я бы лично использовал MySQL в качестве сервера хранения данных на сервере. Это уменьшит количество проблем, с которыми вы столкнулись, а также сделает данные очень управляемыми.

Чтобы ускорить ответы на ваши клиенты, я бы посмотрел на запущенный узел на вашем сервере.

Это связано с тем, что он управляется событиями и не блокируется.

Что это значит?

Ну, когда клиент A запрашивает некоторые данные, хранящиеся на жестком диске, традиционно PHP может сказать C ++, принесите мне этот кусок данных, хранящихся в этом секторе жесткого диска. C ++ сказал бы «нормально, что не проблема», и, хотя он собирается получить информацию, PHP будет сидеть и ждать, пока данные будут считаны и возвращены до того, как они продолжат ее работу, и тем самым заблокировать всех остальных клиентов.

С узлом он немного отличается. Узел скажет ядру: «Принеси мне этот кусок информации, а когда сделаешь, позвони мне», а затем он продолжает принимать запросы от других клиентов, которым может не потребоваться доступ к диску.

Так внезапно, потому что мы назначили обратный вызов ядру, нам не нужно ждать :), счастливые дни.

Взгляните на это изображение:

Это действительно может быть ответом на ваш поиск, пожалуйста, см. Ниже для более подробной и подробной информации о том, как узел может быть правильным выбором для вас:

• http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/

Четвертый вариант, возможно, не тот, который вам нужен, если у вас уже есть PHP-код, который вы хотите использовать, но, возможно, наиболее эффективным является использование сервера на основе Javascript вместо php.

Node.js легко может быть чат-сервером и может хранить все последние сообщения как переменную Javascript.

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

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

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

Если посетители будут общаться друг с другом, и вы ожидаете большого количества сеансов – 10-50, вы все равно сможете использовать базу данных PHP +. Просто убедитесь, что вы не делаете избыточные запросы, и ваши запросы кэшируются правильно. Чтобы уменьшить нагрузку, вы также можете запретить запуск скрипта чата на веб-сервере:

SetEnvIf Request_URI "^/chat.php$" dontlog CustomLog /var/log/apache2/access.log combined env=!dontlog 

Редактировать:

вы можете иметь схему задержки. Например, если вы запрашиваете 2 раза с задержкой 1 секунду, и у вас нет данных, вы можете увеличить задержку до 2 секунд. если вы достигли 10 запросов без ответа – увеличьте задержку до 5 секунд. Через 10 минут вы можете приостановить разговор, требуя от пользователей нажать кнопку, чтобы возобновить чат. Это, в сочетании с советами выше, обеспечит достаточно низкую нагрузку, чтобы иметь много параллельных чатов

Edit2:

Я предлагаю вам найти флеш-версию или Java-решение и купить его. С 5000-10000 пользователей вы должны быть гением, чтобы заставить его работать на VPS, особенно если RAM не так много. Не то чтобы это невозможно, но вы можете арендовать более дешевый VPS, а остальная часть денег купите некоторое решение в java или flash (не знаю, поддерживает ли флеш двухстороннее соединение, я не эксперт по Flash).

Обратите внимание на количество пользователей: если у вас 10 000 пользователей, я предполагаю, что у вас будет не более 100 чатов одновременно. Иди и посмотри сайты знакомств – у них не более 10% пользователей онлайн, и, возможно, большинство из них делают что-то еще и не болтают

Третий вариант. используйте MEMCACHE . бесконечно более быстрое чтение / запись. идеально подходит для вашего приложения.

Храните сообщения чата в базе данных, но используйте Memcached как слой кэширования для чтения базы данных. Таким образом, самые популярные чтения (например, последние 20 сообщений в чат-комнате) всегда будут подаваться прямо из памяти.

Это дает вам преимущество в скорости для наиболее частых операций и постоянного хранения для всех сообщений.

Просто чтобы добавить другой вариант … плоские файлы могли бы обеспечить менее ресурсоемкую альтернативу.

Каждому чату присваивается уникальный идентификатор и плоский файл, хранящийся для него. Каждый чат добавляет строку в этот файл. Затем каждый клиентский компьютер использует jquery для проверки ТОЛЬКО измененной даты файла, чтобы узнать, обновлен ли чат.

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

Я был заинтригован, поэтому сделал несколько тестов, и вот результаты:

1. При существующем соединении db количество «SELECT field FROM table LIMIT 0,1», которое может быть запущено за 1 секунду: ~ 4000

2. Открытие и закрытие соединения db, но выполнение одного и того же запроса: ~ 1,800

3. Проверка измененной даты в разных файлах: ~ 225 000

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

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

Вы должны попробовать XMPP в сочетании с BOSH . К счастью, большая часть тяжелой работы уже сделана для вас. Вы можете быстро реализовать простое jQuery (или другое js framework) решение. Прочтите этот учебник, это поможет вам многое – не только решить вашу конкретную проблему, но и дать вам более широкий взгляд на то, как внедрять технологии push поверх хорошего ole 'http.

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

PS: – Flash также создает отличную платформу для чат-серверов, и вы тоже можете посмотреть на нее.

Если вы определяете разговор как только два человека, то запрос каждую секунду будет выглядеть как один запрос на чтение в секунду для каждого пользователя и один запрос на запись каждый раз, когда кто-то что-то пишет (скажем каждые 10 секунд). Таким образом, каждые 10 секунд у вас будет около 2,2 запросов в секунду для каждой беседы.

Для 50 разговоров это 100 пользователей и 220 запросов в секунду. Это очень большая нагрузка на сервер для такого небольшого количества разговоров. Написание разговора для JSON или XML, вероятно, обеспечит более масштабируемое решение.

В этой статье обсуждается архитектура Meebo – длинный опрос, комета.

Как запоздало, подумали ли вы о том, чтобы установить IM-сервер, например Jabber, а не начинать с нуля?

вы всегда можете найти подходящий инструмент для работы … совместимый с XMPP бит программного обеспечения. так же плохо, как и документация, ejabber – это все в порядке. потому что он строго соответствует стандарту XMPP: http://code.google.com/p/ijab/ вы можете использовать любой клиент XMPP. Вы можете сохранить все это в СУБД, если хотите, и предоставить аналогичные функции, предлагаемые в разговорах gmail / google.

$ 0,02

Очень быстрой альтернативой может быть база данных NoSQL, такая как MongoDB:

1. Главная страница MongoDB
2. Некоторые контрольные показатели
3. Страница расширения MongoDB на php.net

Я не использую его, но вы, возможно, можете попробовать Photon , очень высокоскоростную платформу, основанную на Mongrel. В блоге автора (на французском) у вас есть пример, 30 строк кода для чат-сервера реального времени с демонстрацией видео.

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