Как уменьшить нагрузку сайта на сервер? (собираем инфу по теме)

Будут работать на порядок (раз в пять-десять) быстрее. Ассемблер даст ускорение ещё раза в два за счёт оптимизации использования регистров. Но узкое место, как Вы верно заметили, обычно не в скриптовом коде.

Ну, мне по сути ближе IIS, и больше говорю о нем. Но и под апачей,.. если даже вынос скриптов под nginx дает результат, то полный отказ от скрипта - и подавно.

CGI , в любом варианте, конечно быстрее, и рессурсоэкономичней, чем любые вариации ASP, но тольок при условии, что никакие объекты ASP не нужны. В противном случае, процесс создание объектной модели сожрет весь выигрыш.

Очень странное развитие топика 🙄

Оптимизация скриптов смысл безусловно имеет и отрицание этого звучит с нашей точки зрения настолько странно, что даже возражения привести трудно. Если вспомнить книжку Брукса про "мифический человеко-час", то становится понятным, почему сразу идеальный и оптимизированный скрипт для рабочего проекта ни один менеджер в здравом уме и твердой памяти заказывать не будет. Кстати, ровно по той же причине зачастую проще докупить еще серверов в кластер, но одно другого не исключает - все должно быть сбалансировано. Если оптимизация позволяет вместо 10 серверов поставить 1 сервер или выдерживать пики нагрузки в 10 раз большие, то с нашей точки зрения, это означает что пора перестать закупать сервера оптом и начать оптимизировать скрипт.

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

Доводы о том, что оптимизация сервера должна выражаться в "включении gzip" для нас тоже звучат очень странно. Ибо "отключенный gzip" (пишем в кавычках, т.к. это относится не только и не столько к этому, а ко всему что упоминалось в данном ранге) для нас, как для программистов, звучит совет ускорить скрипт убрав строку "sleep(5);" в начале скрипта. Эти вещи должны быть сделаны априори. Это скорее не оптимизация, а устранение ошибок или базовая настройка.

Лично мы в рамках топика (и учитывая раздел) хотели бы увидеть советы именно по оптимизации серверов под нагрузку. То есть допустим - как определить узкое место на сервере и догадаться что нужно добавить (проц или память). Как перераспределить приоритеты между процессами (если почта не так важна, а mysql важен). Как определить и настроить нужное для скрипта соотношение лимитов в mysql. Как определить тот момент, когда для статики разумно не только поставить nginx, но и вынести её на отдельный сервер для статики. Как определить куда идет основная нагрузка. И т.д. и т.п. То есть именно не очевидные вещи, которыми надо заниматься индивидуально для каждого конкретного случая. И именно не список "todo", а так же алгоритм самого определения что можно сделать.

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

априори - при создании нового, безрассудство. Использование сжатия имеет смысл, когда возникающая доп.нагрузка "незначительна" по отношению к нагрузке скриптом. Посему, "включать/не включать", тольок после того как подумал + взвесил.

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

Если же изначально писать нормальный скрипт, то еще на этапе планирования сможете сами сказать, какие узкие места возникают, и какио образом их обходить.

Начиная "от печки"

- на чем писать

- стоит ли прикручивать SQL (чаще всего он просто не эффективен, т.к. проектов, где действительно он нужен очень мало)

- как распределять нагрузку от каждого пользователя

и т.д.

Вы себя на МЫ?=)))

Может неточно выразились. Речь о том, gzip мы "оптимизацией" не считаем в принципе.

Естественно. Потому что не видим смысла в чем-то другом если речь об оптимизации. Все равно как на форуме бмв-шников обсуждать как круто кто-то оптимизировал свой кар по разгону включив режим S на коробке передач 😂 Если уж говорим за оптимизацию, то давайте говорить за настройки под трассу и сервис-центр с настройками компьютера кара под условия. То есть ту самую "доработку напильником".

Так в том и проблема, что "от печки" далеко уйти нереально. Да, банальности типа выбора sql или txt решить правильно можно. А вот хоть сколько-нибудь сложные вещи, особенно учитывая что в реальных проектах условия могут меняться, уже не решить. То есть опять же - "использовать gzip" или нет, это решить можно, но оптимизацией это назвать сложно.

См. подпись.

Тогда почитайте, что такое -"планирование проекта"

Если вспомните того же Брукса, то должны знать, что единственный непредсказуемый момент в IT-проекте - это качество и скорость работы разработчиков. Если Вы знаете нагрузку на систему и её распределение, то оптимизировать MySQL можно за два дня, поставить сервер за неделю, вписать в код memcached дней за пять (логика скрипта не меняется), а бизнес-логику с архитектурой переработать - месяца два с учётом полного тестирования и написания скриптов для переноса данных. Уже через месяц ситуация с проектом может быть иная и будет нужен другой уровень оптимизации. Затраты на разные способы оптимизации посчитайте на досуге ;)

Это уже не "планирование проекта" будет, а телепатия или очковтирательство. Покажите нам хоть один нормальный проект, который разрабатывался программистами заведомо гарантирующими увидев ТЗ, что результат их труда выдержит Х хитов +-10% и ни каплей больше/меньше.

К стенке тех программистов которые делают оптимизацию переписыванием всей бизнес-логики и архитектуры. Когда Вы тюнингуете бмв (сорри за возвращение к тому примеру), то тюнинг никак не должен начинаться со слов "ну для начала выкинем этот кузов, двигатель и салони возьмем все от мерседеса". Поэтому мы и хотим увидеть тут мысли по поводу оптимизации, а не по поводу "включить gzip" или "а давайте перепишем весь код с нуля", потому что это все что угодно, но только не оптимизация.

Вот это один из способов оптимизации, из тех, о которых мы как раз и хотели послушать изъявляя своё желание тут в предпоследнем абзаце. Но только не в общих словах, а более конкретно, с алгоритмами или примерами. Что именно крутить, почему и на какие параметры опираться. И не только по отношению к mysql, но и ко всему остальному.

1. В планировании проекта и его реализации участвуют не только программеры, но прежде всего те, кого называют "менеджерами проекта". Программер должен исполнять ТЗ, а не выдумывать его. Вы путаете следвствие и причину.

Ведь это Ваше утверждение... Но при этом Вы приписываете программерам функции планировщика.

Ваш вопрос, как и точка рассмотрения говорит о том, что Вы просто не участвовали в разработке программного проекта от начала до конца в составе группы разработчиков (не путайте с программистами, хотя и они там были).

Оптимизировать что-то может только тот, кто может подняться на "частными" решениями. Можно до хрипа оптимизировать запросы к БД, вместо того чтобы просто сменить платформу или вовсе отказаться от БД или сменить идеологию. Конечно, именно программеры будут это реализовывать, но вектор движения ему задают.