Попытайтесь повторить это сами

Как правило, настроенный должным образом сервер Nginx на Linux, может обрабатывать 500,000 — 600,000 запросов в секунду. Но этот показатель можно весьма ощутимо увеличить. Хотел бы обратить внимание на тот факт, что настройки описанные ниже, применялись в тестовой среде и, возможно, для ваших боевых серверов они не подойдут.

Минутка банальности.

yum -y install nginx

На всякий пожарный, создадим бэкап исходного конфига.

cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.orig
vim /etc/nginx/nginx.conf

А теперь можно и похимичить!

Спасибо за статью habrahabr.ru/post/191210! Хорошую тему подняли.

Поделюсь и своим опытом. Ниже — идентичное содержание и первой, и заключительной лекции в программе подготовки стажеров.

В программировании, помимо ЭВМ, методик и софта с разных сторон, есть еще такой ключевой элемент, как программист.

Почему он самый главный? Потому что, как знают многие, большую часть решений можно создать без ЭВМ, без методик и без софта – карандашом на бумаге или вовсе в воображении. А без программиста создать программу нельзя. Потому что он, программист, как раз программу и создает.

О программисте, как о решающем факторе, и о его мозге, как об основном инструменте, мы сейчас поговорим.

картинка для привлечения внимания

4 года назад несколько человек добились возможности возврата ОС.

Однако воз и ныне там:

• по прежнему за счёт одного товара — ЭВМ, продвигается другой товар — право на использование программного обеспечения (ПО), заметьте не само ПО является товаром, а именно право им пользоваться;
• процедуры возврата этого «права пользоваться» трудоёмки, неудобны или вовсе не выполняются;
• процедур отказа от приобретения этого «права пользоваться» — не существует;
• лицензионные соглашения на ПО, по сути, являются договорами аренды, в которых не декларирована стоимость «права пользоваться»;
• Microsoft и другие поставщики ПО прячутся за коммерческую тайну при заключении договоров с поставщиками ЭВМ.

Известно что строку статуса в Vim можно легко кастомизировать в соответствии с вашими пожеланиями: вывести информацию о текущем файле, позиции курсора, текущей vcs-ветке. Есть также отдельные плагины, которые полностью заменяют строку статуса, самым используемым из которых является vim-powerline. В данной статье я хочу познакомить вас с одним из таких плагинов, vim-airline, который я с недавнего времени использую вместо vim-powerline.

Во многих западных странах IT-аутсорсинг регулируется либо отраслевыми стандартами, либо вообще на госуровне. У нас такого нет. Поэтому за несколько лет был собран документ, который детально определяет термины в IT-аутсорсинге и расписывает, что в какой тип работ конкретно входит. С его помощью мы документируем работы, а потом чётко и прозрачно считаем, что сколько стоит.

Вот глоссарий терминов, а вот каталог IT-услуг. Эти документы можно свободно скачивать и использовать. Особенно рекомендую руководителям IT-подразделений.

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

Это интервью – третье из серии наших интервью с техническими руководителями проектов OpenStack, размещённое в блоге Мирантис. Нашей целью является просвещение компьютерного сообщества в вопросах, связанных с проектом OpenStack. Ответы на эти вопросы предоставляет сам опрашиваемый. Интервью публикуется с купюрами в связи с ограничением длины статьи.
Итак, это интервью с Джоном Гриффитом, техническим руководителем проекта OpenStack Cinder.

По роду занятий я часто общаюсь с различными русскими и западными командами. Очень частый вопрос — есть ли какая-нибудь специфика в работе наших и как это влияет на разработку?

Есть очень неплохая книжка о специфике работы русских вообще. Она называется «Русская модель управления». Ее написал А.П.Прохоров (другой, не олигарх). Не буду ее пересказывать. Основная идея в том, что русские по своей природе могут работать только в двух модах. В нестабильном состоянии они могут свернуть горы. В это время мотивация очень высокая. В стабильном расслабленном состоянии — когда никто не пинает — русские вроде как работают плохо и не сильно утруждаются.

Книга замечательная и действительно многое объясняет в нашей истории. Обязательно прочтите, если не читали. Но я не готов ее рекомендовать как непосредственное руководство к действию. Выводы из нее следуют довольно-таки однозначные и не очень лестные для страны в целом. Однако на самом деле все не так плохо. Наша специфика не является абсолютно контрпродуктивной. Она дает и преимущества и недостатки.

