У меня есть идея сделать чат через сессии.
Первая часть.
Принцип работы такой по нажатию кнопки "Отправить" JavaScript отправляет запрос типа "send.php?id=vasya?message=Привет" к PHP страничке которая записывает в массив само сообщение логин и ID сообщения (порядковый номер) после чего этот массив мы кладем в сессию.
Вторая часть.
Обновление сообщений будет происходит так же JavaScript. Скрипт будет отправлять запрос к PHP странице вида "get.php?id=7" ID=7 это ID последнего сообщение на странице пользователя. На PHP странице будет читаться массив и на выходе будут сообщения с ID > 7 ,которые в свою очередь будут выводится собственно в сам чат.
В чем собственно предполагаемая фичя сего....
Не используется БД что в свою очередь должно положительно сказаться на быстродействии, так как сессии не что иное как файлы на сервере и запись, чтение происходит гораздо быстрее, по сравнению с тем же MySQL.
Кто что думает на эту тему.
Спустя 6 минут, 18 секунд (29.03.2012 - 15:22) johniek_comp написал(а):
zloymudvin
| Цитата |
| файлы на сервере и запись, чтение происходит гораздо быстрее, по сравнению с тем же MySQL. |
если у тебя (сомневаюсь) посещаемость >500 одновременно, то можешь попробовать, а потом все переписать на mysql вскоре
Спустя 5 минут, 19 секунд (29.03.2012 - 15:27) zloymudvin написал(а):
| Цитата (johniek_comp @ 29.03.2012 - 12:22) | ||
zloymudvin
если у тебя (сомневаюсь) посещаемость >500 одновременно, то можешь попробовать, а потом все переписать на mysql вскоре |
Тут фичя в том, что чат это всего лишь часть браузерной игры, которая сама по себе уже загружает сервер и MySQL. А посещаемость браузерки > 500 вполне реальна.
Спустя 17 минут, 10 секунд (29.03.2012 - 15:44) Invis1ble написал(а):
zloymudvin
И каким образом ты запишешь в сессию юзера А сообщение, написанное юзером Б ?
И каким образом ты запишешь в сессию юзера А сообщение, написанное юзером Б ?
Спустя 23 минуты, 12 секунд (29.03.2012 - 16:07) zloymudvin написал(а):
| Цитата (Invis1ble @ 29.03.2012 - 12:44) |
| zloymudvin И каким образом ты запишешь в сессию юзера А сообщение, написанное юзером Б ? |
мляяяя чет я сеня ацки туплю....
а идея казалась хорошей
можно использовать просто файлы, но не удобно массивы туда впихивать и выпихивать.
Спустя 1 минута, 9 секунд (29.03.2012 - 16:09) Invis1ble написал(а):
Не морочь себе голову, используй средства по назначению. Для этого есть СУБД.
Спустя 35 минут, 45 секунд (29.03.2012 - 16:44) zloymudvin написал(а):
| Цитата (Invis1ble @ 29.03.2012 - 13:09) |
| Не морочь себе голову, используй средства по назначению. Для этого есть СУБД. |
Да вот я не хотел СУБД пользоваться, так как много времени уходит на конект с базой, а скрипт обновления отрабатывает каждую секунду, если за секунду не успел то сообщение потерялось, надо делать пул сообщений а как его делать ума не приложу.
Спустя 1 час, 29 минут, 23 секунды (29.03.2012 - 18:14) I++ написал(а):
| Цитата |
| файлы на сервере и запись, чтение происходит гораздо быстрее, по сравнению с тем же MySQL. |
На самом деле он прав =)
Все зависит от грамотной структуры, и если размер файла не будет больше 300 кб, то будет работать быстрее мускула
Лучше всего не изобретать велосипеды, лучше используй sqlite для этих целей. При маленькой нагрузке с использованием одних SELECT да INSERT он быстрее мускула работает.
Насчет:
| Цитата |
| Не используется БД что в свою очередь должно положительно сказаться на быстродействии |
Думаю вебсокеты и отдельный демон на питоне, будет в 100500 раз эффективнее
Ну или PHP + libeventНо это не существенно, не думаю, что сообщения чата привысят 1 мегабайт данных в секунду.
Хотя, думаю из этого 1 мегабайта 60% будут мусорные пакеты с заголовками (если делать как ты сказал)
Если чатиться будут не более 1к юзеров, проблем особых не возникнет. Ну хостер только обидеться, из-за лишней нагрузки на процессор.
Спустя 13 часов, 51 минута (30.03.2012 - 08:05) zloymudvin написал(а):
| Цитата (I @ ++29.03.2012 - 15:14) | ||||
На самом деле он прав =) Все зависит от грамотной структуры, и если размер файла не будет больше 300 кб, то будет работать быстрее мускула Лучше всего не изобретать велосипеды, лучше используй sqlite для этих целей. При маленькой нагрузке с использованием одних SELECT да INSERT он быстрее мускула работает. Насчет:
Думаю вебсокеты и отдельный демон на питоне, будет в 100500 раз эффективнее Ну или PHP + libeventНо это не существенно, не думаю, что сообщения чата привысят 1 мегабайт данных в секунду. Хотя, думаю из этого 1 мегабайта 60% будут мусорные пакеты с заголовками (если делать как ты сказал) Если чатиться будут не более 1к юзеров, проблем особых не возникнет. Ну хостер только обидеться, из-за лишней нагрузки на процессор. |
Спасибо, буду юзать демонов)
А существенна ли разница (в плане быстродействия) на чем писать демона, на С там или PHP, питон ...
Спустя 8 часов, 8 минут, 33 секунды (30.03.2012 - 16:13) I++ написал(а):
Не спеши с выводами.
Демон демону рознь. Нужно понять насколько это актуально, масштабируется, требуется ли.
Демон чатика на PHP + libevent + websockets (В интернетах есть примеры), очень хорошо переносит нагрузки с меньшими затратами ресурсов. Потому что работает в обход веб-сервера апача. Но на разработку уйдет гораздо больше времени, нужно учесть возможные ддос-атаки и тому подобное.
А насчет разница С, PHP, питон. Скажем так, каждое решение хорошо, но все зависит от скорости разработки. (сколько потратится на это времени).
На С++ для игрового сервера например, я бы использовал каскад видеокарт с использованием thread-safety концепции и GPU вычислениями. Что повысило бы быстродействие вычислений раз в 1000.
На PHP такое не сделаешь, у PHP нет тредов. Так, что клиенты которые общались бы через демон написанный на PHP + libevent испытывали проблемы с сервер-сайд латентностью. На стороне сервера рано или поздно стек команд забился в такую очередь, что вызывало бы задержки.
Пример на сервер пришло одновременно 10000 запросов от клиентов, все запросы выстроены в очередь. Вычисление 1 запроса занимает 0.01 мс. Клиент пославший 10000 запрос, получит ответ лишь через 100 мс. Вот и задержка.
На С++ можно все запросы распределить по тредам, которые работают асинхронно, а при GPU вычислениях, это произойдет мгновенно, так как команды выполняются на множестве мелких процессорах. Плюс там есть функции выполнения вычислений с float значениями за 1 такт. И много других вкусных плюшек.
До сих пор не понимаю почему дедики для некоторых игрушек не используют подобный подход, поставил видюшку обычную печ 285 например и огого полет какой будет, и проц меньше жраться будет.
Демон демону рознь. Нужно понять насколько это актуально, масштабируется, требуется ли.
Демон чатика на PHP + libevent + websockets (В интернетах есть примеры), очень хорошо переносит нагрузки с меньшими затратами ресурсов. Потому что работает в обход веб-сервера апача. Но на разработку уйдет гораздо больше времени, нужно учесть возможные ддос-атаки и тому подобное.
А насчет разница С, PHP, питон. Скажем так, каждое решение хорошо, но все зависит от скорости разработки. (сколько потратится на это времени).
На С++ для игрового сервера например, я бы использовал каскад видеокарт с использованием thread-safety концепции и GPU вычислениями. Что повысило бы быстродействие вычислений раз в 1000.
На PHP такое не сделаешь, у PHP нет тредов. Так, что клиенты которые общались бы через демон написанный на PHP + libevent испытывали проблемы с сервер-сайд латентностью. На стороне сервера рано или поздно стек команд забился в такую очередь, что вызывало бы задержки.
Пример на сервер пришло одновременно 10000 запросов от клиентов, все запросы выстроены в очередь. Вычисление 1 запроса занимает 0.01 мс. Клиент пославший 10000 запрос, получит ответ лишь через 100 мс. Вот и задержка.
На С++ можно все запросы распределить по тредам, которые работают асинхронно, а при GPU вычислениях, это произойдет мгновенно, так как команды выполняются на множестве мелких процессорах. Плюс там есть функции выполнения вычислений с float значениями за 1 такт. И много других вкусных плюшек.
До сих пор не понимаю почему дедики для некоторых игрушек не используют подобный подход, поставил видюшку обычную печ 285 например и огого полет какой будет, и проц меньше жраться будет.
Спустя 1 день, 2 часа, 41 минута, 27 секунд (1.04.2012 - 18:55) zloymudvin написал(а):
| Цитата (I++ @ 30.03.2012 - 13:13) |
| Не спеши с выводами. Демон демону рознь. Нужно понять насколько это актуально, масштабируется, требуется ли. Демон чатика на PHP + libevent + websockets (В интернетах есть примеры), очень хорошо переносит нагрузки с меньшими затратами ресурсов. Потому что работает в обход веб-сервера апача. Но на разработку уйдет гораздо больше времени, нужно учесть возможные ддос-атаки и тому подобное. А насчет разница С, PHP, питон. Скажем так, каждое решение хорошо, но все зависит от скорости разработки. (сколько потратится на это времени). На С++ для игрового сервера например, я бы использовал каскад видеокарт с использованием thread-safety концепции и GPU вычислениями. Что повысило бы быстродействие вычислений раз в 1000. На PHP такое не сделаешь, у PHP нет тредов. Так, что клиенты которые общались бы через демон написанный на PHP + libevent испытывали проблемы с сервер-сайд латентностью. На стороне сервера рано или поздно стек команд забился в такую очередь, что вызывало бы задержки. Пример на сервер пришло одновременно 10000 запросов от клиентов, все запросы выстроены в очередь. Вычисление 1 запроса занимает 0.01 мс. Клиент пославший 10000 запрос, получит ответ лишь через 100 мс. Вот и задержка. На С++ можно все запросы распределить по тредам, которые работают асинхронно, а при GPU вычислениях, это произойдет мгновенно, так как команды выполняются на множестве мелких процессорах. Плюс там есть функции выполнения вычислений с float значениями за 1 такт. И много других вкусных плюшек. До сих пор не понимаю почему дедики для некоторых игрушек не используют подобный подход, поставил видюшку обычную печ 285 например и огого полет какой будет, и проц меньше жраться будет. |
Ого, ну я думаю параллельные вычисления с помощью GPU для чата это уже перебор. А вот нарыл такую тему с memcache на вид довольно просто и привлекательно, кто нить юзал?