это наверное совсем глупый вопрос, но всё же:
например имеется страница, 10 000 уникальных посещений в день, база данных ~50 000 строк, какой вариант лучше-
1)mysql выборка пользователю только один раз, далее все данные задаются в куки, после чего при следующих перезагрузках страницы идёт проверка на существование куки и вытаскиваются данные из неё(либо если нет, то также коннект к бд, выборка, передача данных в куки и так далее)
2)при каждой перезагрузке страницы всегда mysql выборка
как бы по логике кажется очевидным первый вариант, чтобы в лишний раз не нагружать выборкой из 50к строк, но почему спрашиваю- потому что когда-то кто-то сказал что "так перескакивать из mysql в куки - плохо", может я неправильно понял человека, может он меня, но всё же. (+ сомневаюсь, ведь куками тоже пхп занимается, также нагрузка, но с другой стороны минимальная же, это ведь не 50к строк)
пожалуйста покончите с моими сомнениями раз и навсегда
Когда ваши цифры будут в 1000 раз больше и не будет денег на нормальный сервер, тогда ваша вопрос станет актуальным. При таких цифрах кеш не будет освобождать ресурсы сервера, они и так должны быть свободны, соответственно смысла в кеше нет.
Если при таких цифрах у вас всё тормозит вам нужно, что то из: сменить архитектуру БД или разобраться как работать с БД или нанять админа.
спрошу у вас также:
>больше всего меня волнует как будет справляться бд с ежесекундными коннектами к ней
и кажется это будет плохо и лучше тогда хранить эти данные не в бд (получать из бд, сохранять в куках)
Время отработки одного скрипта в диапазоне от сотых до десятых долей секунды, например эта страница на тосторе полностью отрабатывает за 0.15 секунды. Нет смысла рассматривать временные промежутки больше чем время отработки одного запроса.
Более того, эти 0.15 секунд имеет смысл рассматривать только в ключе сколько за этот промежуток времени сервер успевает обработать запросов. При ваших цифрах среднее количество запросов в этот промежуток времени около нуля.
Приложения с плохенькой архитектурой держат поток десятки/сотни параллельных запросов к серверу, с хорошей сотни-тысячи, с отличной тысячи и десятки тысяч. Куши нужны для экономии процессора или памяти или чтений с диску, и нужны они при переходе от хорошей архитектуры к отличной, если делать их раньше то это будет костыль, что бы прикрыть какие то проблемы.
Walt Disney: хорошо,
>Более того, эти 0.15 секунд имеет смысл рассматривать только в ключе сколько за этот промежуток времени сервер успевает обработать запросов.
запросы к серверу происходят при каждой перезагрузке страницы
как вытаскивать информацию- из кук или из бд во время такого запроса получается почти не принципиально(за то же количество времени сервер сможет обрабатывать приблизительно то же количество запросов как из кук, так и из бд), ведь так?
Walt Disney: ну то есть что и с постоянной выборкой из бд я буду держать скажем поток десятки/сотни параллельных запросов к серверу, что и с куками будут все те же десятки/сотни
а к кэшу соответственно я переходить не стану пока не появится в этом необходимость
somethinginterest: у кук нет ничего общего с БД кроме того, что в итоге это некоторые данные в переменной. В них в принципе не могут лежать одинаковы данные, хотя бы потому что куки это пользовательский ввод и их содержимое надо валидировать при каждом запросе, зачастую опять же через БД. Ну и в целом куки ограниченны по размеру.
В куку часто лежит только ID сессии, и для вашей исходной задачи нужно использовать сессии, сессии могут храниться на диске или в той же базе или в другой.
Если делать стес-тест, простой select vs cookies, то база может выиграть по загрузке канала, из за меньшего размера заголовка в HTTP заголовке. А так оба варианта будут быстрые операции только в памяти, с разницей на уровне погрешности. Но всё же их сравнивать не нужно.
somethinginterest: Всё правильно, лепить везде кеш на уровне приложения это прямой путь к тому, что бы никогда не понять, как писать оптимальный код. Для начала вам лучше разобраться как работает кеш в mysql (а он там есть и работает из коробки всегда) и как он сбрасывается, пользы для будет намного больше.
Walt Disney: спасибо за ваши ответы, мой последний конкретный вопрос:
имея код, при котором пользователи при каждой перезагрузке страницы коннектятся к бд и производят выборку(простых данных из~50k строк), имя десятки параллельных соединений, мне не стоит беспокоиться о нагруженности сервера? (с учётом того, что по всем остальным факторам всё в порядке, то есть меня интересует именно по поводу огромного количества коннектов к бд)
somethinginterest: нет, не стоит. Это очень очень мелкое количество данных которые влезают полностью в память (занимая несколько мегабайт) запросы по ним тормозить не будут, соответственно все эти десятки будут открываться и закрываться вы этого даже не заметите.
Ни тот, ни другой вариант.
Юзайте кеш, сохраните результат выборку в файле или где-нибудь в memcache / redis и второй раз уже берите оттуда, это даст преимущество.
если уж данные слишком простые, то сохраните в сессиях(в куках они нахрен не нужны).
Так или иначе - старайтесь не дергать базу лишний раз.
p.s. храните настолько долго, насколько это возможно(или наоборот, при большом количестве посетителей кеш в 1 минуту даст огромное преимущество)
данные слишком простые, но действительно не хочу дёргать бд в лишний раз
сессии и куки по сути одно и то же ведь, прочитал это:
"Принципиальная разница между cookie и сессиями состоит в том, что cookie полностью хранятся в браузере пользователя (то есть на компьютере клиента), а при сессиях в cookie хранится только идентификатор сессии, а вся информация лежит на сервере в специальном уникальном файле."
как я понимаю частые подключения к бд это самое плохое, допустим по 1 в секунду
с той же периодичностью брать из кук (данных на стороне клиента) кажется гораздо лучше
просто не совсем представляю насколько ресурсозатратны такие подключения к бд
сессии хранят данные на моём сервере, значит наверное по идее это более ресурсозатратно в сравнении с куками, но опять же, данные действительно довольно простые и разницы принципиальной наверное нет
а принцип кеширования мне представляется таким же как и сессий, но данные хранятся в оперативной памяти
на самом деле больше всего меня волнует как будет справляться бд с ежесекундными коннектами к ней
и кажется это будет плохо
тогда если я всё правильно понял, то мой выбор за куками
50к строк - это очень мало для БД. Выбрка, особенно с индексами будет происходить многовенно.
Волноваться о производителности стоит начать когда таблицы начнут переваливать за миллионы.
а то что касается частых коннектов к бд,
то есть если к примеру каждую секунду будет происходить подключение и выборка из моей бд
насколько это вообще адекватно?
просто мне кажется что если я могу, то лучше тогда хранить эти данные не в бд (получать из бд, сохранять в куках)
>больше всего меня волнует как будет справляться бд с ежесекундными коннектами к ней
и кажется это будет плохо
Средний
