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

Но что делать, когда ваш код “идеален”, все тяжелые запросы вынесены в фон, все, что можно, было закэшировано, а сервер все так же не дотягивает до нужных нам показателей SLA? Если есть возможность, то конечно можно докупить новых машин, распределить часть трафика и забыть о проблеме еще на некоторое время.

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

О чем мы расскажем:

— Почему мы решили перейти на LXC контейнеры?
— Как создать контейнер и запустить на нем хост на базе Битрикс?

Для кого это будет полезно:

Для всех, кто хочет попробовать новое решение, при этом используя меньше ресурсов.

О чем мы расскажем:
Как быстро развернуть общее хранилище для двух серверов на базе решений drbd+ocfs2.

Для кого это будет полезно:
Туториал станет полезен системным администраторам и всем, кто выбирает способ реализации хранилища или хотят попробовать решение.

От каких решений мы отказались и почему

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

• Glusterfs не устроил нас производительностью на чтение и запись, возникали проблемы с одновременным чтением большого количества файлов, была высокая нагрузка на CPU. Проблему с чтением файлов можно было решить, обращаясь за ними напрямую в brick-и, но это не всегда применимо и в целом неправильно.

• Ceph не понравился избыточной сложностью, которая может быть вредна на проектах с 2-4 серверами, особенно, если проект впоследствии обслуживают. Опять же, имеются серьезные ограничения по производительности, вынуждающие строить отдельные storage кластеры, как и с glusterfs.

• Использование одного nfs сервера для реализации общего хранилища вызывает вопросы в плане отказоустойчивости.

• s3 — отличное популярное решение для некоторого круга задач, но это и не файловая система, что сужает область применения.

Все мы совершаем ошибки: в данном случае речь идет о поисковых запросах. Количество сайтов для продажи товаров и услуг растет наряду с потребностями пользователей, однако не всегда они могут найти то, что ищут – только потому, что неправильно вводят название необходимого товара. Решение данной проблемы достигается путем реализации нечеткого поиска, то есть использования алгоритма поиска наиболее близких значений с учетом возможных ошибок или опечаток пользователя. Область применения такого поиска достаточно широка – нам же удалось поработать над поиском для крупного интернет-магазина в фудритейл-сегменте.

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

В июле этого года наша студия Greensight приняла предложение холдинга «Кофе Хауз» на участие в оплачиваемом (что само по себе на сегодняшний день уже достаточно необычно) тендере на создание четырех новых сайтов холдинга (рестораны «Кофе Хауз», «Винегрет», «Азия кафе» и объединяющего их холдинга).

Наверняка к вам на улице когда-нибудь приставали девушки или юноши с предложением ответить на самые разные вопросы — от «Что вы курите?» до «За кого вы собираетесь голосовать?».

Случалось ли так, что вы не сразу могли найти форму регистрации или опроса на сайте? Наверняка бывало, хотя бы раз.

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

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

На днях мы открыли qFlow.ru – новый SaaS-проект (пока в beta-версии) для легкого создания web-форм и настройки бизнес-процессов обработки полученных результатов.

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

Идея сервиса для создания web-форм не нова и в интернете можно найти много вариантов, но найти удобный и достаточно функциональный сервис не так уж и просто. Например, в документах гугл есть конструктор web-форм, но он на английском, а работа с результатами все же не так проста, как хотелось бы. Недавно открылся сервис wufoo.com – очень симпатичный и простой, но как у в гугле нет процессов и он на английском.

Редактирование результата