Comments 90
Мне кажется, или тут не хватает таблички «сарказм»?
Если после прочтения статьи еще нужна эта табличка, значит я как автор не доработал.
Как человек лишь интересующегося темой (ибо разработку веду на мобильных платформах) принял бы за чистую монету. Мало ли какие тенденции в хайлоаде. Но при прочтении возникает смутное сомнение. Так что автору хвала, достаточно тонко, но уловимо.
По мере прочтения комментариев я понял: принимая человека в хайлоад, у него забирают чувство юмора. Хорошо, что вы занимаетесь мобильной разработкой!
А вы еще до сих пор в этом сомневаетесь?
Даже если прочитать наоборот, ваши советы неоднозначны
Так, совета думать головой не было.
А без головы дитятко воткнет кэш результатов отработки и потом будет кушать все проблемы поддержки и масштабирования, вместо оптимизации запросов к бд, что являлось первопричиной.
Или же полезет оптимизировать алгоритмы с умным видом всезнайки, в то время как проблема в железе и чудо-юдо просто не могло предположить такой баттлнэк из-за узкого кругозора.
Ум и опыт, опыт и ум. И поэтому да, нельзя просто так взять и поднять производительность, если ты дядя Вася, даже с набором вредных советов, но без опыта и ума
Так, совета думать головой не было.
А без головы дитятко воткнет кэш результатов отработки и потом будет кушать все проблемы поддержки и масштабирования, вместо оптимизации запросов к бд, что являлось первопричиной.
Или же полезет оптимизировать алгоритмы с умным видом всезнайки, в то время как проблема в железе и чудо-юдо просто не могло предположить такой баттлнэк из-за узкого кругозора.
Ум и опыт, опыт и ум. И поэтому да, нельзя просто так взять и поднять производительность, если ты дядя Вася, даже с набором вредных советов, но без опыта и ума
Да, тут вы меня уели. Надо было добавить еще один совет:
Старайтесь поменьше думать
Последние результаты исследований в области нейрофизиологии убедительно доказали, что причиной преждевременного старения является излишнее использование головного мозга. Для рутинной деятельности, к которой можно отнести и разработку, вполне достаточно ресурсов спинного мозга и (в особо сложных случаях) подкорки.
Старайтесь поменьше думать
Последние результаты исследований в области нейрофизиологии убедительно доказали, что причиной преждевременного старения является излишнее использование головного мозга. Для рутинной деятельности, к которой можно отнести и разработку, вполне достаточно ресурсов спинного мозга и (в особо сложных случаях) подкорки.
Прям вредные советы Остера.
Всё. Я хочу от тебя ребёнка! Ей-богу уже начиная со 2-го пункта меня пробрало. :)
Однозначно не хватает. Уже после первого принципа начал ее искать — не нашел. Это скорее антипаттерны, но все зависит от конкретного контекста. Немного увеличить производительность — да, это может помочь. В настоящем HighLoad это антипаттерны, представленные как серебрянная пуля. Был в гостях у Елизарова на jug.ru/, объективно говорилось совершенно об обратном.
Подождите, вы хотите сказать, что эти советы могут быть вредными?
Да, могут быть. ORM, по типу MS Entity Framework, легко сгенерит Вам запрос с 300+ джойнами.
На счёт кешей и одиночных операций — тоже крайне спорный момент.
Выключать мозг, в любом случае, нельзя.
На счёт кешей и одиночных операций — тоже крайне спорный момент.
Выключать мозг, в любом случае, нельзя.
Не вникайте в базу данных
Обычно так делают в самом начале проекта. Идеальный ORM — универсальный ORM. Когда же начинаются реально высокие нагрузки, то алгоритмы специализируются на данных. Вплоть до того, что вот из этой таблицы мы всегда извлекаем быстро N-записей, это и будет верный результат. Извлекать вот так-то очень быстро. Естественно без джоинов. Нормальные формы часто тоже становятся препятствием, но не во всей же БД делаются такие «заточки», а только в самых узких местах.
Тюнинг БД из той же оперы.
Одиночные операции вместо пакетных
Конвейер наше все. Как начал Форд их использовать, так мы и продолжаем. Те же видеокарты, имеют кучу конвейеров. Промышленные ЭВМ содержат специфические конвейеры для разных операций. Например, лучше быстро складывать числа, чем иметь универсальный модуль, но жутко медленный.
Еще пример. По сети приходят пакеты. Мы их как-то обрабатываем и пишем в БД. 100 пакетов в минуту. Наша ИС обрабатывает 10 пакетов в минуту, но зато быстро пишет в БД. Обрабатываем первый пакет, потом сразу берем пачку, обрабатываем и быстро пишем в БД. Частый прием оптимизации.
Никаких кэшей
Кеш надо использовать правильно, тогда не будет проблем с актуальностью данных. Если придерживаться совета из статьи, то ни о каких распределенных системах и речи быть не может, это же какие накладные расходы на синхронизацию.
Используйте единственный примитив синхронизации
Какой? Все зависит от задачи. Мой сосед по общежитию как то сказал профессору на экзамене по ассемблеру: «Мой код на ассемблере никогда не будет так эффективен, как ассемблерный код, выданный компирятором». Свои велосипеды надо писать когда другие средства уже не помогают, а это, поверьте мне, бывает очень редко.
Применяйте как можно более простые алгоритмы
Конечно, все используют эффективные алгоритмы. Других просто нет. Все зависит от задачи и проблемы. Где простые алгоритмы дают приемлемую производительность, то сложные (реально сложные) алгоритмы могут дать колоссальную производительность. Обратное тоже верно.
Используйте умолчательные настройки
На старте да, это возможно, но как только начинается продуктивная эксплуатация, то ни о каких стандартных настройках и речи быть не может. Самый простой пример: у меня, как у разработчика, вся ИС размещается в 2-ух гигабайтах оперативной памяти. Вполне приемлемый объем. На сервере же, эта система запросто может занимать от 16-и гигабайт и выше. Хочешь выделить памяти виртуальной машине — задай нужный флаг. А это уже настройка.
Локальное взаимодействие ничем не отличается от удаленного
Да, классный вариант для архитектуры. Есть клиент, есть сервер. Никакой разницы, на одной машине выполняется код или на разных. Но это до поры до времени. 99% ИС это устроит. Но вот если вам надо обмениваться реально большими объемами данных, то тут и shared-memory и собственные блоки памяти, управляемые из аддона к ядру ОС и пр. шалости.
Обычно так делают в самом начале проекта. Идеальный ORM — универсальный ORM. Когда же начинаются реально высокие нагрузки, то алгоритмы специализируются на данных. Вплоть до того, что вот из этой таблицы мы всегда извлекаем быстро N-записей, это и будет верный результат. Извлекать вот так-то очень быстро. Естественно без джоинов. Нормальные формы часто тоже становятся препятствием, но не во всей же БД делаются такие «заточки», а только в самых узких местах.
Тюнинг БД из той же оперы.
Одиночные операции вместо пакетных
Конвейер наше все. Как начал Форд их использовать, так мы и продолжаем. Те же видеокарты, имеют кучу конвейеров. Промышленные ЭВМ содержат специфические конвейеры для разных операций. Например, лучше быстро складывать числа, чем иметь универсальный модуль, но жутко медленный.
Еще пример. По сети приходят пакеты. Мы их как-то обрабатываем и пишем в БД. 100 пакетов в минуту. Наша ИС обрабатывает 10 пакетов в минуту, но зато быстро пишет в БД. Обрабатываем первый пакет, потом сразу берем пачку, обрабатываем и быстро пишем в БД. Частый прием оптимизации.
Никаких кэшей
Кеш надо использовать правильно, тогда не будет проблем с актуальностью данных. Если придерживаться совета из статьи, то ни о каких распределенных системах и речи быть не может, это же какие накладные расходы на синхронизацию.
Используйте единственный примитив синхронизации
Какой? Все зависит от задачи. Мой сосед по общежитию как то сказал профессору на экзамене по ассемблеру: «Мой код на ассемблере никогда не будет так эффективен, как ассемблерный код, выданный компирятором». Свои велосипеды надо писать когда другие средства уже не помогают, а это, поверьте мне, бывает очень редко.
Применяйте как можно более простые алгоритмы
Конечно, все используют эффективные алгоритмы. Других просто нет. Все зависит от задачи и проблемы. Где простые алгоритмы дают приемлемую производительность, то сложные (реально сложные) алгоритмы могут дать колоссальную производительность. Обратное тоже верно.
Используйте умолчательные настройки
На старте да, это возможно, но как только начинается продуктивная эксплуатация, то ни о каких стандартных настройках и речи быть не может. Самый простой пример: у меня, как у разработчика, вся ИС размещается в 2-ух гигабайтах оперативной памяти. Вполне приемлемый объем. На сервере же, эта система запросто может занимать от 16-и гигабайт и выше. Хочешь выделить памяти виртуальной машине — задай нужный флаг. А это уже настройка.
Локальное взаимодействие ничем не отличается от удаленного
Да, классный вариант для архитектуры. Есть клиент, есть сервер. Никакой разницы, на одной машине выполняется код или на разных. Но это до поры до времени. 99% ИС это устроит. Но вот если вам надо обмениваться реально большими объемами данных, то тут и shared-memory и собственные блоки памяти, управляемые из аддона к ядру ОС и пр. шалости.
Шелдон?
Дефолтные настройки Apache + MySQL сиииильно вас порадуют, ага.
То есть они не для всех проектов подходят, да?
Я не понял сарказма статьи, извините :)
Для домашней странички или мелкого интернет-магазина или сайта, коих большинство — подходят. Но когда начинается «надо запустить это на VPS с гарантированными CPU 512Mhz и 64 MB RAM» — вот тут уже придется лезть в настройки и заморачиваться кешированием. Или когда на ваш маленький сайт придет Хабра-эффект. Или когда вас зачем-то будут DDoS-ить.
Дефолтные настройки postgresql вообще ни к черту.
Дефолтные параметры запуска KVM зачастую нацелена на универсальную возможность запуска виртуалки на любом железе (производительность же второстепенна).
Дефолтные параметры запуска KVM зачастую нацелена на универсальную возможность запуска виртуалки на любом железе (производительность же второстепенна).
а что у него не так с дефолтами, если не секрет?
У постгреса или kvm?
Постгрес по умолчанию настроен на работу таким образом как будто он запущен на машине с памятью меньше 1GB (shared_buffers) на одном диске (effective_io_concurrency) и как-будто в него совсем не будет записи (checkpoint_segments). Пожалуй к этому можно добавить ident авторизацию (по умолчанию в RHEL/CentOS) которая вводит в прострацию новичков)))).
В KVM может использоваться дефолтное кэширование (writethrough) которое во некоторых случаях не идеально (гости на внешних хранилищах по iSCSI или NFS). Не используются hugepages, отключены некоторые вкусные процессорные флаги. Паравиртуальные драйвера для устройств опять же не всегда по умолчанию.
Постгрес по умолчанию настроен на работу таким образом как будто он запущен на машине с памятью меньше 1GB (shared_buffers) на одном диске (effective_io_concurrency) и как-будто в него совсем не будет записи (checkpoint_segments). Пожалуй к этому можно добавить ident авторизацию (по умолчанию в RHEL/CentOS) которая вводит в прострацию новичков)))).
В KVM может использоваться дефолтное кэширование (writethrough) которое во некоторых случаях не идеально (гости на внешних хранилищах по iSCSI или NFS). Не используются hugepages, отключены некоторые вкусные процессорные флаги. Паравиртуальные драйвера для устройств опять же не всегда по умолчанию.
Постгрес интересовал. Спасибо за ответ!
А если детальнее — shared_buffers это совсем плохо? Где можно почитать про оптимизацию постгреса?
А если детальнее — shared_buffers это совсем плохо? Где можно почитать про оптимизацию постгреса?
Более детальней посмотрите на раздел с описанием использования ресурсов, оф.справка PG всегдя является хорошей отправной точкой.
Почитать про оптимизацию постгреса можно в блогах, например у Depesz, у него достаточно часто появляется свежая инфа и есть статьи с фундаментальными вещами.
Почитать про оптимизацию постгреса можно в блогах, например у Depesz, у него достаточно часто появляется свежая инфа и есть статьи с фундаментальными вещами.
Мне лично понравилась и помогла книга Васильева, там много полезно habrahabr.ru/post/158617/
Не надо использовать высокоуровневые паттерны многопоточности — все эти неблокирующие коллекции, атомарные типы, агенты и тому подобное.
Правильно, их же дураки придумали, а мы умные, мы сами все сделаем гораздо лучше.
Статья напомнила огромное количество серверов и fulltext поиск в одноклассниках.
Зачем придумывать логику если можно наращивать вычислительную мощь.
Автор, Вы сами имели дело с HighLoad?
Зачем придумывать логику если можно наращивать вычислительную мощь.
Автор, Вы сами имели дело с HighLoad?
Конечно, разве я не написал, что все это основано на личном опыте?
Используйте умолчательные настройки
Пример месячной давности. С ростом посещаемости нагрузка на MySQL выросла в разы. Тюнинг настроек дал результат из 400 запросов/сек до 2.5-3к/сек.
Никаких кэшей
Если не использовать разумно продуманное кэширование, то мне при генерации страницы нужно делать порядка 70-80 запросов к БД. Если у меня сейчас 2-3к/сек при кэшированных запросах, я даже представить себе не могу что скажет сервер если я выключу кэш.
Хм, я уважаю личный опыт, поэтому ничего не буду здесь возражать. Возможно, нам удастся избежать противоречий, если вы инвертируете каждый из советов статьи?
Когда читал статью не видел тега «вредные советы». Он изначально был?
Был. Хотя, я думал, что все будет понятно и без него. А оказалось, что надо было большими красными буквами в начале писать. Чудно.
А что в вашем понимании highload?
Отказаться от кеша? Забить на настройки? Время при обработке по одному объекту примерно такое же, как и при пакетной? Приведите пример высоконагруженной системы, которую Вы спроектировали таким образом. Протестируем ее хабраэффектом )
Но это частности, вызванные несовершенством окружения в котором вынуждена работать система, и они не заслуживают серьезного рассмотрения.
Браво!
UFO just landed and posted this here
Первый тег статьи — «вредные советы».
Хорошо, в следующий раз я предварительно буду джва года писать годные, полезные статьи на хабр, и картинкой к посту поставлю эту: facepalm.jpg
Хотя знаете что? Пожалуй, не буду.
Хотя знаете что? Пожалуй, не буду.
По мне так, хотя советы и вредные, но их стоит придерживаться в стартапах. Бывает так, что тратятся месяцы на закладывание в систему зазора на высокую нагрузку, начинается борьба с проблемами которых еще нет, а по факту теряется время и деньги. К тому же как показывает практика большая часть стартапов никогда не взлетит и высокой нагрузки там просто не будет.
Пассаж про Оракл непонятен — разработчик может не быть настолько спецом в Оракле, чтобы подкрутить именно то, что нужно в данной ситуации. Особенно учитывая, что ораклоидов часто нужно хранить отдельно от остальных разработчиков ;)
«Настолько» — может не быть, да. но базовые представления о особенностях работы оракла нужны обязательно.
Я встречал (и приходилось перепиливать) перлы «разработчиков», добавляющих в каждом новом экземпляре одного и того-же запроса рандомные псевдонимы к табличкам, чтобы оракл, не дай бог, не догадался что запрос-то один и тот-же и можно его из курсор-кеша брать…
Я встречал (и приходилось перепиливать) перлы «разработчиков», добавляющих в каждом новом экземпляре одного и того-же запроса рандомные псевдонимы к табличкам, чтобы оракл, не дай бог, не догадался что запрос-то один и тот-же и можно его из курсор-кеша брать…
Я уверен, что писать подобные «юморные» советы должен узнаваемый и уважаемый человек.
Иначе такие статьи просто воспринимаются как «мудрость» от какого-нибудь 19-ти летнего Дениса, пишущего архиватор. Я по диагонали проглядел, автоматически минусанул, а потом только понял, что сдаётся мне господа, это был юмор.
Иначе такие статьи просто воспринимаются как «мудрость» от какого-нибудь 19-ти летнего Дениса, пишущего архиватор. Я по диагонали проглядел, автоматически минусанул, а потом только понял, что сдаётся мне господа, это был юмор.
Из комментов складывается впечатление, что у части хабропользователей история ценится выше контента.
Кстати, пункт 3 и 4 содержат лишь долю шутки. К сожалению, некоторые компании воспринимают пункт 3 полностью всерьёз :(.
Ох, начал читать — подумал, неужели все так хорошо: используйте дефолтные настройки, забудьте про сложные алгоритмы, не вникайте в БД…
А потом увидел теги…
Это за гранью тонкости…
А потом увидел теги…
Это за гранью тонкости…
тонко вышло! моё почтение!
Дошло после второго пункта.
Поглядев на комментарии к статье, пришёл к выводу, что я гениален.
Поглядев на комментарии к статье, пришёл к выводу, что я гениален.
Автор молодец!
Прочитал первый же совет, не понял, позвал коллегу, прочитали вместе — не поняли, пошли читать комментарии, дружно поржали дочитав статью вместе. Чувствую хабр, судя по оценкам, не понял настолько тонкого юмора.
Спасибо, автор открыл глаза :)
Последовал всем советам. Ищу новую работу.
Вы забыли про потоки.
Зачем геммороиться и строить схему взаимодействия потоков, если каждый объект/соединение можно обрабатывать в отдельном потоке?
Зачем геммороиться и строить схему взаимодействия потоков, если каждый объект/соединение можно обрабатывать в отдельном потоке?
А как же совет хранить картинки в базе данных? И отдавать их файликом вроде getimage.php? Ведь это решает кучу проблем масштабируемости, и даёт дополнительные возможности — например ресайз фото на лету, без ненужного хранения всех размеров которые могут понадобиться. А еще можно проверяить права доступа к изображению! И да, это была шутка если что)
Имхо, статья о том, как НЕ НАДО делать. Только логично было бы автору еще в конце дописать, что и программисты тоже не нужны, — ставишь себе CMS и из коробки получаешь уже готовый и настроенный GOOGLE…
Даже всякий шлак на хабре уже в почете, печально.
Так и тянется рука злобно отпародировать прочитанное в приложении к HPC :)
Автору — респект. Данная статья учит критически относиться к таким вот опусам в блогах, типа «Уникальные советы».
Но! Те, кто не в теме, могут воспринять статью серьезно (как некий success story — мало ли как бывает, ну делегировал автор настройку БД всяким там DBA, забил разбираться сам — и все равно получил работающий продукт). Вы бы «вредные советы» в заголовок вынесли, что-ли.
Но! Те, кто не в теме, могут воспринять статью серьезно (как некий success story — мало ли как бывает, ну делегировал автор настройку БД всяким там DBA, забил разбираться сам — и все равно получил работающий продукт). Вы бы «вредные советы» в заголовок вынесли, что-ли.
UFO just landed and posted this here
Если потребуется дальнейшая оптимизация, то от блоков синхронизации можно просто избавиться, и система заработает еще быстрее!Да как же я сразу до этого не додумался!!! Пошел убирать все объекты синхронизации.
Я могу гордиться своей работой! У нас половина этих советов уже используется.
А в чем цель статьи? Посмеяться на тему? Заставить задуматься? Простая инверсия данных советов не даст рецепта «как писать хайлоад-приложения».
В разработке действительно больших и сложных систем нет серебряных пуль. А вопросы когда лучше докупить сервер, а когда заняться оптимизацией вообще каждый раз решаются отдельно, и далеко не всегда понятно, что окажется рентабельнее в долгосрочном плане.
В разработке действительно больших и сложных систем нет серебряных пуль. А вопросы когда лучше докупить сервер, а когда заняться оптимизацией вообще каждый раз решаются отдельно, и далеко не всегда понятно, что окажется рентабельнее в долгосрочном плане.
Сбербанк пользуется данными советами уже давно.
Опять mail.ru со своими докладами!
Sign up to leave a comment.
Проектирование высокопроизводительных систем: о чем не расскажут в книгах