optio Feb 6 2015 at 11:35

Техническая сторона Supl.biz

3 min

15K

Supl.biz corporate blogWebsite development*Django*Designing and refactoring*

+13

Comments 30

SuicideBlonde Feb 6 2015 at 17:32

А при помощи чего вы диаграму рисовали?

lesha_firs Feb 6 2015 at 17:58

думаю это drive.draw.io

optio Feb 6 2015 at 20:28

так и есть, draw.io

saggid Feb 6 2015 at 17:35

Здравствуйте) просто небольшой совет к вашему сайту: оберните вызов отображения прогрессбара ajax-загрузки страницы в setTimeout, чтобы он появлялся только тогда, когда сайт простаивает в ожидании данных больше, скажем, секунды, или двух секунд. Чтобы постоянно эта полоска загрузки не появлялась, при каждом клике, и не раздражала пользователей) По большей части, этот прогресс бар вообще не нужен, если сайт отвечает достаточно быстро. А вот когда сайт вдруг начнёт долго ждать ответа, то логично будет показать ему эту полосу загрузки.

optio Feb 6 2015 at 21:06

Спасибо. Я полностью с Вами согласен. Рано или поздно это будет реализовано.

Но тут важно понимать как мы расставляем приоритеты задач: мы задаём вопрос «Как это влияет на основные показатели?»
В итоге в первую очередь реализуем то, что требуется для роста проекта и его монетизации. Lean startup в чистом виде.

saggid Feb 6 2015 at 23:54

Вот так это сделано в одном моём проекте: gist.github.com/believer-ufa/5eb9feb93c1298f48eb3
У меня анимация включается через 800 миллисекунд, большинство запросов отрабатывает меньше этого времени, и обычно прогресс-бар не появляется)

Kumarunster Feb 7 2015 at 01:02

на сайте используется ангулар-модуль ngProgressLite (https://github.com/voronianski/ngprogress-lite). Не знаю насчет кастомизации, документация не выглядит достаточно полной.

Мы используем практически везде angular-loading-bar (https://github.com/chieffancypants/angular-loading-bar). Он сам запускается при http-запросах после 100 мс. Можно задать и большую границу при конфигурации приложения, все очень удобно.

Cyrill Feb 6 2015 at 18:08

Вот если бы не хабр — я бы про вас не узнал...)

allexx Feb 6 2015 at 18:10

Расскажите про celery немного — профиль использования, ваши «best practices» по проблемам?

optio Feb 6 2015 at 20:38

Кратко:

В стандартной поставке celery уже хорош. Я доволен и не ищу «легковесных» альтернатив.
Обязательно нужен веб-мониторинг celery flower. Когда какая-нибудь задача сходит с ума и забивает все рабочие процессы — только так можно быстро всё наладить.
Приоритетов задач в celery нет, но они нужны. Помогает запуск нескольких сервисов celery с различными очередями. Приоритетные и важные задачи отправляются в одну очередь, медленные и неприоритетные — в другую. В результате задачи не блокируют друг друга.
В качестве очереди задач в теории можно использовать Redis, но стабильно у меня работает только RabbitMQ.

Xpundel Feb 6 2015 at 19:06

Какая симпатичная у вас разработчик! ;-)

optio Feb 6 2015 at 20:42

Вы бы слышали как она поёт джаз :)
www.youtube.com/watch?v=ktqe9ZoDl7E

Xpundel Feb 6 2015 at 21:05

Не, так не бывает

optio Feb 6 2015 at 21:07

Передам Татьяне, что её не существует :)

BigD Feb 6 2015 at 22:11

А про RabbittMQ расскажите плиз для человека, ничего в этом не понимающего — чем подробнее, тем лучше. Интересно реальное применение таких штук.

optio Feb 7 2015 at 10:53

При текущей нагрузке проекта — RabbitMQ не более чем клей между django и celery. Настраивается однажды по документации, обслуживания не требует.

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

pesh1983 Feb 6 2015 at 22:48

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

optio Feb 7 2015 at 10:50

На проекте настроено обновление с нулевым простоем серверов. Детально расписывать — получится отдельная статья. Если кратко:

Пока перезапускается процесс uwsgi — запросы ждут в очереди, либо уходят на другой сервер
Версия кода на сервере строго связана с версией скриптов и стилей (чтобы не получилась новая разметка со старыми стилями)
Так как миграция схемы БД выполняется до перезапуска сервера, то старый код должен уметь работать с новой версией схемы БД.

Не все изменения можно выложить на проект при таком подходе. В таких случаях — обновление производится по ночам или субботам с остановкой работы проекта.

pesh1983 Feb 7 2015 at 11:27

Спасибо, как-то даже не задумывался о перенаправлении запросов на другой сервер)

MechanisM Feb 7 2015 at 11:24

Так как я деплою django проекты через uwsgi, могу порекомендовать к прочтению это — там описано несколько различных способов.

pesh1983 Feb 7 2015 at 11:28

Пресного благодарен, полезная статья

optio Feb 7 2015 at 12:06

По этой статье и сделано

lesha_firs Feb 7 2015 at 02:53

почему memcached в качестве кеша не выбрали?

optio Feb 7 2015 at 11:00

Memcached никогда не освобождает занятую память, в отличии от Redis. В облачном окружении это превращается в финасовые потери на пустом месте.

Выбор делал достаточно давно — с тех пор что-то могло поменяться.

stalkerg Feb 7 2015 at 13:04

А почему не использовали полнотекстный поиск из Postgres? Он ещё быстрее, при стандартных usecase не надо отдельно стучаться в другую БД, можно делать join с результатами поиска и т.д.

optio Feb 7 2015 at 13:36

Просто полнотекстового поиска недостаточно. Нужен полнотекстовый префиксный поиск с учётом морфологии.
Так же требуется агрегировать данные для отчётов (например, нам интересно знать динамику размещения и выполнения заказов по рубрикам и регионам)

Всё это можно сделать на PostgreSQL. Первое решение как раз было реализовано на PostgreSQL, но работало достаточно медленно и серьёзно нагружало CPU. Можно основательно разобраться в документации, правильно настроить индексы и написать оптимальные запросы. Но сколько это займёт времени и будет ли результат — мне сложно сказать.

С другой стороны — в ElasticSearch достаточно просто выгрузить данные и тут же получить результат. Что и было сделано.

NaN Feb 7 2015 at 13:31

Да, мне тоже лишним показался Эластик. В свое время отказались от него, в пользу больших плоских таблиц в БД. Меньше компонентов, меньше рисков, прозрачней архитектура, и java эта, оххххх, сколько же она жралаааа ram.
Еще я бы postfix на exim4 заменил, он шибко быстрей и стабильней.

А так всё круто. Схемку себе утащил, сам подобные периодически в draw.io калякаю, буду активно размышлять над ней. У мну правда стек технологий другой (backbone.js / jquery / php-fpm / percona db / memcached / nginx).

Не поделитесь инфой, сколько все это дело жрет под нагрузкой ram, какая нагрузка, сколько весит БД, сколько платите «за свет» )
Надеюсь, не сильно обнаглел ?)

optio Feb 7 2015 at 13:55

Мне больше проблем доставляет PhantomJS: он стремится выжрать всю доступную ему память и занять весь процессор.

lesha_firs Feb 7 2015 at 16:38

Я бы заменил
jquery => reactJs
php-fpm => Python + django

Кстати если кому интересно: Архитектура Instagram и Техническая сторона Медузы

HiNeX Oct 13 2015 at 14:57

optio можно попросить вас не красить блоки в оранжевый при наведении? Просто при длительном просмотре сайта от этого начинает болеть голова(