How to become an author
Search
Write a publication
Pull to refresh

Comments 30

так и есть, draw.io
This comment wasn’t rated yet0
Здравствуйте) просто небольшой совет к вашему сайту: оберните вызов отображения прогрессбара ajax-загрузки страницы в setTimeout, чтобы он появлялся только тогда, когда сайт простаивает в ожидании данных больше, скажем, секунды, или двух секунд. Чтобы постоянно эта полоска загрузки не появлялась, при каждом клике, и не раздражала пользователей) По большей части, этот прогресс бар вообще не нужен, если сайт отвечает достаточно быстро. А вот когда сайт вдруг начнёт долго ждать ответа, то логично будет показать ему эту полосу загрузки.
Total votes 2: ↑2 and ↓0+2
Спасибо. Я полностью с Вами согласен. Рано или поздно это будет реализовано.

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

This comment wasn’t rated yet0
Вот так это сделано в одном моём проекте: gist.github.com/believer-ufa/5eb9feb93c1298f48eb3
У меня анимация включается через 800 миллисекунд, большинство запросов отрабатывает меньше этого времени, и обычно прогресс-бар не появляется)
Total votes 1: ↑1 and ↓0+1
на сайте используется ангулар-модуль ngProgressLite (https://github.com/voronianski/ngprogress-lite). Не знаю насчет кастомизации, документация не выглядит достаточно полной.

Мы используем практически везде angular-loading-bar (https://github.com/chieffancypants/angular-loading-bar). Он сам запускается при http-запросах после 100 мс. Можно задать и большую границу при конфигурации приложения, все очень удобно.
Total votes 1: ↑1 and ↓0+1
Вот если бы не хабр — я бы про вас не узнал...)
Total votes 1: ↑1 and ↓0+1
Расскажите про celery немного — профиль использования, ваши «best practices» по проблемам?
Total votes 1: ↑1 and ↓0+1
Кратко:
  1. В стандартной поставке celery уже хорош. Я доволен и не ищу «легковесных» альтернатив.
  2. Обязательно нужен веб-мониторинг celery flower. Когда какая-нибудь задача сходит с ума и забивает все рабочие процессы — только так можно быстро всё наладить.
  3. Приоритетов задач в celery нет, но они нужны. Помогает запуск нескольких сервисов celery с различными очередями. Приоритетные и важные задачи отправляются в одну очередь, медленные и неприоритетные — в другую. В результате задачи не блокируют друг друга.
  4. В качестве очереди задач в теории можно использовать Redis, но стабильно у меня работает только RabbitMQ.
This comment wasn’t rated yet0
Какая симпатичная у вас разработчик! ;-)
Total votes 2: ↑2 and ↓0+2
Передам Татьяне, что её не существует :)
This comment wasn’t rated yet0
А про RabbittMQ расскажите плиз для человека, ничего в этом не понимающего — чем подробнее, тем лучше. Интересно реальное применение таких штук.
Total votes 3: ↑3 and ↓0+3
При текущей нагрузке проекта — RabbitMQ не более чем клей между django и celery. Настраивается однажды по документации, обслуживания не требует.

Если возникают проблемы с выполнением фоновых задач, то они в самих задачах, а не в транспорте нескольких сообщений между серверами.
This comment wasn’t rated yet0
Очень интересует, как вы так часто обновляете проект на рабочем сервере и пользователи этого не замечают? Насколько мне известно, после обновления рабочей копии сервера его нужно перезапустить, а это автоматом отключает всех пользователей на время перезапуска. Это для вас приемлемо или вы как-то по-другому решаете эту проблему?
Total votes 1: ↑1 and ↓0+1
На проекте настроено обновление с нулевым простоем серверов. Детально расписывать — получится отдельная статья. Если кратко:

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


Не все изменения можно выложить на проект при таком подходе. В таких случаях — обновление производится по ночам или субботам с остановкой работы проекта.
This comment wasn’t rated yet0
Спасибо, как-то даже не задумывался о перенаправлении запросов на другой сервер)
Total votes 1: ↑1 and ↓0+1
Так как я деплою django проекты через uwsgi, могу порекомендовать к прочтению это — там описано несколько различных способов.
Total votes 1: ↑1 and ↓0+1
Пресного благодарен, полезная статья
Total votes 1: ↑1 and ↓0+1
По этой статье и сделано
Total votes 1: ↑1 and ↓0+1
Memcached никогда не освобождает занятую память, в отличии от Redis. В облачном окружении это превращается в финасовые потери на пустом месте.

Выбор делал достаточно давно — с тех пор что-то могло поменяться.
This comment wasn’t rated yet0
А почему не использовали полнотекстный поиск из Postgres? Он ещё быстрее, при стандартных usecase не надо отдельно стучаться в другую БД, можно делать join с результатами поиска и т.д.
Total votes 2: ↑2 and ↓0+2
Просто полнотекстового поиска недостаточно. Нужен полнотекстовый префиксный поиск с учётом морфологии.
Так же требуется агрегировать данные для отчётов (например, нам интересно знать динамику размещения и выполнения заказов по рубрикам и регионам)

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

С другой стороны — в ElasticSearch достаточно просто выгрузить данные и тут же получить результат. Что и было сделано.
This comment wasn’t rated yet0
Да, мне тоже лишним показался Эластик. В свое время отказались от него, в пользу больших плоских таблиц в БД. Меньше компонентов, меньше рисков, прозрачней архитектура, и java эта, оххххх, сколько же она жралаааа ram.
Еще я бы postfix на exim4 заменил, он шибко быстрей и стабильней.

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

Не поделитесь инфой, сколько все это дело жрет под нагрузкой ram, какая нагрузка, сколько весит БД, сколько платите «за свет» )
Надеюсь, не сильно обнаглел ?)
Total votes 1: ↑1 and ↓0+1
Мне больше проблем доставляет PhantomJS: он стремится выжрать всю доступную ему память и занять весь процессор.
This comment wasn’t rated yet0
optio можно попросить вас не красить блоки в оранжевый при наведении? Просто при длительном просмотре сайта от этого начинает болеть голова(
This comment wasn’t rated yet0
Sign up to leave a comment.

Your account

Sections

Information

Services

Support
© 2006–2024, Habr