hell0w0rd
Продвинутый новичок
конфиги, ответы базы: меню, статические страницы - то что часто не меняется.
точнее не часто меняется)
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Время генерации страницы: что можно считать нормой?
- Автор темы stopkran
- Дата начала
точнее не часто меняется)
И что - сильно помогает? А как конкретно кэшируешь?
hell0w0rd
Продвинутый новичок
apc, хз на сколько сильно помогает. Явно быстрее чем парсинг конфига/запрос к базе и рекурсивная отрисовка меню, а ты не кешируешь?)
Holips
Новичок
Временя генерации страницы.... Золотого числа, "за рамки которого выходит не стоит" - назвать невозможно.
Для парсера XML, скрипта наложения водяного знака или распаковки архивов - это одно значение. Например, - желательно до 2-3 секунд.
Для скрипта вывода с парой селектов - в десяток, а то и сотню раз меньше. К примеру - до 0,05 сек
Большее внимание рекомендую уделять потреблению скриптом памяти, своевременному "демонтажу" ненужных объектов, ну и оптимизации SQL запросов. Если с сим всё в порядке - то и о времени генерации скрипта парится не придётся.
Оптимально, если обычная страница с выводом, например списка новостей не будет жрать не более 50 кило. В целом, рекомендую делать статичным всё, что ни лень.
Для парсера XML, скрипта наложения водяного знака или распаковки архивов - это одно значение. Например, - желательно до 2-3 секунд.
Для скрипта вывода с парой селектов - в десяток, а то и сотню раз меньше. К примеру - до 0,05 сек
Большее внимание рекомендую уделять потреблению скриптом памяти, своевременному "демонтажу" ненужных объектов, ну и оптимизации SQL запросов. Если с сим всё в порядке - то и о времени генерации скрипта парится не придётся.
Оптимально, если обычная страница с выводом, например списка новостей не будет жрать не более 50 кило. В целом, рекомендую делать статичным всё, что ни лень.
На этот вопрос уже ответили выше:
Это первое, и совершенно золотое правило.
Все остальные причины по отношению к нему - второстепенные.
AnrDaemon
Продвинутый новичок
Я могу ответить на этот вопрос.
Кеширование рендера одного дерева меню, которое для всех пользователей одинаковое в каждом конкретном состоянии, ускорило повторные открытия разделов каталога в 40 раз.
hell0w0rd
если ты точно знаешь, что как только сайт откроется на него побегут сотни тысяч народу - то да. надо делать оптимально. Если нет, то правильнее сделать простенько, но с возможностью быстро добавлять кеширование и другие оптимизации где надо(т.е. просто чтобы твой код был готов и не сопротивлялся в будущем такому).
если ты точно знаешь, что как только сайт откроется на него побегут сотни тысяч народу - то да. надо делать оптимально. Если нет, то правильнее сделать простенько, но с возможностью быстро добавлять кеширование и другие оптимизации где надо(т.е. просто чтобы твой код был готов и не сопротивлялся в будущем такому).
AnrDaemon
Продвинутый новичок
Не "нельзя", а "очень мало смысла". Если ты совершенно чётко представляешь себе, что происходит с твоим сайтом, какие, как сейчас модно выражопываться, "паттерны использования" твоего детища, ты можешь заранее применять какие-то методы для более оптимальной обработки конкретных мест проекта.
Но.
Практика показывает, что какие бы программист не имел идеи, пользователи будут использовать продукт строго наоборот, и ещё ругаться, что ничерта нормально не работает и приходиться по-всякому извращаться, чтобы добиться хоть каких-то результатов.
Да дело даже не в этом.
Истерически смешна рекомендация, которую дал этот очередной профессор, вычитав в каком-нибудь соседнем форуме, но никогда в глаза не видев кода - он там протаскивает доктринный кэш для кэширования файлов... в котором один из драйверов - кэширует в файлах.
На самом деле - это и есть основная проблема, а никакая не производительность: толпы обезьян, которые делают не то что нужно на самом деле, а то, что они прочитали у других обезьян. И побежали учить третьих.
Но если вот прямо так хочется сокровенного знания.
1. Совершенно идиотское представление о том, будто БД или файлы априори "медленные", и их надо обязательно кэшировать. И база, и файлы, на самом деле - фантастически быстрые хранилища. И если у тебя БД работает медленно, то в 99% случаев надо выпрямлять руки, а не бежать кэшировать задрав портки. И только в одном проценте случаев тебе действительно понадобится кэширование. Ты об этом будешь знать точно, и кэшировать будешь не от балды, просто потому что пацаны на перемене рассказали, что это круто, а строго тот участок, который в этом нуждается.
2. мало сделать кэш. Любой кэш надо инвалидировать. Об этом юные аптемезаторы все поголовно забывают. А инвалидация мало того что (вместе с кэшированием) - это лишний код и усложнение отладки - так там ещё и думать надо, чтобы сделать по-человечески. А с этим у пионэров совсем труба.
Поэтому-то и надо держаться подальше и от пионеров, и от их кэширования, а при возможности - лупить по пальцам молотком.
hell0w0rd
Продвинутый новичок
Фанат нет, я не хотел сказать что файлы/бд медленные. Даже наоборот. Но есть же вещи для которых инвалидация кеша временем - вполне нормально. Я не хочу на каждого юзера, пусть их даже не больше сотни в день собирать меню. Я лучше закеширую его на час и оно будет собираться раз в час. Если все компоненты тесно связанны, то есть я могу контроллировать свежесть данных - можно вообще кешировать на бессрочный период, но при обновлении - очищать.
Ну да, ну да. Ровно то, о чем я и говорю. Вместо того, чтобы срочно выпрямлять руки и исправлять говнокод, который собирает три пункта меню так, что эту операцию приходится кэшировать - будем всем рассказывать, какая хорошая штука это кэширование. Отличный подход. Это называется эффективный менеджмент. Ты не ту профессию выбрал, дружок. Тебе надо идти по стезе маркетинга. Там твои таланты раскроются на полную катушку. А здесь никто не оценит.
stopkran
Дилетант
Не понял. "50 кило" - это память? у меня уже при начальной загрузке PHP - 256. А в конце - 5000. И это именно обычная страница со списком товаров.
Все-таки, обезьяны не понимают, даже когда говоришь им открытым текстом, и онм даже с тобой соглашаются...
Почему база для тебя - пугало обло, стозевно и лайяй? Откуда такая фобия к выполнению простого запроса?
Что в этом плохого само по себе? База предназначена для того, чтобы обрабатывать запросы. абсолютно ничего страшного в обращении к базе нет.
Я точно так же могу спросить тебя - а зачем делать кэширование? Особенно если есть далеко не нулевая вероятность того что будучи ламером, делающим "кэширование" от балды, ты сделаешь медленнее, чем кэшируемая операция. Но суть не в этом. А просто в логике, которой ты руководствуешься. Одно не делаем, другое делаем. причем первого боимся (безосновательно), а второе делаем (без единого повода к тому).
А почему бы и не сделать?
Почему база для тебя - пугало обло, стозевно и лайяй? Откуда такая фобия к выполнению простого запроса?
Что в этом плохого само по себе? База предназначена для того, чтобы обрабатывать запросы. абсолютно ничего страшного в обращении к базе нет.
Я точно так же могу спросить тебя - а зачем делать кэширование? Особенно если есть далеко не нулевая вероятность того что будучи ламером, делающим "кэширование" от балды, ты сделаешь медленнее, чем кэшируемая операция. Но суть не в этом. А просто в логике, которой ты руководствуешься. Одно не делаем, другое делаем. причем первого боимся (безосновательно), а второе делаем (без единого повода к тому).
stopkran
Дилетант
Думаю, на сервере оптимизатор стоит - там коммерческий виртуальный хостинг, им ведь выгодно как можно больше аккаунтов на одну машину помещать.
А насчёт совета... Я немного с другой стороны на это смотрю. Вот тут Фанат недавно сказал, что если, например, 3 пункта меню генерируются 3 секунды, то это надо не кэшировать, а разбираться в проблеме по существу и править свой говнокод. То есть всё-таки оптимизировать. Вот мне и кажется, что я где-то наговнокодил, просто есть смутное ощущение. И я хочу это место оптимизировать. Не дожидаясь, пока лавина ГК нарастёт, и это станет заметно пользователям.
Говоря другими словами, я считаю "правильную" скорость генерации чем-то вроде показателя здоровья сайта. Насчёт "правильности" у меня есть только внутреннее ощущение. И я пытаюсь его хоть немного объективировать, выслушав мнения опытных разработчиков. Хотя бы просто на уровне того же ощущения, как у Фаната - "0.1 с - это уже много, надо начинать беспокоитсья". Или вот Holips ещё написал, что для него комфортная цифра - 0.05 (речь о простых страницах).
Несколько человек выскажут мнения, и это уже будет не совсем мнение, а статистика
.