Комментарии 20
НЛО прилетело и опубликовало эту надпись здесь
Ключевое слово «как». Когда разрабатываете веб-систему, особенно высоконагруженную, подходите к делу так, как будто бы это система реального времени.
Вот как раз с учетом данного ключевого слова и получается вполне однозначный смысл заголовка: «веб-сервис — система реального времени», — что само по себе на сегодняшний день достаточно абсурдно.
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за конструктивную критику. Учтем.
НЛО прилетело и опубликовало эту надпись здесь
Технически проще чем что?
НЛО прилетело и опубликовало эту надпись здесь
Предугадывание запросов у нас есть. Вы легко можете это проверить в хромбаге.
tmpfs, к сожалению, не совсем удачное решение. У вас уйдет много времени на первое копирование части ящика из хранилища в tmpfs, будет много проблем с ее синхронизацией и будет избыточная трата памяти, ибо не все 1000 писем нужны пользователю, обычно только последние 20-30.
tmpfs, к сожалению, не совсем удачное решение. У вас уйдет много времени на первое копирование части ящика из хранилища в tmpfs, будет много проблем с ее синхронизацией и будет избыточная трата памяти, ибо не все 1000 писем нужны пользователю, обычно только последние 20-30.
НЛО прилетело и опубликовало эту надпись здесь
Как минимум это нужно делать для некритичных операций, например, отправки статистики. Кроме того, ответить с лагом 10 секунд и больше — это во многих случаях все равно, что не ответить. Поэтому, по истечению тайм-аута происходит, к сожалению, 500ая ошибка. Зачем зря есть память и висеть в обработчике запросов?
Все к заголовку придрались, а люди in-memory хранилище разработали. Понятно о внутренностях своего сервиса написали. Интересно же! Мне статья очень понравилась
Немного странно
Вы говорите о гарантированном времени отклика, хотя в нем зависите от сети клиента. После пренебрежением сетевых задержек от клиента вы всячески избегаете сетевых задержек в вами контролируемом окружении. Конечно я согласен с тем что вместо 30 запросов между серверами лучше иметь 1-2, но лекарство тут не кеширование, а группировка запросов. И правильная инфраструктура, выделенные каналы с резервированием между серверами со связанными сервисами позволяют гарантировать время отклика по сети. Распространяя этот подход на все связанные сервисы вы получите меньше риска чем просто кешируя запросы. А вместо этого вы точно также игнорируете риск.
На фоне все большим пренебрежением рисков выглядит еще более странным устранение некоторых рисков с памятью. Конечно может у вас все процессы и очереди статично замеплены и никакой динамики нет, но куда вы кладете 10Мб письмо полученное от почтового сервера? Конечно все рассуждения об оптимизации без профилирования — пустое сотрясание воздуха, надеюсь вы его делали и ваши усилия обоснованы.
Плюс высока доступность подразумевает хороший мониторинг ситуации. У вас об этом ни полслова.
Вы говорите о гарантированном времени отклика, хотя в нем зависите от сети клиента. После пренебрежением сетевых задержек от клиента вы всячески избегаете сетевых задержек в вами контролируемом окружении. Конечно я согласен с тем что вместо 30 запросов между серверами лучше иметь 1-2, но лекарство тут не кеширование, а группировка запросов. И правильная инфраструктура, выделенные каналы с резервированием между серверами со связанными сервисами позволяют гарантировать время отклика по сети. Распространяя этот подход на все связанные сервисы вы получите меньше риска чем просто кешируя запросы. А вместо этого вы точно также игнорируете риск.
На фоне все большим пренебрежением рисков выглядит еще более странным устранение некоторых рисков с памятью. Конечно может у вас все процессы и очереди статично замеплены и никакой динамики нет, но куда вы кладете 10Мб письмо полученное от почтового сервера? Конечно все рассуждения об оптимизации без профилирования — пустое сотрясание воздуха, надеюсь вы его делали и ваши усилия обоснованы.
Плюс высока доступность подразумевает хороший мониторинг ситуации. У вас об этом ни полслова.
Время отклика веб сервиса зависит много от чего и в т.ч. от сети клиента. И поэтому надо как минимум ускорять то, что подвластно разработчикам веб-сервиса. Хотя и проблему времени отклика сети клиента можно лечить разными средствами. Мы к этому идем и будут еще статьи.
1-2 запроса вместо 30 — это и есть группировка.
Правильная инфраструктура плюс кэширование — это безусловно лучше чем просто кэширование.
Риски, мы, разумеется, не игнорируем. Жаль, что вы сделали такой вывод.
Получать с сервера 10мб письмо с кучей атачей, чтобы лишь показать юзеру несколько килобайт текстовой части — выглядит странно. Если будете разрабатывать свою почтовую систему, то не делайте так, юзеры вас не полюбят. Более того, отдавать даже большой атач с сервера до юзера можно потоковым методом.
О мониторинге я обязательно расскажу в следующих статьях.
1-2 запроса вместо 30 — это и есть группировка.
Правильная инфраструктура плюс кэширование — это безусловно лучше чем просто кэширование.
Риски, мы, разумеется, не игнорируем. Жаль, что вы сделали такой вывод.
Получать с сервера 10мб письмо с кучей атачей, чтобы лишь показать юзеру несколько килобайт текстовой части — выглядит странно. Если будете разрабатывать свою почтовую систему, то не делайте так, юзеры вас не полюбят. Более того, отдавать даже большой атач с сервера до юзера можно потоковым методом.
О мониторинге я обязательно расскажу в следующих статьях.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Веб-сервис как система реального времени