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

Вы нас с кем-то перепутали, наверное. Мы нигде не сказали что программер должен выдумывать ТЗ.

Вы наверняка нас с кем-то путаете. Мы не приписывали программерам функции планировщика.

Вы точно нас с кем-то путаете.

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

Вот когда разговор зайдет в "Деловых вопросах" об "оптимизации расходов на содержание сайта", тогда там будут более чем уместны ремарки о том, что сервера надо не оптимизировать а покупать, скрипты надо переписывать с нуля а не оптимизировать, а платформу нужно менять а не настраивать.

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

Ставить кластер. Если сайт может быть на одном сервере - о нагрузке рано говорить

Читал читал этот тред.. и почему народ начал уходить от темы всё больше и больше с каждым сообщением.

Понял, что совершил тут такие ошибки.

1. Разместил не в том разделе тему

2. Забыл упомянуть очень важную вещь в своём первом сообщении. :)

Я статью пишу в помощь хостерам виртуального хостинга. Для того, чтобы админы не писали одно и тоже в своих форумах по поводу многочисленных вопросов на подобную тему, а предлагали к прочтению такую статью.

Всё мною перечисленное относилось только к виртуальному хостингу.

То-то и смотрю, что говорим мы на "немного разных языках" :) Я придерживался одной концепции, Вы другой, поэтому и получился такой "разнообразный" :) разговор.

:)

1. Много ли школ сейчас изучают MySQL, PostregreSQL, PHP, Perl, CGI?

Очень хотелось бы, чтобы в моих учебниках по информатике были бы хотя бы какие-то упоминания об этом. Здесь Вы явно загнули.

2. Ваш набор мыслей интереснее в случае не виртуального хостинга. В условиях виртуально это всё "сложно применимо", если вообще возможно.

Но это моя невнимательность.

Зато получился отличный обзор по поводу нахождения узких мест на серваках :) Который несомненно поможет администрированию серверов начинающим пользователей.

Тема получилась очень даже информативная.

На dedic.ru я как админ некоторых виртуальных хостингов указывал ряд заметок. Прежде чем писать - почитайте.

потом кончается место в стойке или начинается нехватка питалова в ДЦ и опять думаем как быть дальше...

Верну к теме.

Прежде всего программист должен внимательнейшим образом изучить RFC, а администратор особенности серверной ОС и программное обеспечение. Не просто так, мануалы почитать, а еще и внимательно просмотреть исходный код. За живое тема просто задевает, т.к. всегда на шаг впереди, а то и на десять. Это не просто так, sql запросы оптимизировать, оно порой бывает и так оптимально все, но из-за самой задачи оптимизация заходит в тупик.

Вот стата в нашем seo модуле под vbulletin, она собирается insert-ами в несколько табличек... по четным периодам в одну, по нечетным в другую. Следовательно когда одна таблица отдыхает, то её обрабатывает, агрегирует и чистит - лучше не придумаешь. А что будет, если mysql не будет справляться с потоком записи? Ну и... ну и... ну и будем писать в fifo, на fifo сборщик/агрегатор и репорты в таблички, неспешно причем - лучше не придумаешь.

Пример - боремся с медленными клиентами. Алгоритм тупой - если у нас все на GET запросах, то на freebsd врубаем accf_http и рестартуем апач, смотрим зацепил ли он его и идем спать. Если кому-то интересно, почему под все остальные методы кроме GET я рекомендую ставить nginx, то идем в сорцы accf_http модуля и смотрим принцип его работы. Как только он видит что-то отличное от GET или HEAD, то он пропускает это сразу, т.е. идет выделение ресурсов для обработки запроса, а запроса, по сути, еще нет.

В данном случае мне приятно на низком уровне это все пояснять, т.к. по этой теме мы давим на всю ивановскую... следовательно accf_http для ресурсов с POST запросами, т.е. к примеру фотогалереи посещаемые и т.д., не является 100% решением. Что у нас происходит на самых низах - приходит куча клиентов с мобильников, с диалапов, да и просто с меговыми фотками и дальше все они занимает один "слот" на нашем веб сервере. Лимит на нашем сервере, к примеру, 200 одновременных подключений. 200 медленных закачек и все, приехали, остальные запросы в очередь, если пик продолжается, то все успешно накапливается пока не сдохнет.

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

Программист все хорошо продумал, все замечательно, в локальных кэш-ах браузера все хорошо кэшируется, нагрузка спадает на 70%, реальная цифра. Причем нагрузка по количеству приходящих запросов.

Заказчику стукает в голову добавить динамики какой-то. Как делать правильно, что бы потом не думать - динамику выносим во внешний жабаскрипт, который персонифицирует страницу под посетителя. Кто-то скажет, что это два запроса. Ответ: два запроса в одном tcp соединении - раз, количество залогиненных юзеров можно легко подрезать - два, основная масса по прежнему кэшируется - три, появление страницы в разы быстрее - четыре, юзера довольны - пять, оптимизация поисковая никак от этого не страдает - шесть.

И вот, что бы этим всем профессионально заниматься, надо читать доки, изучать исходники серверного ПО и выбирать оптимальное решение. То, что порой бывает описываю, грозит только проектам с 2-3 тыс конектов одновременно и наплывом в 300-400 новых запросов в секунду. WAP один чего стоит...

Ответ на Ваш вопрос один: обратитесь к профессионалам.

kostich, решпект. Запостил в блоге.

Кстати, раз знающие люди заглядывают в это топик, есть вопрос.

Бот по расписанию ползает по сайтам. Урлы из базы берет. При этом ежели нет 200 или 301 - пропускает. Но бывает так, что 200 есть, а толку нет. Как бороться? Чтобы бот не вешал mysql? Ибо все это происходит в цикле? Заголовки с ответами серванта беру через get_headers(), в прочем это и не важно. Сервер виртуальный...

Не до конца поняли вопроса, но.. бот ползает Ваш?

1) Что значит "толку нет"? 200 пришло, но сервер контент не отдает или отдает медленно? Для этого есть тайм-ауты. Если Вы не файловыми функциями грабите контент урлов (а делать это файловыми функциями это ужасная идея, хотя мы видели это в очень многих грабберах и некоторые биржы ссылок не то что implode('',file советуют, а даже иногда include(" что нас вообще в ужас приводит).

2) Зачем вообще get_headers делать? Если Вы всё равно граббер потом запускаете? Если php и urls, то мы предпочитаем http://php.net/curl , сойдет http://php.net/stream или если уж если совсем плохо с хостингом, то http://php.net/fsockopen

3) У нас нередко душа лежит к тому, что бы не запускать php для граббинга сайтов (хотя грешим и таким нередко, ибо удобно часто). Кидайте на php в файл нужные списки для граббинга. И запускайте wget обычный по крону, что бы он брал урлы из созданного на php файла и собирал их. А на php потом можно результат собранный обработать, опять же по желанию - по крону.

Делаем geo кластер :)