Сложилась ситуация, что участвую в проекте, который работает с достаточно большой нагрузкой. Как уже написал — 36 млн запросов в час. Я много чего прочитал и перепробовал за последний месяц, настраивая сервер; хотелось бы просто сжато и компактно выдать тезисно то, что работает хорошо в такой конфигурации.

Первое, что я заметил — множество советов как все настроить под большую нагрузку. Читайте их внимательно, обычно в тексте найдете, что речь про «высокую нагрузку» в 15-20 тысяч клиентов в сутки. У нас клиентов примерно миллион, активных, ежедневных.

У нас нет денег и мы все делаем за свой счет, поэтому экономим. Итог — весь миллион клиентов обслуживается на одном сервере, вот на таком — EX-60 на hetzner.

Давным давно, в 1902 году, сидят в кустах трое полицейских (с интервалами в 1 милю), у каждого секундомер и телефон. Проносится мимо первого автомобиль, он тут же засекает время и звонит второму, второй делает математические вычисления и звонит третьему, а тот уже останавливает машину. (пруф)


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

Сегодня речь пойдет о приборах для радиоэлектронной борьбы на наших дорогах.
Пока антирадары и радар-детекторы у нас не запрещены, то РЭБ у нас не ведется, но в некоторых странах война идет по полной. Мы же можем только подготовиться.

Радиоэлектронная борьба (РЭБ) — разновидность вооружённой борьбы, в ходе которой осуществляется воздействие радиоизлучениями (радиопомехами) на радиоэлектронные средства систем управления, связи и разведки противника в целях изменения качества циркулирующей в них военной информации, защита своих систем от аналогичных воздействий, а также изменение условий (свойств среды) распространения радиоволн. Wikipedia

Как противостоять тому, кто пытается снять о вас информацию без вашего ведома и как защитить свои «персональные данные» от несанкционированного съема.

Радары, детекторы радаров, детекторы детекторов радаров. О том, какие бывают, как сделать/распилить самому и то и другое.
(Спасибо интернет-магазину fonarimarket.ru за предоставленное оборудование)

От переводчика: Ссылка на эту статью была опубликована в последней официальной рассылке Docker. Думаю, я не один интересуюсь одновременно и Raspberry Pi и Docker (Swarm), поэтому предлагаю вашему вниманию перевод,

В этом посте мы расскажем насколько легко можно установить Swarm на ваших Raspberry Pi и настроить на них Swarm кластер с помощью Docker Machine.

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

Нравится это вам или нет, отрицать распространенность HTML-писем невозможно, также как и переход электронной почты в мобильную среду (более половины всех открытий теперь происходит на мобильных устройствах).

При этом ситуацию с версткой писем сейчас можно сравнить с тем, как обстояло дело в вебе до тех пор, пока веб-стандарты не стали хм… стандартами. Если вкратце — это просто ад для дизайнера.

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

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

Идея для сервиса, как это часто бывает, родилась из неудовлетворенной потребности. Мне часто кто-то скидывает конфиденциальную информацию, например FTP доступы, через незащищенный канал. Если людям, с которыми общаешься часто, еще можно объяснить, что такое шифрование, и какой софт нужно для него ставить, то навязывать свою паранойю случайным собеседникам — дело неблагодарное.

Так появился на свет Otr.to — браузерный p2p чат с OTR шифрованием. Что бы начать общаться, достаточно зайти на главную страницу, скопировать сгенерированную ссылу и скинуть ее собеседнику. Чат начнется как только он ее откроет.

Юнит-тестирование — одна из неотъемлемых частей процесса разработки, и оно становится сложнее и противоречивее, если основная задача Вашего кода — отправлять запросы ко внешним API и обрабатывать ответы. Немало копий сломано о тему, каким должно быть тестирование кода, завязанного на внешних источниках, и где проходит грань между тестированием собственного кода и чужих API.

На этом этапе разработчикам приходится решить, какие запросы отправлять на удалённый сервер, а какие симулировать локально. Существует немало решений как для отправки запросов, так и для их симуляции. В своём посте я расскажу, как сделать и то, и другое на базе HTTP клиента Guzzle.

Однажды столкнулся с задачей: mongoDb использовался как кэш/буфер между backend на Java и frontend на node.js. Все было хорошо, пока не появилось бизнес требование перебрасывать большие объемы за короткое время через mongoDb (до 200 тыс. записей не более чем за пару минут). Для чего не так важно, важна что задача такая появилась. И вот тут уж пришлось разбираться во внутренностях монги…

Моя статья расскажет Вам как принять 10 миллионов пакетов в секунду без использования таких библиотек как Netmap, PF_RING, DPDK и прочие. Делать мы это будем силами обычного Линукс ядра версии 3.16 и некоторого количества кода на С и С++.