Еще один дисклеймер: на реальное поведение людей действует сложившаяся культура в а) команде б) организации в) стране. Причем именно в этом порядке. Есть «прозападные» компании, где влияние наших культурных кодов очень небольшое. В чисто российских компаниях оно просто огромно. Но реально заметить разницу можно только увидев, как различные культуры сталкиваются друг с другом.

Я буду приводить влияние разных факторов в порядке их важности и силы влияния. Чем выше — тем сложнее это изменить и тем больший эффект это оказывает.

Эта статья выросла из идеи продвинутого обучения наших сотрудников технической поддержки работе с mod_rewrite. Практика показала, что после изучения имеющихся в большом количестве учебников на русском языке саппортам хорошо дается решение шаблонных задач, но вот самостоятельное составление правил происходит методом проб и большого количества ошибок. Проблема заключается в том, что для хорошего понимания работы mod_rewrite требуется изучение оригинальной англоязычной документации, после чего — либо дополнительные разъяснения, либо часы экспериментов с RewriteLog.

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

Я предполагаю, что читатель уже знаком с тем, что такое mod_rewrite, и не буду описывать его основы, которые легко найти в интернете. Также нужно отметить, что в статье освещается работа mod_rewrite при использовании его директив в файле .htaccess. Отличия при работе в контексте <VirtualHost> изложены в конце статьи.

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

Почему так происходит?

Вот некое простое значение:


И мы знаем, как к нему можно применить функцию:


Элементарно. Так что теперь усложним задание — пусть наше значение имеет контекст. Пока что вы можете думать о контексте просто как о ящике, куда можно положить значение:


Теперь, когда вы примените функцию к этому значению, результаты вы будете получать разные — в зависимости от контекста. Это основная идея, на которой базируются функторы, аппликативные функторы, монады, стрелки и т.п. Тип данных Maybe определяет два связанных контекста:

data Maybe a = Nothing | Just a

Позже мы увидим разницу в поведении функции для Just a против Nothing. Но сначала поговорим о функторах!

— Ты все еще не бросил свое Ruby? – взволновано спросила Татьяна. – Ты же знаешь, что сейчас на программистов облавы чуть ли не каждый день? Сергей, ты действительно хочешь, чтобы тебя отправили в ЗАТО?

Сергей понуро молчал.

После Большой свободной революции и полной победы антикопирастов, ЗАТО – закрытые абстракто-творческие общества появились по всей стране.



Сначала туда свозили только людей творческих профессий – писателей, композиторов, художников. Затем принялись и за программистов. Благоустроенные бараки, двухразовое полноценное питание, обязательные спортивные мероприятия, помогающие держать форму…

Несмотря на предсказанный рост производительности, качество художественных произведений снизилось, поставив под угрозу интересы главной фигуры любого творческого процесса – ПОТРЕБИТЕЛЯ. После длительных дебатов в парламенте, правительство было вынуждено пойти на крайние меры – была введена система «мотивирующих воздействий». Если созданное произведение не набирало норму лайков – всей бригаде урезали паек, а систематический саботаж творческой выработки мог привести к переводу в лесорубы.

Недавно я слушал по радио передачу об эволюции альтруизма. Обсуждался вопрос о том, каким образом «ген альтруизма» выдерживает естественный отбор. Это обсуждение навело меня на мысли о том, какие функции должны присутствовать в современных сетевых приложениях, чтобы они «выживали» в естественном отборе.

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

Согласно письму, зловред проник в сеть компании через дыру в системе мониторинга Nagios, и поражал запущенные процессы веб-сервера Apache и sshd (терминал), при этом не изменяя сами бинарники, что и позволило бреши столь долгое время находиться незамеченной. По словам техников, ничего подобного им раньше не попадалось.

Для оценки произошедшего была нанята отдельная секьюрити-компания, которая помогает местным администраторам разобраться в произошедшем, и полностью вычистить сеть от всех копий зловреда. Все компетентные органы были оповещены, расследование на данный момент еще не завершено.

Вольный перевод статьи на тему приватности переписки в Skype.

Все, кто использует Skype, обязан согласится с пунктом, что компания может читать все, что там пишут (смотри Положение о конфиденциальности в Skype). Компания Heis, совместно с немецкими коллегами, выяснила путем простейшего эксперимента, что Microsoft активно использует эту возможность, но очень странным образом.

Практически сразу после отправки сообщения в Skype, в котором содержалась ссылка на некий https ресурс, данный ресурс был посещен с IP, принадлежащего Microsoft HQ в Редмонде, США.

