LINUX.ORG.RU

[ЛПП]Может ли такое быть. Количество запросов к БД при создании странички.


0

0

Итак, есть сайт, который крутиться на CMS (MODx), обычный LAMP. Есть странички выполенных проектов, на каждой дюжина фоток и одна видюшка (ничего не поделаешь). Есть страничка всего раздела "проекты", там все проекты перечислены, для каждого ещё поставлены 4 уменьшенных картинки (первые четыре из проекта) и видюшка.

Фрилансер, который это делал, говорит что каждый проект это ~20 запросов к базе данных, когда проектов будет хотя бы штук 5 это ~100 запросов, сервер будет себя очень нехорошо чувствовать. А я не могу понять, с чего бы, если новые проекты добавляются раз в месяц, весь месяц страницы на сайте не меняются и должны бы выдаются посетителям из кэша.

Кто прав? Такие вещи кэшируются, или нет? Если нет, то почему? Ведь целый месяц на странице ничего не меняется, неужели при каждом обращении страница со списком проектов генерится заново?

★★★★★
Ответ на: комментарий от drull

Не отдам.

>ну отдавай странички через кеширующий прокси и будет тебе счастье.

Это всё крутится на хостинге, конкретно на Мастерхосте, так что поставить кэширующий прокси не вариант. Не удивлюсь если он там уже стоит.

Camel ★★★★★
() автор топика

Это надо не тут спрашивать. Но даже без телепатии можно предположить следующее:

1. 20 запросов на генерацию одной странички - отчаянная криворукость.

2. Дабы нивелировать эту криворукость, скорее всего используется какой-то механизм кэширования.

3. Я не телепат, угадать сложно.

Anoxemian ★★★★★
()
Ответ на: комментарий от Anoxemian

>20 запросов на генерацию одной странички - отчаянная криворукость.

Если простая страничка с текстом - то да. Там и 3-5 запросов хватит :)

Если наворочанная входная страница толстого портала - то и в 10 раз больше бывает при пустом кеше.

Но, естественно, всё это нужно кешировать. В идеале - вообще статикой.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

> Если наворочанная входная страница толстого портала - то и в 10 раз больше бывает при пустом кеше.

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

Anoxemian ★★★★★
()
Ответ на: комментарий от Anoxemian

>имхо, если такое возникло, то надо перерабатывать логику кардинально.

Ну, как её переработать, если на странице будет, скажем, штук 20 независимых модулей, работающих с 30-ю таблицами трёх баз данных? :)

Или ты предложишь отойти от модульности и MVC, слепив страшного Франкенштейна, где всё-всё-всё будет в одном месте делаться? Ты уже через месяц ничего с таким монстром сделать не сможешь, когда понадобится типовой модуль поменять сразу в 5-6 местах сайта...

Скажем, на http://www.aviaport.ru/ генерится запросов, как раз, штук по 170. Если хорошенько посидеть и повозиться, можно уменьшить до 100-120, наверное. Но нафига, если проще заюзать статический кеш? :)

KRoN73 ★★★★★
()
Ответ на: комментарий от Anoxemian

У нас на одном большом портале на Django было по 900 запросов на главной странице. Вот уж где жесть была… С memcached для объектов Django-моделей снизилось до 250 простых запросов. Сейчас серьезно думаем над статическим кэшем.

vden ★★
()
Ответ на: комментарий от KRoN73

В идеал недостижим.

Таки фрилансер криворукий, или жизнь такая? Напомню условия, новые проекты добавляются раз в месяц. Обязательно ли генерить страничку с перечислением проектов каждый раз заново?

Camel ★★★★★
() автор топика
Ответ на: В идеал недостижим. от Camel

>Напомню условия, новые проекты добавляются раз в месяц. Обязательно ли генерить страничку с перечислением проектов каждый раз заново?

Если там кроме ссылок на эти проекты ничего другого нет, никто не мешает сделать статику... Да хоть с ежедневной очисткой кеша :)

...

Ну и 20 запросов на 5 проектов = 100 запросов всего - это уже реально кривизна какая-то. Если там, берём худший случай, каждый проект - объект в базе, ссылающийся на 20 других объектов, то это будет 1 запрос на извлечение проектов и 20 запросов - на извлечение данных.

Если оно ещё хоть как-то иначе формализуется, то запросов будет меньше. Мне трудно представить вариант с более чем 4-6 запросами :)

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Посчитаем.

Попробую и я посчитать, поправьте где неправ.

Нужно вытащить название проекта, ссылку на страничку с его описанием, 4 ссылки на thumbnail'ы стандартного размера, ссылка на видюшку стандартного размера. Получается 7 запросов на проект. Но всё равно, что-то он про статику и/или кеширование недоговаривает.

Camel ★★★★★
() автор топика
Ответ на: Посчитаем. от Camel

>поправьте где неправ.

Я не знаю, какая у вас структура данных. Если каждый проект - отдельная запись в БД, то все его параметры вытягиваются одним запросом.

4 первьюшки на проект? Проходим по циклу по проектам, собираем id-шники картинок, дёргаем все их параметры - ещё один запрос.

Два запроса на весь вывод.

Ещё один запрос на запрос авторизационных данных пользователя, если у вам там форма с логином и паролем.

После выдачи ещё запрос на инкремент счётчика заходов на страницу, на запись в лог ещё один.

Итого, 4 запроса :) Хотя можно и двумя обойтись, если пользователь не логинится и логи не ведутся...

KRoN73 ★★★★★
()
Ответ на: комментарий от vden

> У нас на одном большом портале на Django было по 900 запросов на главной странице. Вот уж где жесть была…

Вот до чего людей ORMы доводят...

anonymous
()
Ответ на: комментарий от KRoN73

> Ну, как её переработать, если на странице будет, скажем, штук 20 независимых модулей, работающих с 30-ю таблицами трёх баз данных?

И эти люди ещё рассуждают а франкенштейнах...

> Скажем, на http://www.aviaport.ru/ генерится запросов, как раз, штук по 170.

Это такая быдлокодерская мода лепить страницы "всё-в-одном" с километровым вертикальным скроллом? Как насчёт эргономики, юзабилити? А ведь можно было сделать интерфейс по уму, глядишь и не пришлось бы генерить стопицот запросов.

anonymous
()
Ответ на: комментарий от anonymous

>Это такая быдлокодерская мода лепить страницы "всё-в-одном" с километровым вертикальным скроллом?

Быдлокодеры занимаются только быдлокодингом. А композицией главной страницы занимается руководитель проекта. С возможной консультацией специалистов по юзабилити и маркетологов. Это тебе на будущее, а то ляпнешь где-нить за пределами ЛОРа...

Это только в школе проектом один человек занимается. Сам себе проектировщик, сам себе дизайнер, сам себе верстальщик, сам себе программер и сам себе админ, редактор сайта, ньюсмейкер, фотограф, автор, пиарщик, секретарь и бухгалтер :)

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

>Сам себе проектировщик, сам себе дизайнер, сам себе верстальщик, сам себе программер и сам себе админ, редактор сайта, ньюсмейкер, фотограф, автор, пиарщик, секретарь и бухгалтер :)

сильно, надо еще что-нить добавить

z0D5e8n7x_2
()
Ответ на: комментарий от KRoN73

>Сам себе проектировщик, сам себе дизайнер, сам себе верстальщик, сам себе программер и сам себе админ, редактор сайта, ньюсмейкер, фотограф, автор, пиарщик, секретарь и бухгалтер :)

я аж прослезился... оказывается так просто описать в одном предложении всю мою жизнь(((

ЗЫ профессии не совпадают но суть та же)

dijik
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.