Сначала я хотел бы поделиться парой слов о том, как работает pcap — общеизвестный способ захвата пакетов. Он используется в таких популярных утилитах как iftop, tcpdump, arpwatch. Кроме этого, он отличается очень высокой нагрузкой на процессор.

Итак, Вы открыли им интерфейс и ждете пакетов от него используя обычный подход — bind/recv. Ядро в свою очередь получает данные из сетевой карты и сохраняет в пространстве ядра, после этого оно обнаруживает, что пользователь хочет получить его в юзер спейсе и передает через аргумент команды recv, адрес буфера куда эти данные положить. Ядро покорно копирует данные (уже второй раз!). Выходит довольно сложно, но это не все проблемы pcap.

Кроме этого, вспомним, что recv — это системный вызов и вызываем мы его на каждый пакет приходящий на интерфейс, системные вызовы обычно очень быстры, но скорости современных 10GE интерфейсов (до 14.6 миллионов вызовов секунду) приводят к тому, что даже легкий вызов становится очень затратным для системы исключительно по причине частоты вызовов.

Также стоит отметить, что у нас на сервере обычно более 2х логических ядер. И данные могут прилететь на любое их них! А приложение, которое принимает данные силами pcap использует одно ядро. Вот тут у нас включаются блокировки на стороне ядра и кардинально замедляют процесс захвата — теперь мы занимаемся не только копированием памяти/обработкой пакетов, а ждем освобождения блокировок, занятых другими ядрами. Поверьте, на блокировки может зачастую уйти до 90% процессорных ресурсов всего сервера.

Хороший списочек проблем? Итак, мы их все геройски попробуем решить!

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

Инфографика Inside NGINX сверху вниз проведет вас по азам устройства процессов к иллюстрации того, как NGINX обрабатывает множество соединений в одном процессе. Данная статья рассмотрит всё это чуть более детально.

Как известно, для обработки соединений NGINX использует асинхронный событийный подход. Вместо того, чтобы выделять на каждый запрос отдельный поток или процесс (как это делают серверы с традиционной архитектурой), NGINX мультиплексирует обработку множества соединений и запросов в одном рабочем процессе. Для этого применяются сокеты в неблокирующем режиме и такие эффективные методы работы с событиями, как epoll и kqueue.

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

Каждый процесс расходует память и каждое переключение между ними требует дополнительных циклов процессора, а также приводит к вымыванию L-кэшей

У медали есть и обратная сторона. Главной проблемой асинхронного подхода, а лучше даже сказать «врагом» — являются блокирующие операции. И, к сожалению, многие авторы сторонних модулей, не понимая принципов функционирования NGINX, пытаются выполнять блокирующие операции в своих модулях. Такие операции способны полностью убить производительность NGINX и их следует избегать любой ценой.

Но даже в текущей реализации NGINX не всегда возможно избежать блокировок. И для решения данной проблемы в NGINX версии 1.7.11 был представлен новый механизм «пулов потоков». Что это такое и как его применять разберем далее, а для начала познакомимся с нашим врагом в лицо.

Постановка вопроса

Недавно, во время собеседования в одну крупную компанию мне задали простой вопрос, что такое Load Average. Не знаю, на сколько правильно я ответил, но лично для себя пришло осознание, что точного ответа я на самом деле и не знаю.

Большинство людей наверняка знают, что Load Average — это среднее значение загрузки системы за некоторый период времени (1, 5 и 15 минут). Так же можно узнать некоторые подробности из данной статьи, про то, как этим пользоваться. В большинстве случаев этих знаний достаточно для того, что бы по значению LA оценивать загрузку системы, но я по специальности физик, и когда я вижу «среднее за промежуток времени» мне сразу становится интересна частота дискретизации на данном промежутке. А когда я вижу термин «ожидающие ресурсов», становится интересно, каких именно и сколько времени надо ждать, а так же сколько тривиальных процессов надо запустить, что бы получить за короткий промежуток времени высокий LA. И главное, почему ответы на эти вопросы не дает 5 минут работы с гуглом? Если вам данные тонкости так же интересны, добро пожаловать под кат.

Сначала я и не думал писать статью на эту тему, но похоже, что это уже часть целого цикла статей на Денди-тематику. И да, на этот раз речь в первую очередь именно про отечественную Денди, а не про оригинальные консоли — Famicom или NES. Просто я делал устройство в подарок одному человеку, который снимает очень интересные видеоролики про Денди, и ориентировался на совместимость именно с этим клоном.

Дело в том, что и для Famicom, и для NES выходили самые разные аксессуары: 3D очки, клавиатуры, роботы, считыватели штрих-кодов, всякие игровые контроллеры и очень многое другое. До нас же дошёл только световой пистолет. Передо мной стояла задача собрать устройство, которое совмещало бы в себе разветвитель на четыре игрока (да, были такие игры) и Arkanoid-контроллер.

