О сайтах и не о сайтах

Расширения конфигурационных файлов в Apache 2.4

Понятное дело, что сейчас каждый первый сидит на Apache 2.2, но т. к. последняя стабильная версия на сегодня уже Apache 2.4, то обновиться рано или поздно придется. Про сам Apache 2.4 и список нововведений можно почитать на официальном сайте, однако некоторые действия, которые облегчат будущий апгрейд, можно начать предпринимать уже сейчас.

В версии 2.4 все конфигурационные файлы должны заканчиваться расширением .conf, что касается в том числе и файлов виртуальных хостов, находящихся в директории /etc/apache2/sites-available/, в то время как Апач 2.2 разрешал именовать эти файлы по любому, хоть examle.com или example.com.kekeke.

Соответственно, сменив сейчас названия файлов виртуальных хостов с общепринятого шаблона site.com на site.com.conf мы никоим образом не повлияем на стабильность работы текущей версии Апача, однако сохраним себе нервы при будущем обновлении до 2.4 (и пусть это будет только через год или даже два), ведь такая мелочь, как обязательное расширение .conf может запросто выпасть из головы, подарив пару часов нервного чтения документации и попыток поднять почему-то упавшие сайты.

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

Делается сиё следующими командами (для примера site.com):

sudo a2dissite site.com
sudo service apache2 reload
sudo mv /etc/apache2/sites-available/site.com /etc/apache2/sites-available/site.com.conf
sudo a2ensite site.com.conf
sudo service apache2 reload

Комментарии

Зачем апач, когда есть nginx + php-fpm? (.htaccess для стандартных вещей типа wp/drupal переносится на ура).

Зачем куча конфов, если можно на одном дефолтном поднять универсальный и отвечать им на все? (когда-то давно делал так на локалке, сейчас примеры плохо гуглятся). Хотя это актуально, если десятки сайтов.

На отсутсвие .conf ругнулся, ага, по привычке назвал просто site.ru) А обновится можно и сейчас, и не парится с именованием.

Алсо, не изучали вопрос с mariadb (форк mysql от авторов mysql после продажи их ораклу)?

Зачем апач, когда есть nginx + php-fpm?

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

Зачем куча конфов, если можно на одном дефолтном поднять универсальный и отвечать им на все?

Чьерт, только минут десять назад об этом подумал :3 Хотя мне так проще, сайтов меньше десятка всего. Но когда буду прикручивать редирект, то скорее всего в один файл две записи для двух доменов воткну, чтобы для домена с одним лишь редиректом не валялось ничего лишнего.

mariadb

Загуглил, ссылочка в серпе фиолетовая, значит читал что-то по теме, но ничего не помню. Здесь также, как с Апачем, наверное. Т. е. зачем, когда и так работает. ИМХО, если куда и смотреть, то в сторону того же PostgreSQL или еще каких объектных БД, т. е. с концептуальными различиями. А так что эта реляционка, что та, если не является бутылочным горлышком, то какая суть разница. ИМХО, кнешно. Ну и личные предпочтения и спортивный интерес как факторы тоже исключать не надо :3 Но мне пока сильно не до этого.

Эээ, так ты что, даже статику nginx-ом не проксируешь? Если много посетителей онлайн (много одновременных запросов), апач тормозит с отдачей контента (или сжирает кучу памяти процессами), что приводит к увеличению времени загрузки страниц. Если проксировать - то вся статика (картинки, js, css) идут через него, генерируя бешенный RPM, а апач работает только там, где есть логика (пыха). Можно совсем от него отказаться, еще шустрее все будет работать, только про htaccess придется забыть (ЧПУ настраивать в конфах nginx).

Пыху тоже можно закешировать через xcache, скрипты один раз компиляются в опкод и сохраняются (в памяти занимают примерно в 10 раз больше места, чем сами скрипты), и при повторном исполнении юзаются уже скомпилированные, не запуская интерретатор. Причем все работет прозрачно и настраивается как тебе надо. Хотя если куча всякого вордпресса, память забивается прилично.

