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

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

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

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

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

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

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

Итак, для тех кому это интересно, расскажу об составляющих частях этого проекта.

Статья написана по материалам моего доклада на CodeCamp 2009.

Для многих из нас настает тот долгожданный день, когда аудитория сайта начинает стремительно расти. Каждое утро мы, затая дыхание, смотрим на графики google analitycs и расплываемся в улыбке, когда взят рубеж в очередную тысячу посетителей в день. Как правило, рост посещаемости не совпадает с ростом технической базы и сайт начинает тормозить. Тут в игру вступает сисадмин...

У любого проекта всегда есть что оптимизировать: можно почитать советы по оптимизации на webo.in, установить eaccelerator, memcache, проиндексировать поисковые поля в базе данных. Я предполагаю, что все это уже проделано, а сайт по прежнему тормозит.

Пришло время оптимизировать nginx...

Вступление

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

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

Моя первая статья, не судите строго...

Приветствую вас, уважаемые хабрадевелоперы!

Многие из вас знают о прекрасном легковесном веб-сервере nginx.
Некоторые также знают, что он умеет работать с memcached.
Но лишь немногие в курсе, при чём здесь SSI и как его можно использовать в связке с nginx и memcached.

Как известно, новое — это хорошо забытое старое. Каждый названный инструмент и технология вам наверняка известны. Я же хочу рассказать о том, как и зачем свалить всё это в одну кучу :)

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

1. Обязательно прописывайте обратную зону для своего почтового сервера (ptr record). Это не так сложно сделать. В большинстве случаев достаточно написать вашему интернет провайдеру. Далее либо он сам пропишет в своих dns, либо делегирует вам вашу зону (in-addr.arpa).
2. Старайтесь держать в актуальности соответствие PTR записи с A, на которую указывает MX запись.
3. Используйте fqdn в приветствии HELO/EHLO
4. Проверьте, что не используете openrbl.org в списках RBL. Этот сервис давно закрылся и блокирует всех адресатов.
5. Включите позможность работы по защищенному tls соединению. Пусть даже с самоподписанным сертификатом, но у которого стоит корректное common name, совпадающее с вашей PTR записью. Используйте как SMTP over SSL так и submission сервисы.
6. Не запрещайте в своих почтовиках DSN (delivery status notification), они значительно позволяют упростить решение возникающих проблем.

Это совсем кратенькие советы, но исходя из своего опыта работы, выдерживают их не более 30% почтовых серверов на просторах СНГ.

P.S. Если потребуется, напишу как реализовать это применительно к postfix.

Продолжаем ставить Xen на Ubuntu.
Часть первая

Так исторически сложилось, что домены сайтов называют с префиксом www или без.

Есть несколько взглядов как истинно должен называться домен, прогрессивное человечество считает, что без www — nowww.ru, многие западные эксперты считают обратное.

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

