Доброго времени суток, %username%!
Ранее я рассказывал о генерации сертификатов с эллиптическими кривыми.
Сегодня я расскажу о том как можно без особых усилий настроить в IIS авторизацию по обычным RSAшным клиентским сертификатам, сгенерировать сертификаты для сервера и клиента. И поможет мне в этом как всегда OpenSSL.
Для того чтобы все работало нам понадобятся минимум 3 сертификата:

1. Корневой сертификат (Certificate Authority или CA). Им будем подписывать все остальные.
2. Сертификат домена (сервера). Им IIS будет проверять клиентов. И наоборот, клиенты смогут проверить подлинность сервера.
3. Сертификат(ы) клиента(ов)

Orchard – это движок блогов с открытым исходным кодом, который разрабатывается фондом CodePlex.org при поддержке Microsoft. Orchard основан на ASP.NET MVC 2 и на данный момент использует .NET 3.5.

Orchard развивается быстрыми темпами и на сегодня поддерживает следующие функции:

• заведение нескольких блогов
• многопользовательский режим
• создание дополнительных страниц
• админка с редактированием основных функций
• темы
• поддержка XML-RPC, постинг в блоги через Live Writer или другое ПО

В этой заметке я расскажу как развернуть блог на базе Orchard самыми минимальными усилиями. Поможет нам в этом Web Platform Installer.

Для успешной установки Orchard вам надо иметь IIS-сервер (в статье рассмотрен IIS 7.5) и установленный .NET Framework 3.5, плюс для упрощения установки мы будем использовать Web Platform Installer 2.0, который интегрируется в панель администрирования IIS.

При переезде с 32-битного (на Core2Quad) Ubuntu на 64-битный (на Athlon 64 X2) Debian оказалось, что все процессы, будь-то PHP или старый добрый Apache2, стали потреблять вдвое больше памяти. Знающие люди подсказали то, о чем сразу не подумал сам — рост потребления памяти обусловлен вдвое большей длиной указателей.

Совершенно справедливо напрашивается вопрос — в чем тогда выигрыш для простого сервера? Было 2Гб памяти на 32-битах, стало 4Гб на 64-битах, при этом сhild-процессов Apache2 в памяти может жить примерно одинаковое количество, потому как на старом сервере один процесс занимал 20Мб, а на новом — все 50Мб.

Парни, через пару дней у меня будет редкая возможность встретиться лицом к лицу с Джастином Грэмом (Justin Graham), старшим техническим менеджером по продуктам Windows Server в Microsoft. Подозреваю, что этот товарищ может рассказать очень многое, но только если ему задать правильные вопросы. И вот беда: сам я в серверных технологиях с точки зрения опытного пользователя мало чего понимаю и посему правильных вопросов у меня нет.

Так что буду очень благодарен за любые более-менее интересные вопросы касательно серверных технологий Microsoft вообще и Windows Server в частности.

Ну а сразу после интервью обязательно опубликую ответы.

Введение

С момента написания мной предыдущей статьи по оптимизации этой связки прошло довольно много времени. Тот многострадальный Pentium 4 c 512Мб памяти, обслуживающий одновременно до тысячи человек на форуме и до 150,000 пиров на трекере уже давно покоится на какой-нить немецкой, свалке, а клуб сменил уже не один сервер. Всё сказанное в ней всё ещё остаётся актуальным, однако есть вещи которые стоит добавить.
Статья большая, так что будет поделена на логические блоки:

0. Зачем вообще что-то оптимизировать?
  
1. Оптимизация ОС (FreeBSD)
  1.1 Переход на 7.х 
  1.2 Переход на 7.2
  1.3 Переход на amd64
  1.4 Разгрузка сетевой подсистемы
  1.5 FreeBSD и большое кол-во файлов
  1.6 Softupdates, gjournal и mount options
  
2. Оптимизация фронтенда (nginx)
  2.1 Accept Filters
  2.2 Кеширование
  2.3 AIO
  
3. Оптимизация бэкенда
  3.1 APC
  3.1.1 APC locking
  3.1.2 APC hints
  3.1.3 APC fragmentation
  3.2 PHP 5.3
  
4. Оптимизация базы данных
  4.1 MySQL 
  4.1.1 Переход на 5.1
  4.1.2 Переход на InnoDB
  4.1.3 Встроеный кеш MySQL - Query Cache
  4.1.4 Индексы
  
4.2 PostgreSQL
  4.2.1 Индексы
  4.2.2 pgBouncer и другие.
  4.2.3 pgFouine
  
4.3 Разгрузка базы данных
  4.3.1 SphinxQL
  4.3.2 Не-RDBMS хранилище
  4.4 Кодировки
  4.5 Асинхронность
  