Впрочем, опять таки, если памяти достаточно, а посетителей не так много, то и апач справится. Потестируй через ab. Для меня это само собой разумеещиеся, что топсапа генерит дохера запросов, что блог раздает фотки на 2гб в день. Просто поставь его для начала проксировать, у тебя как раз куча файлов подгружается на каждую страницу.

MariaDB - да, именно фор фан, причем от его замены так же ничего править не надо - phpmyadmin даже работает так же. Но несколько вкусных измений там все так есть. Nosql все равно несколько для иных задач, ковыряйся-не ковыряйся, использовать негде.

Да я не хило прокачал словарный запас и кругозор после прочтения твоего комментария ^_^ В одминстве и всем этом полный ноль на данный момент.

Запасов железа хватает с головой (БД правда частенько падала при 1ГБ оперативки, сейчас 2ГБ и пока ни разу не упала), так что острой необходимости во всем этом нет.

Но разбираться в этом следует, это точно. Вернусь к вдумчивому прочтению комментария как только так сразу, пока для меня это не более чем набор слов. Вебмастер, бдлжад, называется >_<

Хах) Начав плотно работать с настройкой сервера, трудно остановиться =) Особенно когда у тебя 512мб оперативки, на которых полтора десятка сайтов, ежедневно насилуемых гуглоботом, и своё кривоватое поделие, внезапно отжирающее кучу ресурсов.

А какой la? Собственно, я из-за этого парился, хотя у меня затык в БД, и в общем-то, решился только обновлением железа. А уж миграция на nginx + php-fpm уже больше для удобства, надоело по два раза конфы делать для сайтов (вот только перпеписывать 2.2кб htaccess обломало, поэтому на одной vps пришлось оставить).

Тут дело в том, что за часик настройки (даже с дефолтными конфами) можно уменьшить время загрузки страниц вдвое. А если еще и вдумчиво вкурить, что зачем, прикрутить кеширование для сайта... Впрочем, у тебя проблемы с долгой загрузкой нет, так что это уже идет чисто некритичная оптимизация (но ускорение работы сайта лишним все равно не будет - https://twitter.com/Sprytru/status/479875401280684032 )

Начав плотно работать с настройкой сервера, трудно остановиться =)

Этого и боюсь :3

А какой la?

load average: 0.01, 0.03, 0.05
Если это то.

2.2кб htaccess

Избранные произведения Пушкина закомментированные штоле? o_O

но ускорение работы сайта лишним все равно не будет - https://twitter.com/Sprytru/status/479875401280684032

Как-то слишком вкусно выглядит. У меня таких падений не было при смене железа. Значит все-таки стоит этим позаниматься.

Шаред -> VPS (спад в июне):
Изображение удалено.

1GB -> 2GB, HHD -> SSD и еще что-то (на графике последние пять дней):
Изображение удалено. Спад на графике может и не большой, но чисто по ощущениям значительно быстрее стало работать.

load average: 0.01, 0.03, 0.05

Все ОК, ага.

Избранные произведения Пушкина закомментированные штоле? o_O

)) Поддержка старого кода + исключения + фактически роутинг через .htaccess, а не в коде.

Как-то слишком вкусно выглядит. У меня таких падений не было при смене железа. Значит все-таки стоит этим позаниматься.

Ну это только у топсапы, это именно было упирание в потолок ресурсов, при пиках посещаемости. У блога например ничего не изменилось, даже наоборот чуть медленней стал (шаред то был заоптимизирован по самое не хочу хостером), хотя тоже SSD nginx все дела (но тормознутость WP без кеширования никто не отменял).

Тут еще дело в том, что тут в графиках - время загрузки чистых страниц, а пользователи то подгружают еще и кучу графики-файлов. Тут и проявляются хорошие стороны nginx, который умеет разруливать кучу одновременных запросов одним процессом. Но, если памяти хватает, то и апач справится, он на 2 гига процессов 15 может продублировать, главное mpm-prefork корректно настроить

В свое время просил написать пост по этой теме, вроде как. А теперь у меня есть все в комментиках, кекеке :3 Буду хоть знать, от чего отталкиваться при изучении.

Добавить комментарий

Содержимое данного поля является приватным и не предназначено для показа.