Рисунок: Маргарита Закиева
Что будет под катом:
Наша статья будет полезна для тех, кто:
9 декабря состоится уже шестая конференция .NET-разработчиков DotNext – называться она будет DotNext 2016 Moscow и пройдет, как вы наверняка догадались, в Москве (гостиница «Славянская»). Кстати, DotNext – единственная в России .NET-конференция, которая собирает под 600 Senior/Middle .NET-разработчиков.
Что нового будет в этот раз? Прошу под кат.
Читать полностью »
Каждый год на DevConf появляются новые лидеры в разработках — в этом годы было много интересных заявок по Go, где разработчики готовы рассказать, как они применяют Go в продакшен. Вам интересено Go? Присоединяйтесь к сообществу Go на 4Gophers.ru
Первый доклад "Prometheus мониторинг от души" представляет Евгений Пак — разработчик с 10 летним опытом работы, Senior Developer Go компании Lazada. Он расскажет об опыте переезда на Prometheus, и почему выбрали именно его, о процессе миграции и о том, как организована инфраструктура для сбора метрик Go приложений. Расскажет о тонкостях вычисления квантилей как на стороне клиента (тип метрик Summary), так и на стороне сервера (тип метрик Histogram). Также вы узнаете о тех нюансах, с которыми столкнулись при работе с Графаной, и как их решили.
О том, как приготовить Go микросервис к продакшену поведает Вадим Мадисон. Доклад о том, что считать готовым к продакшену микросервисом. Как должен быть реализован микросервис, какую функциональность он должен предоставлять, чтобы считать сервис надежным, прозрачным для поддержки и мониторинга. На примере Go-микросервиса будет дан перечень необходимого функционала и рассказаны основные подходы по разработке, деплою и поддержке микросервисов.
Читать полностью »
Коллеги, помогите сформировать программу DevConf 2016 — должны остаться только лучшие и интересные доклады.
Голосование продлится до 31 мая, сформируем программу вместе!
Представляем вашему вниманию 13 кандидатов на участие:
— Развитие ветки PHP-7.*
Дмитрий Стогов (Zend,PHPNG)
Я расскажу о внутреннем устройсве PHP-7.0, изменениях готовящихся в PHP-7.1 и планах на PHP-7.2.
— Как Badoo перешли на PHP7 и сэкономили $1M
Юрий Насретдинов
Мы сделали это! Несколько сотен наших application-серверов переведены на PHP7 и прекрасно себя чувствуют. Насколько нам известно, это второй переход на PHP7 проекта такого масштаба (после Etsy). В процессе мы нашли несколько очень неприятных багов в системе кеширования байт-кода PHP7, но они исправлены. А теперь — ура! — благая весть для всего PHP-сообщества: PHP7 действительно готов к продакшену, стабилен, потребляет значительно меньше памяти и дает очень хороший прирост производительности. Я расскажу, как мы перешли на PHP7, с какими трудностями столкнулись, как с ними боролись и какие результаты получили.
— Создание расширений для PHP с помощью Zephir.
Виктор Большов crocodile2u
Zephir — высокоуровневый ЯП, предназначенный специально для создания PHP-расширений (extensions). Код, написанный на Zephir, транслируется в C, с использованием внутреннего API для расширений PHP, и его можно собрать как свое объектно-ориентированное расширение. Это может быть крайне полезно для оптимизации «узких мест» вашего кода: можно добиться ускорения интенсивных вычислений в разы.
Читать полностью »
Мы в PushAll обрабатываем несколько тысяч запросов в секунду для получения статистики доставки и открытия уведомлений и для передачи контента оповещений. Обычная БД вроде MySQL не справляется с таким потоком запросов и не может так быстро отвечать.
Стараясь все больше операций перенести на быстрые NoSQL хранилища вроде Redis, мы хотим знать как эффективнее его использовать и не будет ли у нас проблем с большим количеством соединений.
Также для работы мы используем форки PHP и нам было интересно, а как поведет себя Redis, если мы будем делать несколько тысяч соединений в одновременно в нескольких потоках. Мы решили поделиться с сообществом нашими тестами.
Читать полностью »
Мы сделали это! Несколько сотен наших application-серверов переведены на PHP7 и прекрасно себя чувствуют. Насколько нам известно, это второй переход на PHP7 проекта такого масштаба (после Etsy). В процессе мы нашли несколько очень неприятных багов в системе кеширования байт-кода PHP7, но они исправлены. А теперь — ура! — благая весть для всего PHP-сообщества: PHP7 действительно готов к продакшену, стабилен, потребляет значительно меньше памяти и дает очень хороший прирост производительности. Ниже мы подробно расскажем, как мы перешли на PHP7, с какими трудностями столкнулись, как с ними боролись и какие результаты получили. Читать полностью »
В своей предыдущей статье по оптимизации сайта на WordPress я рассказал об очень эффективном подходе к оптимизации за счёт кэширования страниц. В результате чего для незалогиненных пользователей время ожидания страницы клиентом (исключая время на установление TLS-сессии) сократилось с 820 мс до 30 мс (этот и все последующие замеры проводились с сервера, расположенного в том же городе, что и мой VDS), что, согласитесь, является отличным показателем. Однако, для залогиненных пользователей генерация страницы происходила по-прежнему долго — в среднем 770 мс на сервере. В этой части я расскажу о том, как я сократил это время до 65 мс, при этом полностью сохранив работоспособность пользовательского функционала.
Целью этой и предыдущей статей является моё желание показать возможность оптимизации сайтов не только на WordPress, а вообще любого веб-приложения. Поэтому я использую такое количество инструментов, и так детально разбираю их конфигурацию. Если же Вам просто нужно ускорить WordPress — установите плагин WP Super Cache. Если Вас, как и меня, интересуют технологии, позволяющие оптимизировать любой сайт, а также Вам интересно, что стоит учитывать при разработке веб-приложений, рассчитанных на высокие нагрузки — прошу под кат, но только после прочтения первой части — дорабатывать я буду ту же систему.
Читать полностью »
В данной статье я расскажу о том, как я заставил свой блог на WordPress летать за счёт грамотного кэширования, сжатия и другой оптимизации серверной и клиентской сторон. На момент написания статьи характеристики VDS следующие:
CPU: 1 x 2GHz
HDD: 10Gb
RAM: 512Mb
OS: Debian 8 x64
Схема работы системы выглядит следующим образом:
Часто у нас стоит задача протестировать какую нагрузку выдерживает сайт наших клиентов. Для себя, в качестве инструмента тестирования, мы выбрали yandex-tank. Это будет краткая заметка о том как быстро начать работать с этим инструментом.
Здравствуйте, меня зовут Александр Зеленин и я веб-разработчик.
Информация — основа любого приложения или сервиса.
Более 10 лет назад я общался с владельцем покер-рума, и он показал мне страницу, приносившую около 10 000$ в день. Это была совершенно банально оформленная страница. На ней не было ни стилей, ни графики. Сплошной текст, разбитый заголовками, секциями и ссылками. У меня просто не укладывалось в голове — ну как вот это может приносить такие деньги?
Секрет в том, что «вот это» было одним из первых исчерпывающих руководств по игре в покер онлайн. У страницы был PageRank 10/10 (или 9, не суть), и в поисковой выдаче это было первое, на что натыкались.
Цель вашего приложения, какое бы оно ни было — донести (получить, обработать) некоторую информацию до пользователя.
Конечно, конверсия может быть ниже, или пользователь может быть не очень доволен опытом работы с сайтом, но, если сам товар будет именно тем, что он искал — всё остальное будет малозначимо.
Я не рассматриваю магазины, продающие «на эмоциях», и покупки, о которых пользователь может потом пожалеть.
Очень часто способ доступа к этой информации уходит за пределы самого клиента игры. С помощью мобильного приложения можно проверить, не нападает ли на тебя кто, или выставить какие-нибудь товары на внутриигровой аукцион, даже не заходя в саму игру.
Конечно, хорошо использовать лицензионный контент, но если пользователь не может найти то, что искал — он уйдет и найдет это в другом месте. В интернете люди не запоминают информацию как таковую, они запоминают место, где эту информацию нашли. Поэтому, если на вашем сайте нет песен группы Х, но зато есть ссылка на страницу группы Х, где они продают свои альбомы, ваш сервис все равно в плюсе, потому что пользователь запомнил, где он взял информацию о группе Х и вернется к вам еще раз поискать информацию о группе Y.
Я работал в нескольких музыкальных проектах, и очень часто всё упиралось именно в наличие необходимых треков, несмотря на десятки терабайт данных.
Думаю, идею вы уже уловили. Примеры можно приводить бесконечно (вот ещё один: на википедию не за дизайном ходят. Более того, часть информации с википедии выводится сразу в поисковой выдаче, без открытия даже самого сайта), и если думаете, что в вашем случае это неприменимо — напишите в комментариях (или на почту / в личку), и я объясню, почему всё же применимо.
Так вот: чем бы вы ни занимались, первичной всегда будет информация. Хорошую, качественную информацию пользователи обязательно найдут и обратятся к вам.
Я расскажу, как организовать работу с информацией так, чтобы это было:
1. Масштабируемо — репликация, шардирование и т.п. настраивается БЕЗ вмешательства в работу приложения.
2. Удобно для пользователей — легко документировать, понятно как использовать.
3. Удобно для ваших разработчиков — быстрое прототипирование, возможности оптимизации только необходимого.
Данный подход не имеет смысла для вас, если у вас маленький проект с небольшим количеством компонентов и разработчиков.
