ktokto

Всем привет.

По просьбам желающих (Мониторим Nginx c помощью ZTC и Zabbix) сделал мини статью по подключению memcache к Zabbix. Здесь все гораздо проще, нежели с ZTC шаблонами.

Для начала проверим, что memcache у нас жив и правильно отдает нужные нам значения:

В этой статье я опишу интересное решение на базе Nginx для случая, когда дисковая система становится узким местом при раздаче контента (например, видео).

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

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

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

В чем суть проблемы

Проблема заключается в том, что любой нормальный сервер приложений всегда выставляет Cookie, например для того, чтобы сохранять сессию клиента или корзину с его товаром. Если этот сервер (точнее его администратор) озабочен поддержанием определенного уровня безопасности, то он выставляет в теле Cookie домен и путь, например domain= backend.org; path=/path1. Наш Nginx запущенный в режиме Reverse Proxy замечательно меняет все ссылки в теле документов с backend.org на frontend.org, но не делает этого для кук! Это означает что браузер клиента отвергнет такие куки.

Этот вопрос с давних пор волнует умы администраторов nginx, в рассылках он всплывает по 1-2 раза в год. Большинство вопрошавших, по-видимому, решили свои проблемы подкручивая логику backendа, но не я! После очередного апдейта оригинального сайта стало понятно, что костыль с PHP + Curl тянуть больше невозможно и надо непременно найти решение с помощью Nginx!

Я вернул тему в рассылку, попутно перебирая варианты из ngx_http_perl_module и переменной $upstream_http_set_cookie, даже заглянул в дебри сорсов с призрачной надеждой написать модуль самому. Но все было неудачно пока в один прекрасный момент я не получил письмо от Mikhail Mazursky, который дал ценный совет. Благодаря этому совету я не только с легкостью решил задачу проксирования Cookie, но и получил новый инструмент, с помощью которого можно создать версию 2.0 своего проекта.

Решение

Название этого инструмента lua-nginx-module, который написан еще одним китайским самородком с корнями из Taobao. Из названия легко понять, что речь об языке скриптов Lua встроенном в Nginx — но это больше чем просто интерпретатор! Эти ребята создали полностью неблокируемую реализацию с производительностью десятки тысяч операций в секунду, которая имеет хуки ко всем событиям внутри Nginx. То что раньше можно было реализовать только написав свой модуль на C, теперь можно сделать несколькими строчками на Lua. Заинтересовались?

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

Думаю, что все разработчики на PHP (включая меня) так или иначе проходили через период, когда код представляет из себя жуткую смесь html и php, напиханных в одном файле. И речь не о шаблонах, а вообще о всей логике в лапше/спагетти-коде.
И в качестве концепта я решил к первому апреля набросать реализацию чего-то подобного, но на lua под nginx. Прямо как на картинке.

---

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

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

---

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

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

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

О том, что, ускорение загрузки сайта даже на полсекунды важно уже много написано и известно всем.



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

Для этого мы будем использовать Microsoft Azure, который на месяц дает бесплатный аккаунт и 7000руб. на счет, что позволяет не рискуя понять сколько вы будете тратить в месяц на ускорение своего сайт.
Для примера, по расчету для 10 сайтов с настройками из статьи, с общим количеством просмотров около 10 000 в день, я буду платить около 100руб.м. в месяц (грубая прикидка, скорее всего меньше).

Эта статья поможет ответить на вопросы владельцев, разработчиков и системных администраторов PHP-сайтов:

• Как оптимизировать сайт и ускорить его работу?
• С какой скоростью будет и может работать сайт, в соответствии с теми технологиями на которых он будет запущен?
• Какие технологии следует использовать настраивая сервер или VPS?

Типичная проблема:
В какой-то момент сайт начинает открываться и работать слишком медленно. Бывает, что хостинговая компания блокирует сайт за превышение нагрузки или перерасход ресурсов. Что же делать в такой ситуации?

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

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

