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

Есть 1 на 1 чат. Два решения:

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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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

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

Edit:

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

Edit2:

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

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

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

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

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

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

  • Открытие и закрытие соединения db, но выполнение одного и того же запроса: ~ 1800

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

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

Ответ 7

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

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

Ответ 8

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

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

Ответ 9

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

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

В этой статье обсуждается архитектура Meebo - long-poll, comet.

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

Ответ 11

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

$0.02