UPD: Статья дополнена предположениями о возможной причине произошедшего. Опубликовано 17 Мая 2013 на The-H-Security.

Эпоха путешествий во времени еще не наступила, а человечество уже давно пытается разрешить сопутствующие им парадоксы. Мы поговорим о самом очевидном из них: что же все-таки произойдет при вмешательстве в ход истории? Существует несколько вариантов того, как поток времени реагирует на действия путешественника из будущего. Эти модели можно увидеть в фантастических фильмах, о них все больше начинают говорить ученые, но какая модель ближе к истине — единого мнения пока нет. Мы только начинаем проникать в тайны времени, и еще не обладаем возможностью экспериментировать с перемещениями в прошлое. Что же можно прояснить в данном вопросе уже сейчас? Под катом нас ждет экскурсия по основам механики времени, мы порассуждаем о парадоксах, и проведем небольшой эксперимент. Да, это будет испытание виртуальной машины времени, построенной на основе алгоритма «Жизнь»!

Исследовательская компания Gartner хорошо известна на рынке аналитики информационных технологий. Я бы даже сказал — является одним из лидеров этого рынка. Ежегодно она выкладывают крайне интересный график, именуемый «Цикл зрелости технологий» (в англ. Hype cycle, или дословно – «цикл шумихи»). На этом графике, в хронологическом порядке, разложены технологии, которые либо уже готовы к применению, либо только-только вступают в стадию исследований.

Вот так выглядит график на 2013 год (выполнен по состоянию на июль 2012 года):


Итак, график делится на пять частей. Первая – «технологический триггер». Т.е. то время, когда технология только-то начинает свое существование (хотя бы в виде идеи). Этап второй – «пик завышенных ожиданий». Т.е. период времени, когда о технологии начинает узнавать общественность. На вершине этого пика о технологии говорят все и на каждом углу, и даже бульварная пресса начинает писать об этом как о почти свершившемся факте. Дальше следует «пропасть разочарования», т.е. то время, когда оказывается, что в реальности технология позволяет делать совсем не то, что от нее хотели. Из этой пропасти выбираются далеко не все. Ну и следом идет «склон просвещения» и «плато продуктивности», по сути – последние этапы перед массовым внедрением.

Сегодня хочу опубликовать материал, который мы подготовили еще в прошлом году. Однако, по ряду причин, он пролежал на полке. Речь о том, как мы запускали в воздух 20-ти литровую бутыль от кулера при помощи воды и автомобильного насоса. Подобное уже кто только ни делал. Но одно дело — посмотреть, а другое — попробовать самим. Занятие оказалось весьма увлекательным и четыре часа пролетели незаметно. Всем рекомендую на майские праздники ;)

Теперь подробнее о самом запуске.

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

Все команды Vim нужно вводить на английском языке. Если основной текст вводится на каком-либо другом языке, то это представляет из себя проблему, т.к. нужно часто переключать раскладку. Одно из решений представлено тут, однако оно заставляет привыкать к новой горячей клавише для переключения раскладки. Так же существует множество платформенно-зависимых решений с вызовом тех или иных утилит. Целью плагина vim-xkbswitch является предоставить единое поведение для многих операционных систем и языков.

FailOver Conference состоится уже завтра, 4 апреля! Мы сами ждем это мероприятие с огромным нетерпением, потому что работа над программой уже завершена и в нее попало только все самое «вкусное»! :-)

Самое «горячее» специальное предложение для тех, кто не сможет присутствовать лично — бесплатная онлайн трансляция всего мероприятия!

Можно будет не только посмотреть все доклады, но и задать интересующие вопросы через твиттер с хэштегом #failoverconf.

Для этого требуется самая малость — зарегистрироваться на онлайн трансляцию.

А под катом мы расскажем о наиболее интересных, на наш взгляд, докладах!

Не секрет, что разработчикам программных систем часто приходится решать проблемы производительности, высокой нагрузки, обработки больших объемов данных и отказоустойчивости. В идеале, все эти вопросы учитываются при проектировании системы. Но на практике их часто пытаются решить запоздалыми «оптимизациями» после запуска.

Почему так происходит? Обеспечение высокой производительности и надежности ошибочно почитается многими за «черную магию». И неспроста — чуть ли не в каждой книге или статье на эту тему вы первым делом наткнетесь на утверждение типа «нельзя просто так взять и повысить производительность».