Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 75
На мой взгляд, автор немного перегибает палку, но общая мысль очень правильная.
Ну да. Несколько гиперболизирует, чтобы ярче донести суть. Но по сути с ним согласен, часто делаем лишнее, забывая суть.
Не назвал бы это гиперболизацией. Он именно перегибает палку — ставя приоритет одному вопросу, вынужден занижать важность других. Не в том дело, что кнопка tweet дублирует функциональность твитера, а в том, что она увеличивает удобство отправки конкретного твита и вероятность этого события. Это сейчас важная часть раскрутки и дополнительное удобство для читателя. Ведь хороший текст вынуждает им поделиться, и помочь в этом не грех. Опять же никто не мешает производить загрузку этого дополнительного функционала по событию отрисовки основного контента.
А в чем автор реально прав, так это в том, что собирать страницу из базы налету для каждого посетителя это перебор.
А в чем автор реально прав, так это в том, что собирать страницу из базы налету для каждого посетителя это перебор.
Дак key=>value БД быстрее чтения файла отработают, почему бы и нет?
Вы в это правда верите, или есть доказательства?
Ничего не мешает разместить kv бд в оперативной памяти, поиск определенного ключа займет всего несколько тактов, тем более если ключи построены в посимвольное дерево, ну и соответственно сравним со скоростью работы дискового накопителя, разница будет существенной
Пока я могу сказать, что это ваши домыслы.
Возьмите любимый язык программирования и замерьте время чтения из файла и время выборки из бд — это же так просто, десяток-другой строк кода. Только учтите, что сравнивать надо при одинаковых условиях, т.е. либо делать открытие-чтение-закрытие в обоих случаях, либо использовать закешированный дескриптор и измерять только время чтения одинакового объема данных.
Возьмите любимый язык программирования и замерьте время чтения из файла и время выборки из бд — это же так просто, десяток-другой строк кода. Только учтите, что сравнивать надо при одинаковых условиях, т.е. либо делать открытие-чтение-закрытие в обоих случаях, либо использовать закешированный дескриптор и измерять только время чтения одинакового объема данных.
> замерьте время чтения из файла и время выборки из бд
То есть сравниваем выборку и простое чтение? А поиск информации в вашем файле? А если там тысячи/миллион записей? А если эту же информацию считывать повторно множество раз?
Само же время чтения будет таким же, так как происходит то же чтение из файла. А может и быстрее для бд, если таблица в ОП.
То есть сравниваем выборку и простое чтение? А поиск информации в вашем файле? А если там тысячи/миллион записей? А если эту же информацию считывать повторно множество раз?
Само же время чтения будет таким же, так как происходит то же чтение из файла. А может и быстрее для бд, если таблица в ОП.
Если данные в ОП, то оно быстрее чем если данные на файловой системе. Верно для большинства типов БД.
Вы так говорите про key-value, будто это единственный способ хранить все в ОП…
Да и не всегда все можно хранить в ОП.
Ну и в лучшем случае, не несколько тактов а десятки, сотни, тысячи)).
Вы так говорите про key-value, будто это единственный способ хранить все в ОП…
Да и не всегда все можно хранить в ОП.
Ну и в лучшем случае, не несколько тактов а десятки, сотни, тысячи)).
никто также не мешает разместить файлы в оперативной памяти
Доказательства в самой структуре NoSQL баз. Их индексы работают эффективнее, чем кешированная дисковая подсистема сервера. Конечно это заметно на объемах индексов превышающих объем памяти под fs кеш.
Не знаю, как автор, а я говорил о сборке из базы страниц, на которых есть больше одного обращения к базе. например страница, где помимо статьи: комментарии к статье, актуальный путь в меню, блок «другие материалы по теме», последние комментарии на форуме… У меня есть посещаемый сайт, у которого главная страница собирает больше 100 материалов по разным темам, что вызывает более 300 sql запросов. Если бы эта страница не складировалась в кеш при каждом изменении, то текущая посещаемость просто свалила бы сервер.
Если она в оперативной памяти, то быстрее, иначе нет.
Такие странные, дак давайте вообще текстовыми файлами информацию раздавать. Открыл «этот сайт», даже желание что то читать пропало, как будто на несколько лет назад откатился. Текст ужасный, дизайна как такового вообще нет, а что «так быстро» открывается не удивлен. Задача веб-проекта — сделать красивый, приятный, информативный сайт и при этом оптимизировать его и заставить быстро грузиться, а не сделать убогое г***, и прикрывать это оптимизацией.
А что не так с сайтом, чего там не хватает? Можно, конечно, и покрасивее было оформить, но я бы не сказал, что сайт сейчас «убогое г***».
В чём убогость? Недостаточно эппло/гугло/твиттерообразно?
Такие сайты очень радуют когда на них натыкаешься — никаких социальных кнопок, плавающих панелей, плавающего фона, рекламы, счетчиков, флеша (за редкими исключениями), идиотской расцветки (синий на синем, 6 кегль шрифта, комик санс и прочие извращения) и т.д. Я не говорю что это абсолютная истина дизайна или что сайт в заметке идеальный (шапку точно чинить надо), но на мой взгляд большинство вебдванольненьких сайтов весьма посредственны. При тех же усилиях вебмастера испортить текстовую статичную страницу гораздо сложнее.
>Задача веб-проекта — сделать красивый, приятный, информативный сайт и при этом оптимизировать его и заставить быстро грузиться
Судя по текущей ситуации, большинству команд это не по силам. А про убогое говно вы погорячились. Вот в бумажных книжках тоже просто текст на белом фоне и если верстальщик не болен на всю голову, то результат как правило «красив и приятен».
>Задача веб-проекта — сделать красивый, приятный, информативный сайт и при этом оптимизировать его и заставить быстро грузиться
Судя по текущей ситуации, большинству команд это не по силам. А про убогое говно вы погорячились. Вот в бумажных книжках тоже просто текст на белом фоне и если верстальщик не болен на всю голову, то результат как правило «красив и приятен».
Он просто на примерах хочет донести одну и очень правильную мысль: решайте проблемы посетителей, а не свои. Я бы еще добавил про капчу. Это решение, которое избавляет от проблем администратора сайта, но создает кучу проблем посетителю. Вроде бы это всем понятно, но капч в инете не стало меньше. Администратор подсознательно стремится автоматизировать все администрирование сайта, чтоб спокойно пить пиво и ни о чем не думать. Ему даже в голову не приходит та очевидная мысль, что он должен вкалывать, чтобы заинтересовать посетителя.
Блоги ведь действительно в первую очередь для чтения, но ни один блог почему-то не сосредоточен на этом. Лично я, хотел бы видеть в блоге функции альтернативного форматирования, смены цветовой гаммы (с общепринятыми заготовками).
Блоги ведь действительно в первую очередь для чтения, но ни один блог почему-то не сосредоточен на этом. Лично я, хотел бы видеть в блоге функции альтернативного форматирования, смены цветовой гаммы (с общепринятыми заготовками).
Даешь неделю переводов prog21 на Хабре!
Больше сотни постов можно настрочить!
Больше сотни постов можно настрочить!
> Нет никакой магии в том, чтобы раздавать простые статические страницы.
можно использовать nginx
> Что удивительно — так это то, что большинство разработчиков движков блогов решают не те проблемы.
На примере drupal — простенькое решение модуль boost.
Так что все не так плохо :)
можно использовать nginx
> Что удивительно — так это то, что большинство разработчиков движков блогов решают не те проблемы.
На примере drupal — простенькое решение модуль boost.
Так что все не так плохо :)
Ну вообщето все направлено на увеличение количество читателей, а не держателей блогов, которым не нужны читатели.
Отсюда и виджеты с лайками, отсюда и удобная админка автору и реляционные базы. Все это измерено и вымерено и доказана польза. Как ни как пляшут то все от статистики.
Пусть раздражает но это работает, как реклама прокладок.
Интересно, а этим он тоже решает свои проблемы?
CMS как раз и решает проблему поддержки сайта, ничего в этом нового и удивительного нет. А быстрая отдача сформированных страниц для чтения — это вообще не проблема. Включить fastcgi_cache и поставить формат ключа и время. Странички будут улетать так же шустренько, как и на этом сйте. То, что не всякий держатель сайта использует кеши — это другой вопрос.
Я так понимаю, наезд был на количество запросов и суммарный трафик загрузки, на что кеш никоим образом не влияет.
А что касается скорости выдачи основного ответа (html), то кеш — не является панацеей. Нужно просто грамотно писать, а иначе и в кеше будет валяться неактуальная инфа, промахи могут убивать сайт с сервером и т.д. и т.п.
А что касается скорости выдачи основного ответа (html), то кеш — не является панацеей. Нужно просто грамотно писать, а иначе и в кеше будет валяться неактуальная инфа, промахи могут убивать сайт с сервером и т.д. и т.п.
Реляционная база данных, хранящая посты, которые могут быть на лету отображены при помощи шаблонов с поддержкой тем оформления (...) Неужели вы будете вычислять их во время работы программы? Вы ведь их уже знаете. Вы вычислите их один раз во время разработки — и готово.В этих двух фрагментах прослеживается наезд на постоянную генерацию страницы, вместо отдачи готового файла (в том числе из http-кеша после сборки, но такой вариант не упомянут автором). Естественно, настраивать его надо с головой. Наезд на количество запросов тоже присутствует, упрёк на перегруженный дизайн сайтов, которые изобилуют не несущими информации рамками и текстурами.
Не совсем понял фишку, хранить статичные штмлки? Смена дизайна, архитектурты и еще чего нить, означает очень большой геморой или не? Кнопки с твиттером, фейсбуком, больше напоминают, о том, что можно написать в соцсеть, чем добавляют удобства и тут еще вопрос, кто выигрывает автор ресурса или читатель у которого замедляется на 0,01 секунды время генерации и загрузки страницы
Я так понимаю, у него всё страницы генерируется, но не перед отдачей клиенту, а при изменении контента
Скорее всего, хотя может и в редакторе делает. Для его философии (никакой авторизации, персонализации и комментариев) вполне подходящая реализация.
Смена дизайна, архитектурты и еще чего нить, означает очень большой геморой или не?Никто же не говорит, что страницы надо полностью вручную писать. Можно генерировать статические страницы при помощи специального движка так же, как обычно генерируются динамические.
читатель у которого замедляется на 0,01 секунды время генерации и загрузки страницыТут вы правы, в крайности впадать не надо, и лишать пользователя удобства ради доли секунды — это не круто. Основная мысль статьи по-моему не в том, что надо сразу все кнопки убрать, а в том, что добавляя каждую подобную фишку, надо задуматься. А то получится как на многих современных сайтах — на странице тысяча свистелок и каждая замедляет на долю секунды, и в итоге всё тормозит.
На эту тему по-моему вполне разумные вещи писал Фоулер martinfowler.com/bliki/EditingPublishingSeparation.html
Тупо реклама сайта.
Хрень какая-то!
Усли уж так рассуждать, то зачем машине педаль газа?! Можно ведь на метро…
Усли уж так рассуждать, то зачем машине педаль газа?! Можно ведь на метро…
А можно для несведущих, какими средствами пользуетесь для генерации и сохранения всех страниц?
Чем пользуется автор — не знаю, можете у него спросить, на сайте есть контактная информация. Сам я из подобных систем знаю только Jekyll
movabletype рулит, да.
Всё это прекрасно для read-only сайтов. Но если есть задачи типа «добавить коммент», «создать профиль на сайте» и т.д. — тут уж без скриптов не обойтись.
Сам, кстати, тоже использую сгенеренный набор HTML-файлов на хостинге, если сайт позволяет (каталог продукции без поиска (вернее, с помощью Яндекса), корзины и т.д.).
Сам, кстати, тоже использую сгенеренный набор HTML-файлов на хостинге, если сайт позволяет (каталог продукции без поиска (вернее, с помощью Яндекса), корзины и т.д.).
добавлять коменты можно через disqus.
Я, конечно, об этом подумал, и это (вообще выделение функционала в сторонние сервисы) имеет свои недостатки — отсутствие или затруднённая кастомизация, каждый сервис свои наработка по JS и CSS использует — будет много дублирования, да и склеить в один файл будет сложно.
В общем, чем больше функционала, тем менее выгодно становится использовать сторонние сервисы, а некоторые функции (типа того же личного кабинета) реализовать без серверных скриптов невозможно.
Ну и конечно всё зависит от типа сайта — бложек — это одно, а какая-нибудь CRM — это другое.
В общем, чем больше функционала, тем менее выгодно становится использовать сторонние сервисы, а некоторые функции (типа того же личного кабинета) реализовать без серверных скриптов невозможно.
Ну и конечно всё зависит от типа сайта — бложек — это одно, а какая-нибудь CRM — это другое.
Недавно надо было небольшой сайтец сделать со сравнительно редко меняющимся контентом (раз в день), вспомнил, что xsltproc есть по-умолчанию в большинстве линукс-систем. В итоге весь движок выглядел, как набор из нескольких xslt шаблонов + данные в xml + nginx для сгенирированных страниц + пару shell скриптов чтобы все склеить. Работает чудно, закидывал сотней запросов в секунду, система почти не дрогнула.
Сотни запросов на генерацию? Статика-то должна отдаваться со скорость over 9000 per second даже на довольно слабеньком железе.
А оно нужно для небольшого бложика? Всё равно будете платить за хостинг гораздо больше, чем он потребляет ресурсов.
Экономией начинают заниматься на высоконагруженных сайтах, где каждый сэкономленный байт дает значительный выигрыш.
Экономией начинают заниматься на высоконагруженных сайтах, где каждый сэкономленный байт дает значительный выигрыш.
Сотней запросов не на генерацию, конечно, а на статику. Over 9000 тестовых запросов, простите, сделать не было возможности.
Пример с решетом Эратосфена удачно показывает, какую проблему надо в самом деле решать: не вычислять повторно то, что эффективнее закешировать. Вот один из основных корней тормознутости (есть ещё неэффективные алгортимы вычисления). Путей решений этой проблемы много, включая и использование исключительно статических html-ек, но не надо зацикливаться именно на таком режиме. Вполне адекватно даже использовать тормозное хранилище с тормозным шаблонизатором, если результат будет вычисляться один раз на несколько тысяч запросов, и кешироваться до тех пор пока будет оставаться валидным (т.е. например до добавления очередного коментария..).
Проблемы скорости загрузки и так хорошо решаются инструментами автоматически
А вот проблемы удобства заполнением контента решаются намного хуже.
Так что все правильно и проблему решают ту.
А вот проблемы удобства заполнением контента решаются намного хуже.
Так что все правильно и проблему решают ту.
Логика, возможно, есть, но это уже другая крайность.
Чтобы читателю было удобно, нужно, во-первых, чтобы этот читатель был. А для этого нужно, чтобы было что почитать. А для этого нужно чтобы было кому написать. Так что проблемы авторов первостепенны. Их нужно решать, чтобы проблемы читателей вообще возникли.
Это значит что автором должно быть удобно. Это значит и фидбек должен быть, потому что фидбек уже сам по себе контент (комментарии иногда лучше статьи). Это значит и кнопки лайк должны быть, чтобы привлекать других читателей.
Конечно, сам он может писать хоть в HTML. Потому что верит в то, что делает. А вера способна закрыть глаза на всё остальное и дать сил. Но это не значит, что его метод подходит для всех.
Чтобы читателю было удобно, нужно, во-первых, чтобы этот читатель был. А для этого нужно, чтобы было что почитать. А для этого нужно чтобы было кому написать. Так что проблемы авторов первостепенны. Их нужно решать, чтобы проблемы читателей вообще возникли.
Это значит что автором должно быть удобно. Это значит и фидбек должен быть, потому что фидбек уже сам по себе контент (комментарии иногда лучше статьи). Это значит и кнопки лайк должны быть, чтобы привлекать других читателей.
Конечно, сам он может писать хоть в HTML. Потому что верит в то, что делает. А вера способна закрыть глаза на всё остальное и дать сил. Но это не значит, что его метод подходит для всех.
В детстве думал, что все сайты именно так и работают — т.е. отписал что-нибудь на форуме — твой пост просто добавился к .html коду странички.
Можно ещё varnish использовать и кешировать блоки на странице. Например, блок с статьёй можно кешировать с большим TTL, всё равно не поменяется, а если поменяется — инвалидация кеша, а блок комментариев можно не кешировать или кешировать с минимальным TTL. В принципе, ничем от статичных HTML файлов отличаться не будет.
Будет отличаться необходимостью инициализации запроса на backend, паразитными запросами/подключениями к базе данных и т.д. Правда всё это реально заметно скорее на сайтах с большой нагрузкой — хорошие скрипты держат сотни запросов в секунду, а это миллионы хитов в день.
Сайты с большой нагрузкой прекрасно работают на подобной архитектуре, даже несмотря на проблемный в плане производительности backend.
И что за проблема с запросами к db — или HTML странички генерируются из мыслей? Такое же подключение.
К тому же минус генерации — один статичный файл, а блочное кеширование позволяет иметь несколько различных блоков на странице.
И что за проблема с запросами к db — или HTML странички генерируются из мыслей? Такое же подключение.
К тому же минус генерации — один статичный файл, а блочное кеширование позволяет иметь несколько различных блоков на странице.
Я имею в виду случай, когда скрипт используется по сути только для сборки блоков — если результаты работы скрипта будут постоянны во времени (например, нет блока «рандомные новости в категории»), то разница как раз будет в тех «мелочах», из которых складывается время работы скрипта. Конечно, даже блок пользователя может отправить HTML-странички на отдых, так что это скорее узкая задача.
А про блочное кэширование я в курсе, высокопосещаемые сайты скорее используют генерацию блоков на разных инстансах и последующую сборку в единую страницу — кэширование блоков почти везде имеется в популярных CMS.
А про блочное кэширование я в курсе, высокопосещаемые сайты скорее используют генерацию блоков на разных инстансах и последующую сборку в единую страницу — кэширование блоков почти везде имеется в популярных CMS.
ИМХО: блог — это не только чтиво для посетителей, но и взаимодействие автора с читателями и наоборот. Без этого взаимодействия не будет обратной связи и нарушается сама идеология блога.
Давайте тогда уж вернемся к отзывам по e-mail… потому что построение дерева комментариев существенно увеличивает время загрузки страницы блога.
Впадание в крайность, мне кажется, не самая лучшая идея.
Давайте тогда уж вернемся к отзывам по e-mail… потому что построение дерева комментариев существенно увеличивает время загрузки страницы блога.
Впадание в крайность, мне кажется, не самая лучшая идея.
Сейчас большинство сайтов — это не просто ресурс с каким-либо содержимым, чтобы его просто отдавать (статикой или динамикой с кешем), но отдельная сложная система по взаимодействию с пользователем. Веб-строители предлагают пользователям то, что они хотят: оставить отзыв, обсудить, покритиковать, потроллить. Так как мир неуклонно усложняется, то и способ взаимодействия с информацией меняется.
Идет генерация новых идей, что в большом кол-ве случаев приводит к тому, что сайт, созданный с одной конкретной целью начинает выполнять еще 100500 функций, большая часть которых вообще кроме разработчику нафиг не нужна. А разработчик рад — как гениально все сделал и продумал. Опять же СЕО, популярность, заработок с проекта бабла — по разным причинам говносайтами становятся многие хорошие проекты. Я сам таких наплодил в свое время :)
Идет генерация новых идей, что в большом кол-ве случаев приводит к тому, что сайт, созданный с одной конкретной целью начинает выполнять еще 100500 функций, большая часть которых вообще кроме разработчику нафиг не нужна. А разработчик рад — как гениально все сделал и продумал. Опять же СЕО, популярность, заработок с проекта бабла — по разным причинам говносайтами становятся многие хорошие проекты. Я сам таких наплодил в свое время :)
То, что большинство блог-движков представляют из себя перегруженный и обросший нездоровым наследстком звездец никоим образом не означает, что нужно срочно взрывать мосты и отправляться в каменный век.
Конкуренция и «гонка вооружений» — она и в вебе гонка вооружений. Каждый стремиться сделать «круче чем у другого».
Вижу единственное решение этой проблемы(?) — модульность систем, в нашем случае, движков блога. Что бы пользователь/админ мог просто отключить ненужные модули.
К примеру, базовая установка WordPress — превратилась из простого блого-движка в монстрообразную систему, 99% функционала которой не нужны обычному пользователю, но отключить это простым способом нельзя.
ИМХО. Мне кажется, что в будущем общедоступные CMS/CRM примут вид набора сервисов, с максимально-модульной структурой (практически идеология Drupal) и минимальным по функционалу «ядром».
Вижу единственное решение этой проблемы(?) — модульность систем, в нашем случае, движков блога. Что бы пользователь/админ мог просто отключить ненужные модули.
К примеру, базовая установка WordPress — превратилась из простого блого-движка в монстрообразную систему, 99% функционала которой не нужны обычному пользователю, но отключить это простым способом нельзя.
ИМХО. Мне кажется, что в будущем общедоступные CMS/CRM примут вид набора сервисов, с максимально-модульной структурой (практически идеология Drupal) и минимальным по функционалу «ядром».
Во всём нужна золотая середина.
Очень редко где возможно публиковать полностью голый HTML. В примере убогий сайт, немного расширив его, автор столкнется с ситуацией, когда потребуются скрипты.
Виджеты социальных сетей могут и не тормозить — api.yandex.ru/share/
Очень редко где возможно публиковать полностью голый HTML. В примере убогий сайт, немного расширив его, автор столкнется с ситуацией, когда потребуются скрипты.
Виджеты социальных сетей могут и не тормозить — api.yandex.ru/share/
имхо, я бы все, что не критично к отображению, загружал бы скриптом из window.onload
чтобы страница сперва загрузилась, отрисовалась и отобразилась, а уже потом появлялись лайки и прочие свистелки-перделки.
чтобы страница сперва загрузилась, отрисовалась и отобразилась, а уже потом появлялись лайки и прочие свистелки-перделки.
Вообще, автор не на том акцент делает — возможно у него до датацентра 10-ГБитный канал, но у большинства читателей его блога задержки будут десятки мс, так что им визуально практически без разницы — статические страницы или динамические. Говоря в общем, есть статистика, по которой у 10 000 самых популярных сайтов backend вместе со всеми своими кишками занимает 10-20% от общего времени доступности страницы. То есть проблема-то на другом конце провода, а автор сравнивает статические странички с динамическими. Просто нужно грамотно использовать инструменты, держа в уме то, как страничку будет видеть конечный пользователь, а не условный Apache Benchmark или JMeter.
> Все кроме меня делают с сайтом prog21 одно и то же — они открывают страницы и читают их.
А что, там можно сделать что-то еще… Комментарий написать, мнение оставить, обсудить, с друзьями поделиться в сетях, в избранное добавить… Может быть там поиск есть, какие-то фильтры для удобства тех самых забытых всеми по мнению автора людей?…
> Решая не ту проблему
Надо полагать другие проблемы решать не нужно…
А что, там можно сделать что-то еще… Комментарий написать, мнение оставить, обсудить, с друзьями поделиться в сетях, в избранное добавить… Может быть там поиск есть, какие-то фильтры для удобства тех самых забытых всеми по мнению автора людей?…
> Решая не ту проблему
Надо полагать другие проблемы решать не нужно…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Решая не ту проблему