Не бейте если написал не в ту ветку. заказал чат у знакомого программиста, ставка была на скорость, безопасность и функционал из т.з. Чат должен держать не напрягаясь 500 человек онлайна(на практике обычно 100 загружает сам чат). Программист опытный. Решено было использовать файлы, а не базу данных в чем я доверился программисту, однако когда выяснились детали функционала, стало понятно что используя файл такое не замутить. Не знаю почему, но видимо в силу возраста он не застал чаты из начала 2000-ых осознанно. При использовании файла, загружается весь файл целиком, соответственно его нужно чистить постоянно, иначе пользователь зашедший в 4 дня, будет видеть все сообщения с 9 утра. к примеру. ясное дело что можно написать мудренный алгоритм и сделать работу с файлом по сути такой же как работу с б.д., но это не имеет смысла, т.к. есть б.д. зачем придумывать колесо. собственно вопрос, насколько сильно будет нагружаться сервер, с использованием чата на php+mysql учитывая такой онлайн? Соккеты и другие базы данных не доступны. Я прекрасно понимаю что можно на ржавом корыте держать и больший онлайн в зависимости от того насколько мощный сервер. Но и тут есть рациональность. 8 ядер 8 гигов оперативы для того чтобы держать онлайн в 100 человек не конструктивно. Задам более конкретно. Каков запас у сервера с 8 ядрами, 8 гигами оперативы, ссд при чате на php+mysql + другие скрипты. От себя скажу что, я лично убедился на практике что лаги начинаются не из-за количества запросов, а из-за количества строк в таблице. Т.е. в таблице 500к строк и алгоритм скрипта написан через одно место, от чего он начинает перебирать всю таблицу - тогда лагает. цифры взяты с воздуха, для примера.
Не надо загружать или чистить файл. Его можно читать построчно. Открывать чатлог на чтение, ставить указатель в конец и читать сколько хочешь строк вверх. А новые сообщния тупо дописывать в конец.
да, но разве это не имитация работы базы данных? таким образом нивелируется весь выигрыш в скорости обработки. и собственно что скажете по поводу: Разве чат на mysql это плохо? Алгоритм ведь не делает выборку по всей таблице, есть индексация.
MySQL это хорошо, но если речь идет об экономии ресурсов, то просто чат на одном файле будет быстрее. Главное не считывать файл целиком для разбора внутри пхп.
Разумной экономии, 500 человек никто не станет держать на хостинге за 5 долларов. Но и 100 человек не должны сжирать кучу ресурсов. Скажем так ездить на офисную работу в пробках на Камазе глупо.
ну..... как то странно и нельзя сокеты и другие БД использовать? ..... не VPS что-ли? Имхо - файл это зло..... ориентировочно при нагрузке постоянной в 100 чел - начнет сыпаться сам файл из-за механизма блокировок и прочего... проверенно -не всегда - но будет периодически обнулять например А вообще нужно смотреть всю архитектуру чата... как у вас например происходит "он лайн" обновление разговоров в чате.... - не f5 же жмут пользователи.... - по таймеру через ajax? вот вам и нагрузка...... насколько часто итд итп Я бы использовал VPS - вебсокеты + MySQL (хотя возможно и что-то типа хранилища Redis) но файлы бы точно не использовал
и еще говоришь из за колво записей в бд лаги. Так тяни не все записи а только последние 100 последних а потом если нужно подгружай еще сто и так делее. У меня из за этого были тоже такие траблы решил вот так вот.
А про memory cache с отложенной синхронизацией в бд опытный программист слыхом не слыхивал, видимо.. Ох уж эти опытные программисты, не бывшие в начале 2000 в сознательном возрасте. Бинго. Распухание очередей, рейскондишн, рассинхронизация, это вот букет дурнопахнущий, который гарантирован по мере роста.
мда. вы правы. для меня сейчас уже очевидно что использование файла бред. причем не из-за того что мне тут написали. как только я понял алгоритм работы скрипта, который он написал. почему человек с многолетним опытом и приглашенный в другую страну на работу, начал писать по заведомо ложному пути я понимаю. программирование настолько фрагментировано сейчас, что язык не повернется назвать 90 процентов людей "знающих синтаксис" программистами. Все потому-что 90 процентов работы шаблонная. В вебе. Тоже самое и в остальных отраслях. Java программист, а что он делал? 5 лет писал на андроид софт для заказа пиццы или такси. Для меня как для заказчика, такие знания Java равноценны нулю,тем более что сейчас все намного проще. Да, такой кодер будет хорошо зарабатывать, будет востребованным, но он не знает Java полноценно. Придется писать самому. Ждите кучу "тупых" вопросов на форуме в разделе для новичков))
Вопросы, цель которых - что-то понять, или чему-то научиться, априори тупыми не являются. Добро пожаловать на форум
Нашел на одном из форумов, что чат на PHP это большой большой костыль - любой хостер быстро вас выгонит с таким чатом. В то же время тем "чат на PHP" очень много. Из этого главный вопрос - где проверенные рекомендации сервер/бд/структура бд/сочетание языков реализации чатов? Если есть, напишите. Сейчас делаю чат на mysql/php/jQuery/Ajax и решаю задачу оптимизации производительности. Реализация такова: Каждый раз когда пользователь отправляет сообщение, отправляется ajax запрос и в бд добавляется новая строка с сообщением. Каждые 3 секунды происходит ajax запрос к бд на получение всех сообщений которые > last_msg_id(id последнего сообщения загруженного при предыдущем запросе). Все хорошо работает, но изучив форумы, меня беспокоит вероятность того что чат упадет при нагрузке от 50 пользователей одновременно(зависит от мощности железа), но не суть. Факт в том что на сервер к одной и той же таблице каждые 3 секунды происходит 50/100/200 запросов или более, что в итоге может завалить сервак. Из этого приходит здравая мысль что эту нагрузку нужно распределять. Например можно, при записи новых сообщений, записывать их в 3 копии таблицы, которые будут находиться на разных серваках, а интервальные 3х секундные запросы распределяться на эти три таблицы. В такой схеме главное прогнозировать нагрузки и увеличивать количество копий. В таком случае если одновременно сообщение напишут 100 человек, каждый из них будет подключен к трем базам, получается 300 запросов(по 100 на каждый сервак) + 100 от интервального запроса от одного запроса по 33 запроса на каждую базу. Итого на каждую базу 133 запроса в момент времени против 400, если все происходит с одной базой. Экономия на лицо. На сколько верно я рассуждаю? Вторая мысль такая. Запись в базу по старой схеме, но только в одну-корневую. На одной из страниц повесить аналогичный интервальный запрос кроном каждую секунду который будет выводить новые сообщения в какое либо хранилище(либо копии хранилищ), к которым уже и обращаются пользователи. Например интервальный запрос будет перезаписывать последние 50 сообщений из базы в файл на хостинге(файлы на хостингах). А браузер каждого пользователя уже будет получать обновленные 50 срок из файла(файлов). Таким образом нагрузка уже не идет на базу данных, здесь конечно лучше протестировать какой вариант менее ресурсоемкий запросы к базе или чтение файла. Что думаете?
Вам нужен не аякс, вам нужны вебсокеты. Почитайте, думаю, понравится. --- Добавлено --- С вебсокетами вы на одной машине без танцев с бубном и хитровыбоенных архитектур сможете держать сотни одновременно общающихся друг с другом людей, причем в реальном времени, без 3-секундных таймаутов.