Довольно много времени прошло после моей последней статьи про nginx под windows, неделя nginx закончилась. Стоит поправить это упущение.

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

После небольшого разбора и оценки в сравнении с результатами предыдущего анализа, заметил одну странность — абсолютная скорость отдачи nginx упала в среднем от 5 до 15%.

Объяснить, чем это вызвано с налету никак не удавалось, больших изменений вроде не было, объемы данных тоже настолько не выросли. Да и на отдаче динамики сильных изменений не много.

Покрутив логи и так и сяк, зацепился за отдачу маленькой статики — выяснилась одна закономерность: чем длиннее путь (url) — тем «медлительней» становился nginx (независимо от размера файла).

Итак после нескольких экспериментов, имеем следующие факты:

• скорость отдачи падает прямо пропорционально увеличению длины пути до файла
• скорость практически не зависит от длинны URL, т.е. если URL короткий, но увеличиваем длину root/alias, скорость отдачи падает также, т.е. это все-таки длинна пути, а не URL
• ну и наконец, поиграв с путями файла, а именно его вложенности, выяснилось, что скорость отдачи падает в зависимости от количества поддиректорий, и не зависит от длины как-таковой. Т.е. файл «D:\...\ms-ms-ms-ms-ms-ms-ms-ms\test.gif» отдается много быстрее «D:\...\ms\ms\ms\ms\ms\ms\ms\ms\test.gif»

И тут пришло озарение — я вспомнил, что в этом проекте изменилась файловая структура, и вложенность до некоторой статики и динамики отдаваемой файлом (по redirect) увеличилась на два-три, а местами до пяти каталогов.

Читать дальше →

Мы привыкли видеть истории проектов с миллионами клиентов и целым парком серверов, но разные интересные и курьезные ситуации могут встречаются и на относительно небольших проектах. Одна из них произошла недавно. Однажды работающий нормально сервер вдруг начал случайным образом тормозить…


А ведь ничего не предвещало беды...

Пожалуй главным отличием конференции разработчиков высоконагруженных систем HighLoad++ от многих других является отсутствие скрытых целей. За нами не стоит ни одного лица или организации, которая бы навязывала правила игры или занималась хантингом на мероприятии, типа:

• Крупной компании
• Толстосума-спонсора
• Государственных структур

Уже долгие годы HighLoad++ остается событием, которое одни разработчики организуют для других разработчиков.

Девять лет назад мы приняли для себя несколько строгих правил, которым стараемся неукоснительно следовать. Не будем перечислять их все — для этого еще придёт время, назовем лишь основные.
Читать дальше →

Предисловие

Нижеследующий текст − результат практического опыта и самообразовательных порывов человека, не имеющего систематического образования ни в одной из областей, о которых он (то есть я) берётся рассуждать. Поэтому заумные рассуждения здесь будут перемежаться банальностями. Бейте меня за первые и игнорируйте вторые. Для кого-то и они могут стать откровением.

Я постараюсь описать идеальные варианты настройки тестового веб-севера, хотя понимаю, какой бардак на них обычно творится. Буду ориентироваться на ситуацию, когда деплоить приходится часто, то есть на сервере живёт проект в стадии активной разработки либо несколько проектов на разных стадиях. Проектами занимаются разные разработчики или команды, поэтому проекты нужно изолировать друг от друга. Но сервер внутренний, поэтому такая степень изоляции и автоматизации процессов администрирования, как на серверах под сдачу в аренду, не нужна.

Основной упор я буду делать на применение разных версий Python в качестве языка поддерживаемых веб-приложений. Хотя многие вещи наверняка будут справедливы и для других языков, например, Ruby или Perl.
Читать дальше →

Крупнейший российский регистратор и хостинг-провайдер REG.RU вводит проверку и лечение сайтов от вирусов и угроз при помощи Вирусдай.Сервер. Напомним, что Вирусдай.Сервер — это серверный антивирус для хостинг-провайдеров, разработанный компанией Вирусдай для замены менее эффективных антивирусных утилит и обладающий большой полнотой и точностью детектирования вредоносного и опасного кода в файлах веб-сайтов. Читать дальше →