делать сайт на цмс или без?

Умоляю, вы же не хотите продолжить недавнюю тему правильного деплоя? При мне нельзя произносить слово блокнот и ФТП и ФМ )))))

Прям сотни запросов?)

И прям в Yii их нет?)) Про schemaCachingDuration помните?)

Нет, неоптимизированный план запросов бывает у всех.

Но дело даже не в том.

Не помню как с этим делом в Юии2. Но помню неоднократные и справедливые разговоры мейнтейнеров, что незачем за них волноваться, что и кеширование решает, и СУБД закеширует и драйвер и даже если ничего не закешируется, то это такие копейки в скорости все эти десятки мусорных запросов, что не о чем беспокоиться.

Так вот, даже в столь нелюбимом всеми нами ВП кеширование решает.

Ерунда это всё и вздор.

На микросайтах никто и никогда не заметит разницы производительности с кешем или без. А уж между кешированным ВП и кешированным Юии так точно не заметят разницы.

И да, я говорил не о множестве файлов. Я говорил о том, что даже в нужном коде много "лишнего", что нужно только на случай функций которые нам не нужны именно в этом проекте.

как вариант, пишется на php свой поиск

вот пример: http://www.apriorico.com/ страниц ~1000, сайт на html+SSI, + поиск php, заявка на почту

Короче подробней надо: что за сайт, что за услуги и т.д. Это уже считай техзадание прорабатывается, тащемта.

Вот у меня яркое впечатление перед глазами: 2014 год, оконная фирма, сайт только что перенесли с юкоза, гы, в ModX. Ну и там был кромешный ад с кучей css файлов и с кодом, не раз побывавшем в Ворде и обратно. Это был просто тотальный пипец.

А в плане структуры, кода, можно сказать одно: если сначала сделать на чистом html, то потом без потерь куда угодно можно будет натянуть: хоть на вордпресс, хоть куда.

А вот если сделать на какой-то cms, а потом начать переносить на другие, потерь не избежать. Чисто физически программер чаще всего не сможет учесть все нюансы, что-то да потеряется или изменится, а в итоге могут полететь позиции.

Теоретически да.

Практически - был у меня один сайт.

Пытался натянуть на ЦМС.

На 150 страниц там было около 60(!) разных вариаций верстки.

Короче закончилось всё новым сайтом с существенной деградацией разнообразия и ручным копипастом контента со старого сайта.

Ибо нефиг. (Ибо нефиг было со мной не советоваться - старые школьные друзья))

Пример не показательный. То же самое можно и в цмс наворотить. Это уже крайности безумия.

---------- Добавлено 25.08.2016 в 19:22 ----------

mendel,

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

Совсем не показательный.

Это были дизайнеры (оффлайновые: архитекторы по образованию, планировка квартир, оформление, полиграфия и т.п.). А исполнители были слабоваты, да еще и с клиентом спорить не стали. В результате - верстка на таблицах, вся перелинковка картинками без альтов и т.п.

Ну и да, поскольку это таки близкие, то я таки честно потратил часа два-три на попытки это распарсить на что-то хоть отдаленно единообразное и выдавить из этого хоть какую структуру, пока не плюнул и не похоронил.

В целом я с аргументом соглашусь. Как правило перенос статики в динамику проще. Просто вспомнилось.

То есть вместо "сразу ЦМС/Самопис на фрейме" мы идем сложным путем, костылями и прочими ужасными вещами. Зачем вы так над собой издеваетесь?)

---------- Добавлено 25.08.2016 в 21:11 ----------

Посчитайте запросы того же ВП.

schemaCachingDuration - он не включен изначально ,если он вам не нужен - так и не включайте.

Вот вот, но в фрейме, да еще на предполагаемых 25 страниц сайта - отрегулировать лишние запросы - 2 минуты дела .даже если их накидал.

Конечно заметят. Просто вы не совсем понимаете суть кеше - если у вас запрос работает больше 10 секунд - это нужна оптимизация БД/запроса а не кеширование. Кеширование нужно на случай очень большого количества посетителей -что бы не дергать БД подключением 1000 раз за секунду, а отдавать части посетителей кеш.