В этом обзоре я протестирую только что установленный сайт на одном из самых распространённых движков управления контентом Drupal 7.33.

Для теста выбрана лишь одна составляющая php-хостинга. Мы будем тестировать web-серверы Nginx и Apache2, модули mod_php и php-fpm, версии php php53 и php56, посмотрим, как влияют оптимизаторы apc и opcache на скорость работы сайта.

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

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

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

В этой статье мы расскажем, как анализировать данные 1С при помощи QuBeQu: откуда возникает такая задача, как это работает и какие есть альтернативы.

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

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

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

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

Меня просто бесит, когда менеджер проекта отправляет макет дизайна — письмом, с припиской «Вот, нарисовали. Смотрите. Ждем ваших замечаний». Убил бы.

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

— Это возмутительно! И вот почему:

Есть разные методологии разработки. Каждый выбирает себе тот подход, который максимально эффективно подходит компании-разработчику. В качестве основы для собственной методологии мы используем экстремальное программирование (XP). Конечно же мы внесли в нее собственные изменения, но сегодня я бы хотел рассказать не об этом.



Любой проект начинается с технического задания. Так было раньше, а для многих это остается аксиомой до сих пор. Это не плохо, однако мы практически полностью отказались от ТЗ. Теперь это сокращает нам огромное количество времени, которое тратилось раннее практически впустую.

На днях нам попалась заметка хабражителя Mairon, найденная по теме «Защита моих персональных данных – мое личное дело».

Вызвала эта заметка массу мыслей и соображений, даже взволновала не на шутку. Спешим поделиться с Хабром своими мыслями на указанную тему.

Постоянно приходится слышать на всех мероприятиях, которые по долгу службы мы регулярно посещаем, бесконечное причитание представителей солидных, небедных компаний о том, что «как-так можно выполнить требования ФЗ-152 нам не понятно?», «как-так столько денег надо на это потратить?», «как-так государство не выделило нам средств на это?»… Все это происходит на фоне нашей повседневной, личной некорпоративной жизни, где мы постоянно сталкиваемся:

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

Из всех часто задаваемых вопросов на тему хранения, обработки и защиты персональных данных по частоте возникновения уверенно лидирует следующий: «Может кто-нибудь адекватно пояснить, как распространяется сей ФЗ на обычную фирму, которая имеет локальную инсталляцию 1С и считает зарплату?». А распространяется он одинаково на все организации, обрабатывающие персональные данные, независимо от их размера (даже ИП, который ведет в 1С расчеты с наемными работниками). Естественно, небольшая (и даже средняя) компания в здравом уме и трезвой памяти задастся вопросом: «А стоит ли овчинка выделки?»

Привет, Хаброжители!

Недавно у нас вышли книги по созданию посадочных страниц и лидогенерации.



А. Петроченков, Е. Новиков «Идеальный Landing Page. Создаем продающие веб-страницы»
К. Андреева «Лидогенерация. Маркетинг, который продает»
Р. Назипов «Лидогенерация: клиентов много не бывает»

Цель поста — краткий обзор книг.

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

Это история о значительной оптимизации интерпретатора Perl, о борьбе со сложностями кода, и о том, как мы хотели «съесть торт так, чтобы он у нас остался» [английская поговорка «You can't have your cake and eat it», означающая невозможность достижения двух противоположных целей].

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

Предыстория

В perlguts и PerlGuts Illustrated написано, что представление переменных в Perl обычно состоит из двух частей – заголовка и тела (представляемых как struct). Заголовок содержит необходимые для обработки переменных данные, которые не зависят от её типа, включая указатель на возможное тело.



Структура тела может сильно отличаться, в зависимости от типа переменной. Простейшая переменная — SvNULL, которая представляет undef и которой не требуется тело.

У строки (PV — “pointer value”) тело имеет тип XPV:



Структура тела PV отличается от тела PVNV. PVNV может содержать число с плавающей точкой и строковое представление того же значения.



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