Приложение. Мелочи.
  1. SSHGuard или альтернатива.
  2. xtrabackup
  3. Перенос почты на другой хост
  4. Интеграция со сторонним ПО
  5. Мониторинг
  
 6. Минусы оптимизации

Для оптимизации движка решил проверить что будет быстрей работать: unserialize + file_get_contents или подключать сгенерированный php файл.
Cериализированый масив занимает 10кб.
Тестирование проводилось для unserialize, подключения файла и получения данных с базы mysql

Данная заметка является шпаргалкой для новичков в установке нормально работающего комплекса, описанного в заголовке. Все пункты установки протестированы несколько раз на разных vds, поэтому проблем с нехваткой чего-то быть не должно, как это обычно бывает, когда ставишь что-то по мануалам, надерганных из разных источников. Подробно описания настроек и «тюнинга» в заметке нет, т.к. это всё очень индивидуально и требует понимания что, как и зачем делается, а это невозможно охватить в одной даже очень большой шпоре.

Зачем всё это? — спросите вы. Да просто захотелось поделиться с общественностью некоторым опытом, полученным в процессе оптимизации vds под нужды одного общеизвестного блого-социального движка, который на обычном хостинге чувствует себя, мягко скажем, некомфортно.

Началось всё с того, что я ушёл от firstvds, где уже ничто не спасёт от тормозов. Ушел на ганди.нет, взял одну шару (1 share), которую дали на месяц бесплатно. Кстати, акция эта (This summer, your server is free!) вроде еще не закончилась. ;) И начал на этой шаре проводить зверские эксперименты с установкой разного ПО. Тестировал результаты с помощью siege.

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

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

Не претендую на гениальность своего решения, но надеюсь, кому-нибудь оно поможет.

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

Недавно проводили тест, результаты которого показали, что одно приложение обрабатывает 2000 запросов в секунду на скромном сервере, где это было не единственной нагрузкой. При этом результат каждого запроса записывается в 3-5 таблиц в MySQL. Честно говоря, меня такой результат удивил, поэтому решил поделиться с хабрасообществом описанием архитектуры этого приложения. Подобный подход применим от баннерных показов до чатов и микроблогов, надеюсь кому-нибудь покажется интересным.

Во-первых, это приложение однопоточное. Всё делается одним процессом, работа с сокетами — неблокирующими epoll/select, никаких ожидающих ввода/вывода потоков (threads). С развитием HTTP, сначала появлением Keep-Alive, затем AJAX и набирающим популярность COMET, количество постоянных соединений с веб-сервером растёт, на нагруженных проектах измеряется тысячами и даже десятками тысяч, и если для каждого создавать свой поток (thread) со своим стеком и постоянно переключаться между ними — ресурсов сервера очень быстро не хватит.

Второй ключевой момент — что один SELECT… WHERE pk in (k1, k2, ..., kN) выполняется быстрее, чем несколько SELECT… WHERE pk=… Выполняя работу с базой данных большими пачками можно уменьшить не только число запросов в секунду, но и общую нагрузку.

Вступление

Забавно, но когда программист разрабатывает какой-либо продукт, он редко задумывается над вопросом могут ли на одну кнопку в один момент времени нажать одновременно 2000 человек. А зря. Оказывается могут. Как ни странно но большинство движков, написанных такими программистами, очень плохо ведут себя под большими нагрузками. Кто бы подумал, а всего один лишний INSERT, не проставленный index, или кривая рекурсивная функция могут поднять load averages чуть ли не на порядок.

В этой статье я опишу как мы, разработчики проекта, сумели выжать из одного сервера с Pentium 4 HT / 512Mb RAM, максимум, держа одновременно 700+ пользователей на форуме и 120,000 на трекере. Да, проект этот — торрент трекер. Предлагаю сразу оставить в стороне разговоры о копирайтах и правах, мне это не интересно, что действительно интересно — это HighLoad.

Всем известно, что развитие технологий идёт по спирали и сейчас мы находимся на новом её витке. Я думаю все слышали и наверняка работали(ют) с так называемыми «серверами-лезвиями»? В этом топике, я хотел бы рассказать вам немного о них, а также какие бонусы этот тип серверов нам предоставляет.

Вообще, сервер-лезвие не представляет из себя ничего нового, с точки зрения архитектуры серверных систем. Грубо говоря, это плотно уложенные 1u в большой коробочке, а в коробочку можно, помимо самих серверов, запихать и другие аппаратные решения в виде лезвий. Вообще, слово лезвие отражает суть сверхтонкости различных аппаратных средств и модулей.