Вчера столкнулся с небольшой проблемой — на машине с Win2k3 установлены 2 сетевых карты, 2 провайдера. Проблема оказалась следующая: подсети пересекаются (точнее — совпадают). Было решено использовать за основной шлюз 1го провайдера, а по внутрисетевым ресурсам гулять — через 2го. И всё бы ничего, но машина должна обслуживать входящие соединения с обоих интерфейсов. Но, благодаря статическим маршрутам, ответы на запросы из подсети 10.0.0.0/8, пришедшей со стороны первого провайдера уходили через канал второго провайдера, что было, мягко говоря, не тем, что нужно. Как решить эту проблему под линухом — я знал (и тоже поведаю в этой заметке). Немного погуглив был найден вариант решения (в msdn'e наткнулись на управления приоритетами соединений). Коллега (WAJIM, привет) подумал — и нашёл 2й вариант. Потом немного (совсем немного) подумал я — и по аналогии появился 2й вариант решения для линуха :)
Итого, под катом вас ожидает 4 варианта решения задачи маршрутизации по 2м провайдерам — 2 под виндовс и 2 под линукс.

FreeBSD, сетевая Intel fxp, порт 100Мбит, polling, http accept-filter
в sysctl:

sysctl kern.maxfiles=90000
sysctl kern.maxfilesperproc=80000
sysctl net.inet.tcp.blackhole=2
sysctl net.inet.udp.blackhole=1
sysctl kern.polling.burst_max=1000
sysctl kern.polling.each_burst=50
sysctl kern.ipc.somaxconn=32768
sysctl net.inet.tcp.msl=3000
sysctl net.inet.tcp.maxtcptw=40960
sysctl net.inet.tcp.nolocaltimewait=1
sysctl net.inet.ip.portrange.first=1024
sysctl net.inet.ip.portrange.last=65535
sysctl net.inet.ip.portrange.randomized=0


Вопросы резервного копирования никогда не утратят свою актуальность. Это то, без чего не возможно представить ни одну информационную структуру. Сегодня мы поговорим об on-line способе создания резервных копий.

Едва ли кто-то ещё не знает, что такое спам и не имеет желания от него избавиться. У тех, кто при этом является «хозяином» корпоративного почтового сервера, наконец-то, появилось более менее эффективное средство от спамеров.

В виду достаточно большого парка серверов/свитчей/модемов и иного активного оборудования в конторе, была установленная система мониторинга zabbix и успешно использовалась продолжительное время. Zabbix имеет замечательную возможность отправки уведомлений о возникших проблемах.
Для этого был написан скрипт отправки sms сообщений через шлюз email-to-sms оператора связи, ограничение по количеству смс с одного адреса в сутки было обойдено путем ротации исходящих адресов, работало более или мение сносно, но в последнее время смс сообщения через данный шлюз начали доходить с задержкой порядка 10-15 минут, что уже не очень нравилось.
Итак, было решено организовать отправку уведомлений через собственный GSM-терминал, порывшись в прайсах поставщиков и не обнаружив там подходящих по цене и характеристикам GSM модемов весьма огорчился.
И тут вспомнилось что дома валяется старый Siemens CX65 да еще и data-кабель к нему, после подключения телефона и курения доков по отправке sms сообщений пришел к не очень радостному выводу, оказывается siemens не поддерживает отправку sms в текстовом режиме, команда AT+CMGF=1 возвращает error.
Отправка сообщений в данных аппаратах возможна только в режиме PDU, ради спортивного интереса и для размятия мозгов было решено реализовать эту систему, был написан скрипт для перекодировки в PDU формат сообщений и отправки через телефон.

Настало, наконец, время вернуться к теме пакетирования в Debian и Ubuntu.
Начну я с оправданий. Причиной долгой паузы, между четвертой и этой частью была не моя лень, не диплом, который я никак не допишу, и даже не положение звёзд, а уже упомянутый мною в предыдущих статьях (раз, два, три, четыре) досадный баг в одном из пакетов Debian. Как я, наконец, понял, скорого исправления этого бага ждать не стоит, поэтому я предлагаю тем, кто уже освоил сборку пакетов, изучить интересное средство, облегчающее как тестирование вашего пакета, так и сборку его под разные архитектуры — pbuilder.

Ранее здесь была представлена статья о том как сделать вертикальный текст картинками, генерируемыми php.

Теперь я хочу вам рассказать о том как сделать поставленную задачу без картинок, флеш и js, только средствами html и css. К тому же стало возможно сделать текст под произвольным углом. В конце статьи есть готовый пример.

Представляю вам mctop — продвинутую консольную утилиту мониторинга состояния memcached-серверов.
Забрать можно по адресу — code.google.com/p/mctop

Так уже получилось что писал статью для howtoforge. И естественно тут же все это оказалось в русском варианте на других сайтах. Только вот незадача: в статье были допущены неточности, и публицисты с других «сайтов» вставили as-is.
Хочу попробовать исправить это оплошность.
Для чего это надо?
Объясню на примере: был у меня фтп с 2мя сетевыми картами, но использовалась одна. Со временем весь 1Гб/с начал забиваться по вечерам — и людям плохо, и у меня iowait растет. Но есть вторая сетевая карта. Так вот такое объединение позволит использовать 2 (3, 4, 5...) как одну с 2Гб/с.