Pull to refresh

Comments 20

UFO just landed and posted this here
Ключевое слово «как». Когда разрабатываете веб-систему, особенно высоконагруженную, подходите к делу так, как будто бы это система реального времени.
Вот как раз с учетом данного ключевого слова и получается вполне однозначный смысл заголовка: «веб-сервис — система реального времени», — что само по себе на сегодняшний день достаточно абсурдно.
Но, тем не менее, пользователь не любит ждать. Стремитесь к системе реального времени.
Вот ниже вам более развернуто ответили.
Спасибо за совет — буду стремиться. Вам же посоветую стремиться к более адекватным заголовкам — дабы читатель понимал, что вы тоже пока стремитесь, а не совершили переворот в науке :)
Спасибо, будем стремиться
UFO just landed and posted this here
Спасибо за конструктивную критику. Учтем.
UFO just landed and posted this here
Технически проще чем что?
UFO just landed and posted this here
Предугадывание запросов у нас есть. Вы легко можете это проверить в хромбаге.
tmpfs, к сожалению, не совсем удачное решение. У вас уйдет много времени на первое копирование части ящика из хранилища в tmpfs, будет много проблем с ее синхронизацией и будет избыточная трата памяти, ибо не все 1000 писем нужны пользователю, обычно только последние 20-30.
UFO just landed and posted this here
UFO just landed and posted this here
Как минимум это нужно делать для некритичных операций, например, отправки статистики. Кроме того, ответить с лагом 10 секунд и больше — это во многих случаях все равно, что не ответить. Поэтому, по истечению тайм-аута происходит, к сожалению, 500ая ошибка. Зачем зря есть память и висеть в обработчике запросов?
Все к заголовку придрались, а люди in-memory хранилище разработали. Понятно о внутренностях своего сервиса написали. Интересно же! Мне статья очень понравилась
Немного странно

Вы говорите о гарантированном времени отклика, хотя в нем зависите от сети клиента. После пренебрежением сетевых задержек от клиента вы всячески избегаете сетевых задержек в вами контролируемом окружении. Конечно я согласен с тем что вместо 30 запросов между серверами лучше иметь 1-2, но лекарство тут не кеширование, а группировка запросов. И правильная инфраструктура, выделенные каналы с резервированием между серверами со связанными сервисами позволяют гарантировать время отклика по сети. Распространяя этот подход на все связанные сервисы вы получите меньше риска чем просто кешируя запросы. А вместо этого вы точно также игнорируете риск.

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

Плюс высока доступность подразумевает хороший мониторинг ситуации. У вас об этом ни полслова.
Время отклика веб сервиса зависит много от чего и в т.ч. от сети клиента. И поэтому надо как минимум ускорять то, что подвластно разработчикам веб-сервиса. Хотя и проблему времени отклика сети клиента можно лечить разными средствами. Мы к этому идем и будут еще статьи.
1-2 запроса вместо 30 — это и есть группировка.
Правильная инфраструктура плюс кэширование — это безусловно лучше чем просто кэширование.
Риски, мы, разумеется, не игнорируем. Жаль, что вы сделали такой вывод.
Получать с сервера 10мб письмо с кучей атачей, чтобы лишь показать юзеру несколько килобайт текстовой части — выглядит странно. Если будете разрабатывать свою почтовую систему, то не делайте так, юзеры вас не полюбят. Более того, отдавать даже большой атач с сервера до юзера можно потоковым методом.
О мониторинге я обязательно расскажу в следующих статьях.
Ok, буду ждать новые статьи. Как минимум интересно
Sign up to leave a comment.