Mail.Ru — огромный портал, существующий более 15-ти лет. За это время мы прошли путь от небольшого веб-проекта до самого посещаемого сайта рунета. В состав портала входит огромное количество сервисов, у каждого из которых своя судьба, и над каждым из которых работает отдельная команда. Разработчикам пришлось как следует потрудиться, чтобы на всех проектах — и новых, и старых, и тех, которые присоединились к порталу по мере его развития, — использовалась единая система авторизации. А через много лет перед нами встала фактически обратная задача: разделить пользовательские сессии. О том, зачем мы это делали, какие трудности нас ожидали и как мы их обошли, я расскажу в этом посте.

В программировании самокритика – это умение распознать контрпродуктивные решения в дизайне, коде, процессах и поведении. Знание о вредных шаблонах решений полезно для программиста. В этой статье я опишу анти-паттерны, которые я встречал на своём личном опыте время от времени.

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

1 Преждевременная оптимизация

В 97% случаев надо забыть об эффективности малых частей программы: преждевременная оптимизация – корень всех зол. Но в 3% случаев об оптимизации забывать не нужно.
Дональд Кнут

Хотя никогда зачастую лучше, чем прямо сейчас
Тим Питерс, Зен языка Python

Что это

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

Почему плохо

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

Как избежать

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

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

Не хотелось бы, чтобы пост воспринимался в ключе холиваров на тему SQL vs. NOSQL И так понятно что везде есть свои плюсы и минусы, в данном случае это просто где-то немного справки, где-то немного примеров из того, с чем приходилось сталкиваться. Примеры на mongo shell и на python.

1. Миграция в на новые версии в mongodb
   
   • До версии 2.6
   • С 2.6 до 3.0 версии
   • Новое в PyMongo
2. Запросы сравнения и логические
3. Полнотекстовый поиск в Mongodb, regexp, индексы и пр.
4. Атомарные операторы (модифицирующие данные )
5. Немного о транзакциях в Mongodb
   
   • Уникальный индекс
   • Двухфазный коммит
6. Агрегационный фреймворк и JOIN-ы в Mongodb
7. Примеры
   
   • Деревья, комментарии в Mongodb
   • Теги, блоги
   • Е-commerce, и сложные фильтры в Mongodb
8. Небольшая песочница на Python

Команда FlyElephant подготовила свежий выпуск дайджеста, который включает в себя подборку со ссылками на новости и материалы по направлениям: искусственный интеллект, большие данные и высокопроизводительные вычисления. Приятного чтения!

Шифруем всё подряд

Эра незашифрованного веба проходит, и это хорошо. В этой инструкции мы предполагаем, что на вашем сервере работает веб-сервер Nginx. И теперь мы сделаем так, чтобы все посетители сайта пользовались исключительно протоколом HTTPS. Кроме этого мы включим HSTS – это «HTTP Strict Transport Security», когда сайт не только поддерживает HTTPS, но и настаивает на его использовании.

Для этого есть множество способов, но я опишу метод под названием «HTTPS termination». Иначе говоря, мы поставим перед веб-сервером обратный прокси, который и будет обеспечивать HTTPS. Это получается проще и гибче, чем настраивать HTTPS только при помощи возможностей веб-сервера. Возможно, вам покажется контринтуитивным, что добавление ещё одного приложения в стек упростит вашу жизнь – но это действительно так.

Уточним, что данный рецепт подходит для серверов на базе Linux, на которых установлен Nginx.

То, что будет работать прежде всех остальных приложений в стопке – это HAProxy. Это в первую очередь приложение для балансировки – он умеет распределять приходящие запросы между разными физическими серверами. Много высоконагруженных сайтов используют его в этом качестве (тот же reddit), но в последней версии у него появилась возможность выполнять SSL termination. Он умеет устанавливать HTTPS-соединения от имени сервера.

Поэтому мы поставим HAProxy, скормим ему наши сертификаты SSL/TLS, поручим перенапрявлять все HTTP запросы на HTTPS, и покажем ему уже сам веб-сервер в качестве бэкенда.

Задумываясь о разработке html5 приложения, многим сразу на ум приходит jQuery, или точнее jQueryMobile. И попробовав написать даже самое простенькое приложение используя jQueryMobile, очень легко разочароваться, так как производительность и отзывчивость получившегося html5 приложения куда ниже ожидаемого, и уж совсем его не сравнить с нативными приложениями.

Apple HTTP Live Streaming — широко распространенная технология для доставки видео на мобильные устройства, которая делает ставку на простоту, универсальность и проходимость. В качестве протокола доставки используется самый простой, доступный и проверенный протокол Интернета HTTP, что позволяет доставить видео практически на любое устройство или ПО в сети.

Ниже под катом рассматривается альтернатива — Websocket Streaming для iOS Safari и подробно описывается процесс тестирования.