---------- Добавлено 25.08.2016 в 21:14 ----------

Самый простой пример, это когда нужно было мне просмотреть проблему с престашопом. Я в последнее время все на Yii2 делаю, привык к дебагингу, перехвату исключений и тд. А потом пришла "популярная цмс для инет магазина" и я потратил в 4 раза больше времени на поиск проблемы, просто потому, что там была туча плагинов типа подписки, оплаты и тд, но не было нормального отлова ошибок и прочих мелочей.

Зачем? Без тысячи бездумно налепленных плагинов его выдерживает любой хостинг на любой приемлимой нагрузке.

Ну я и не включаю никогда. И ничего не происходит. А ведь там "сотни запросов" сразу)

А зачем их регулировать если и с кривыми запросами всё прекрасно работает?

Вы впадаете в страшный грех. Грех преждевременной оптимизации, он же "нанооптимизация". У нас визитка на 25 страниц, которая по факту разрастется в 50 страниц по сути и 200 статей на разные группы ключей.

Ну какая тут к черту оптимизация запросов?

То это не сайт на 25 страниц который вообще хотели сделать без ЦМС))

Да и в тяжелом проекте время отклика в 10 секунд это надо умудриться.

Последний раз у меня дикие тормоза были в 6 секунд. Лажа была в том, что был включен подробный лог, который писал все вызовы АПИ движка, а это под тысячу записей, при этом он открывал и закрывал поток при каждой записи, ибо так надежнее, а дело было на перегруженной облачной ноде, где файловую систему куда писался лог умудрились утянуть в сеть, и на другую ноду.

В час пик у хостера были такие тормоза. SQL запросы тоже были не оптимизированны, их было чуть больше сотни. Но уменьшение уровня лога с параноидального до подробного вернуло скорость в рамки 200мс.

Ну не знаю я как нужно издеваться чтобы иметь 10 секунд. Не знаю. При современных серверах то.

Да еще и на статейнике/визитке, который мы обсуждаем.

Еще раз. У нас СТАТИЧНЫЙ САЙТ. Тут даже проблему инвалидации решать не нужно. При задержке в 1сек (а больше затормозить сайт думаю вам не удастся даже если специально будете навешивать плагины для тормозов) мы пройдем все 25 страниц по разу, а дальше она будет возвращаться из кеша. Сильно зависит от механизма кеширования, но большую часть проблем заберет на себя банальный нгинкс, который хостер поставит перед нами из экономии)

Понимаю. Есть один проект на ОпенКарт. Прекрасно понимаю. По этой причине я ушел от всяких ВП и т.п.

Понимаю дважды, ибо в моей ЦМС средства отладки слабоваты в сравнении с тем же юии. Но я и не агитирую ПИСАТЬ на ВП.

Я говорю что оно приемлимо для заказчика. Не более.

Кеширование подразумевает, что отдается html-файлик, а php даже не стартует?

Тогда верю.

Иначе на голой страничке за это время фреймворк не успеет инициализироваться.

За 250 р вряд ли Вы имеете больше 1GB / 1 ядро / 2 GHz. Возможно и не ssd.

1-байтовая php страничка у меня отдается 8-10к раз в секунду на 2*2GHz + ssd.

П.С.

Если бы ТС был программистом, то точно посоветовал бы самопись + pma | mysql gui :^)

А так могу посоветовать:

самопись + pma | mysql gui (сам таким пользуюсь, некоторый функционал вынесен в протоадминку: отправка писем, бизнесоспецифичные фичи; список частоиспользуемых запросов под рукой в файлике)

самопись + админка (правда эта админка будет явно уступать cms в широте функционала, но в глубине может и выигрывать, так как будет необходима, как я понял, админка только для сущности, ну или просто сохранялка кода в файл)

cms

фреймворк + pma | mysql gui

фреймворк + админка (то же, что и для самопись + админка)

На фреймворке будет явно дороже, потому что там типа крутые перцы пишут, которым не хватает на сыр. Если предложат дешево, то будет явно некачественный говнокод на фреймворке.

При нормальном ТЗ и реализации самопись лучше.