- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Создам очередной повод для холивара.
В различных инструкциях пишут, что сессии в базе данных позволяют быстрее отдавать страницу, чем сессии в файлах. Конкретно сейчас ставлю форум SMF, там есть такая опция при установке.
Оставим в стороне преимущества сессий БД для работы кластера серверов (общие сессии для всех) и прочие довольно заумные фишки для очень крупных проектов.
Вот, допустим, сессия в файле. Читается файл с диска, затрата времени на поиск файла в таблице файловой системы и на само чтение файла.
Сессия в БД: идет подключение к серверу БД, запрос, его парсинг, чтение из таблицы БД (фактически файла, т.е. опять же поиск в файловой системе и чтение файла, только уже не конкретного, а проход от начала до нужного смещения, т.к. таблица крупная).
БД может работать быстрее файла только если эта запись (сессия) закеширована в памяти.
А сейчас большинство VPS идут с SSD дисками, т.е. скорость чтения с них будет порядка скорости чтения из памяти.
Вопрос: так все таки зачем нагружать базу данных (теоретически и так нагруженную) еще и сессиями?
Почему сразу MySQL, почему не key-value database, memcached в конце-концов?
Если у вас свой VPS, то храните сессии в файлах, НО на виртуальном диске в памяти.
А вообще никогда не понимал хранения сессий в БД. Или на крайний случай в БД, то таблица должна иметь формат MEMORY
Мы Вам один страшный секрет скажем.
MySQL хранит данные в файлах.
Поэтому вопрос "сессии в файлах vs mysql" отдает чем-то странным:)
---------- Добавлено 16.08.2015 в 16:55 ----------
А вообще никогда не понимал хранения сессий в БД.
memcached самая тема для этого.
Мы Вам один страшный секрет скажем.
MySQL хранит данные в файлах.
Поэтому вопрос "сессии в файлах vs mysql" отдает чем-то странным
Продолжу демагогию: в мире Unix-подобных ОСей всё есть файл или сокет. И слово "файл" было использовано в качестве примера не в данном определении, что понятно и ребёнку, а в качестве примера простейшей реализации хранения без дополнительных абстракций и оптимизаций для доступа к данным. С тем же успехом можно было залетать в любой тред и начать иметь мозги собеседнику фразами "а ты чо, низнал, шо директория - тожэ файл?"
"а ты чо, низнал, шо директория - тожэ файл?"
Следовательно все читается из файлов. Файлы как файлы тоже кешируются. Имеется даже функция очистки файлового кеша. Я про php.
Кроме того, несуразно соединять с бд такие простые фичи как например капча на сессии. В сущности сессии и хранят данных таких простых фич.
Продолжу демагогию: в мире Unix-подобных ОСей всё есть файл или сокет. И слово "файл" было использовано в качестве примера не в данном определении, что понятно и ребёнку, а в качестве примера простейшей реализации хранения без дополнительных абстракций и оптимизаций для доступа к данным. С тем же успехом можно было залетать в любой тред и начать иметь мозги собеседнику фразами "а ты чо, низнал, шо директория - тожэ файл?"
Больше половины людей задающихся таким вопросом на самом деле не понимают, что mysql хранит данные на диске в файлах. Когда это понимание приходит - как правило вопрос "мускул или файлы" отпадает сам по себе.
Упускать в ответе этот важный момент или еще хуже - считать этот момент демагогией - ошибочно.
Больше половины людей задающихся таким вопросом на самом деле не понимают, что mysql хранит данные на диске в файлах. Когда это понимание приходит - как правило вопрос "мускул или файлы" отпадает сам по себе.
Упускать в ответе этот важный момент или еще хуже - считать этот момент демагогией - ошибочно.
Однако мускул предоставляет из коробки оптимизацию выборки, а также доступ к оперативе как в случае индексов, так и в случае варианта полного хранения записей сессий в оперативе с возможностью кеширования результата. И именно это подразумевалось изначально для дискуссии.
Однако мускул предоставляет из коробки оптимизацию выборки, а также доступ к оперативе как в случае индексов, так и в случае варианта полного хранения записей сессий в оперативе с возможностью кеширования результата.
Это какая-то унылая попытка холивара. ФС тоже хранится в оперативке, а b-tree не особо отличается от структуры ext.
И именно это подразумевалось изначально для дискуссии.
А, подразумевалось. Мы отвечали по тому, что написано. Но раз Вы решили придраться основываясь на том, что "подразумевалось", то ок.
Собственно я это и писал в 1-м посте. Просто слишком уж много мануалов, рекомендующих MySQL.
Чего не знал того не знал. И сколько ее хранится в ОЗУ? А если файлов-сессий столько что mc через putty прорисовывает директорию несколько минут? (была реальная ситуация)? Думаю в кеше будут только последние файлы, причем в кеше жесткого диска.
Из всего выше сказанного я понял что наиболее удачный вариант при работе 1го сервера - файлы, желательно на ram-диске.
Для кластера из нескольких серверов, которые должны пользоваться общими сессиями, это MySQL таблица типа MEMORY.