---

В продолжение статьи:

Ускорение и оптимизация PHP-сайта. Какие технологии стоит выбирать при настройке сервера под PHP

---

В отличии от предыдущего материала, в этой статье сделан упор на сравнение скорости отклика и интерпретации кода для различных версий PHP, включая PHP 7 beta3.

Для ранних версий PHP, проведено тестирование между оптимизаторами кода apc, xcache и opcaсhe.
Эта статья не содержит тестов на производительность, таких как нагрузочные тесты ab и siege. Возможно, об этом я напишу в одной из следующих статей.
В данном случае, меня не интересует сколько страниц за секунду способна сгенерировать та или иная версия php-интерпретатора, скорее то, с какой скоростью она сгенерирует мне страницу и с какой задержкой.
В данном случае разница в том, что тесты производительности замеряют отношение скорости интерпретатора к общим ресурсам сервера, а так же подготовленности других связанных компонентов web-системы к работе на повышенных нагрузках.
Остановимся на скорости и отклике. Очевидно что производительность зависит от скорости, но высокая скорость не может гарантировать высокую производительность. Это, возможно, связанно с тем, что недостаточно хорошо настроен web-сервер или база данных, а также с какими-то не было ограничениями, например сетевого стека.
Что бы не заниматься попыткой объять необъятное, мы просто замерим скорость и отклик работы интерпретаторов php, на мощном сервере без нагрузки, с одинаковыми конфигурациями web-сервера, базы данных и операционной системы для всех испытуемых. Используем конфигурацию php-fpm + nginx. База данных MariaDB. Все технические детали скрыты под спойлером ниже.

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

^{(ориг. фото)}

После выхода mysql 5.6 с его GTID (global transaction identifier) репликация в mysql перестала быть кошмарным сном сисадмина и стала вполне рабочим инструментом. В инете есть некоторое количество информации по этому поводу, но вся она довольно разрозненная и не всегда доступна для понимания. По этому я решил сделать небольшую инструкцию-выжимку, больше для себя, но может и еще кому пригодится.

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

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

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

Привет Хабр! Последние 1.5 года я работал над своим проектом, которому был необходим надежный облачный хостинг. До этого момента я больше 10 лет занимался веб-программированием и когда я решил построить свой хостинг у меня были относительно поверхностные знания в этой области, я и сейчас не являюсь системным администратором. Все что я буду рассказывать может выполнить обычный программист в течение 5 минут, просто запустив набор сценариев для Ansible, которые я подготовил специально для вас и выложил на GitHub.

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

В июне 2014 года на конференции Google I/O вместе с новой версией операционной системы Android 5 была представлена целая философия дизайна от Google — Material Design.



Разрабатывая прежние Android-версии Aviasales, мы далеко не во всем «слушали» Google. Теперь же, с выходом Android 5, было решено опробовать новые гайдлайны, и о наших впечатлениях я расскажу ниже.

WebRTC – это API, предоставляемое браузером и позволяющее организовать P2P соединение и передачу данных напрямую между браузерами. В Интернете довольно много руководств по написанию собственного видео-чата при помощи WebRTC. Например, вот статья на Хабре. Однако, все они ограничиваются соединением двух клиентов. В этой статье я постараюсь рассказать о том, как при помощи WebRTC организовать подключение и обмен сообщениями между тремя и более пользователями.

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

Вёрстка HTML для электронной почты — интересная и довольно сложная задача. Письма должны одинаково хорошо отображаться на старых устройствах и версиях программных клиентов.

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

Примечание переводчика: Представленный ниже материал содержит значительное количество технических терминов, при переводе которых могут возникнуть неточности. Если вы заметили опечатку, ошибку или неточность перевода — напишите нам, и мы оперативно всё исправим.

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

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

Итак, поехали.

Уже несколько месяцев использую docker для структуризации процесса разработки/доставки веб-проектов. Предлагаю читателям «Хабрахабра» перевод вводной статьи о docker — «Understanding docker».

Что такое докер?

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

Так уж случилось, что последнее время приходилось заниматься оптимизацией и масштабированием различных систем. Одной из задач было масштабирование PostgreSQL. Как обычно происходит оптимизация БД? Наверное, в первую очередь смотрят на то, как правильно выбрать оптимальные настройки для работы и какие индексы можно создать. Если обойтись малой кровью не вышло, переходят к наращиванию мощностей сервера, выносу файлов журнала на отдельный диск, балансировке нагрузки, разбиению таблиц на партиции и к всякого рода рефакторингу и перепроектированию модели. И вот уже все идеально настроено, но наступает момент, когда всех этих телодвижения оказывается недостаточно. Что делать дальше? Горизонтальное масштабирование и шардинг данных.

Доброе утро, Хабр!

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

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

У компаний с большим портфелем продуктов со временем встает вопрос упрощения работы над ними. В Mail.Ru Group их около 40, не считая мобильных и планшетных версий, а также огромного игрового направления. Наше подразделение Почты и Портала занимается почти половиной из этих сорока. Что вместе с сопроводительными приложениями, мобильными сайтами и промо-ресурсами — за сотню проектов. Сейчас мы ведем их поэтапное обновление и унификацию вокруг нескольких гайдлайнов. На примере одного из них я расскажу о том, как перестроить дизайн-процесс от классического «прототип → макет → верстка → код» для каждого экрана к более эффективному и современному, основанному на фреймворках.

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

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

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

До девятой версии в PostgreSQL для создания «теплого» резервного сервера использовался WAL archiving. В версии 9.0 появилась потоковая репликация с возможностью создания «горячего» read-only сервера. В следующей версии PostgreSQL 9.4 появится новый функционал для создания потоковой репликации под названием replication slots.

Docker в продакшене на Iron.io


Ранее в этом году (прим. 2014 г.), мы приняли решение запускать каждую задачу на IronWorker внутри своего собственного Docker контейнера. С тех пор мы запустили более 300 000 000 программ внутри собственных Docker контейнеров в облаке.

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

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

Соответственно, технологический прогресс шел не только по направлениям увеличения мощности процессоров, объемов памяти или уменьшения размеров устройств, но и в области улучшения эффективности работы с данными. В результате появилось большое количество различных систем управления базами данных (СУБД).

В нашем продукте, мессенджере для корпоративных коммуникаций Kato, используется СУБД PostgreSQL. Сегодня мы хотели бы напомнить историю возникновения этого прекрасного инструмента и показать преимущества его использования для стартапов в области информационных технологий.

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

В случае балансировки и терминации HTTP(S)-трафика на HAProxy (Layer 7 [1]) данная задача легко решается добавлением заголовка “X-Real-IP” и его обработкой на Nginx при помощи модуля ngx_http_realip_module [2]. При балансировке TCP-трафика от HTTPS-клиентов и передаче его на веб-сервера напрямую без модификации или терминации (Layer 4 [3]) добавить данный заголовок невозможно, поэтому требуется воспользоваться возможностями, предоставляемыми Proxy Protocol [4, 5, 6].

Рассмотрим оба варианта (балансировка L7 и L4) на примере выдержек из конфигурационных файлов haproxy 1.5.9 и nginx 1.6.2