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

Question

В чате 1 на 1. Два решения:

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

2) Я сохраняю каждое сообщение в одном html-файле и каждую секунду через jQuery этот файл отображается снова и снова.

Что лучше? Или есть третий вариант? И вообще, что лучше, mysql или файл для такого рода проекта?

Большое спасибо.

P.S. Самый важный вопрос: что эффективнее и каким образом будет потреблять меньше ресурсов!

Редактировать: И действительно ли в наши дни очень плохо для многих чатов (скажем, 2500 чатов, что означает 5000 пользователей) использовать длинный опрос и проверять, когда файл редактируется каждую секунду с помощью javascript? Я использую очень похожие методы, такие как этот чат: http://css -tricks.com / jquery-php-chat / Это убьет мой хостинг?

Answer 1

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

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

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

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

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

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

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

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

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

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

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

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

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

Посмотрите на это изображение:

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

Edit:

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

Edit2:

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

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

Answer 4

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

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

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

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

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

2. Открытие и закрытие соединения БД, но с тем же запросом: ~ 1800

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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

Answer 8

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

Answer 9

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

$ 0,02

Answer 10

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

1. Домашняя страница MongoDB
2. Некоторые тесты
3. домашняя страница расширения MongoDB на php.net