Использование $rootScope.$broadcast — не лучший пример, такое событие будет спускаться по иерархии скоупов и возникать на каждом.
Ну и конечно неизбежно возникают гонки, когда событие сгенерировано, а получатель еще не подписался на него.
Странный у вас профиль — приглашена более чем на полгода позже, чем зарегистрирована. У меня, например, логично — сначала приглашен, через полчаса зарегистрирован.
Модель DEXP Ursus KX110/KX110i удивительно похожа на Oysters T104w (чехол-клавиатура тоже один в один).
Последний у желто-черного оператора с клавиатурой стоит в районе 7000 рублей.
Да, не botvac, а XV-21 вроде.
Я понял, о чем речь — именно такой проблемы с датчиками у меня не было никогда. Как только он бампером случайно врезался в препятствие — тут же понимал это и отъезжал.
Но я правда стабильно его чистил раз в 1-2 недели — снимал щетку и вычищал все артефакты на ней.
У меня неато года 3, наверно.
Года через полтора у него перестало крутиться одно колесо — два похода в сервис-центр вроде бы решили проблему.
Через два года у него сдохли аккумуляторы — купил новые в китае.
Еще через полгода он сдох окончательно — подсветка дисплея горит, но никакой информации на нём нет. Поначалу какое-то время его еще можно было включить в рабочий режим вслепую (благо это делается одной кнопкой), но потом он перестал переходить в режим уборки, а при включении попискивает о какой-то ошибке (без экрана — непонятно). Всё никак не соберусь отдать его в сервис.
240 серверов для хранения пользовательских видео. Дисков там более 7000 — суммарно около 30 петабайт;
метаданные и кэш развёрнуты еще на 36 машинах;
за трансформацию видеороликов в наш внутренний формат отвечают еще 150 серверов;
наконец, ещё 36 машин используются для раздачи и загрузки видео.
Почему нельзя конвертировать видео на 240 стороджах? На сторадже всегда CPU загружен минимально и было бы логично конвертировать именно там.
И почему нельзя загружать файлы и раздавать файлы опять таки напрямую со стороджей? Насколько я понимаю, канал наружу — это 36 серверов? Они наверняка часто втыкают по диску из-за загрузки?
Я конечно все понимаю, но сотня ламп дает ну пусть суммарно тысячу записей в базе. Вся ваша база умещается с потрохами в оперативной памяти калькулятора и будет работать быстро почти при любом раскладе, если ваши руки не совсем кривые.
Если бы в вашей базе было пару сотен миллионов записей — можно было о чем-то говорить.
Удачи, радует, что и такие крутые вещи делаются нашими людьми )
У меня сфинкс (еще какой-то лохматой версии) работает месяцами, рестартуется только при обновлениях на сервере. И при этом на сайте быстрый и внятный поиск.
К написанию тестов своего кода надо подходить максимально взвешенно.
Я всегда писал тесты, и все равно однажды в проекте вылез жуткий баг.
А друг племянника моего брата начал писать тесты на второй день проекта, а через месяц проект свернули!
Мой знакомый вообще придерживается мнения, что тесты вредны, т.к. время, потраченное на тесты, можно было потратить на улучшение кода.
Прошу прощения, я и сам заблуждался, и вас пытался ввести в заблуждение.
В действительности, proxy_cache_lock работает только при создании нового элемента кеша, а при обновлении кеша работает proxy_cache_use_stale updating.
Во-первых, замирание будет равно времени ответа бэкенда.
Во-вторых, вы говорите про 2700 запросов в секунду в пике. Предположим, кеш протух и его обновление занимает 100мс (т.е. бэкенд на этот запрос отвечает за 100мс). Соответственно, в момент протухания кеша на ваш бэкенд пойдет примерно 270 одинаковых запросов практически одновременно! И все эти клиенты получат ответ не ранее чем через 100мс, а скорее даже позже, т.к. ваш бэкенд в любом случае будет работать медленнее при множестве одновременных запросов.
В случае использования proxy_cache_lock на ваш бэкенд уйдет всего один запрос, который обновит кеш за 100мс и все клиенты, ждущие этот кеш (грубо говоря 269 клиентов) получат ответ за те же 100мс, но при этом бэкенд обработал один запрос вместо 270.
У вас видимо nginx староват, по вашей же ссылке в прокси-модуле можно обнаружить вкусности типа директив proxy_cache_lock*, которые могут заметно сгладить всплески просачивающихся на бэкенд запросов при устаревании кеша.
А почему вы не хотите сделать шардинг сами, на уровне приложения?
С доказательной медициной это не имеет ничего общего.
Это неправда, если речь идет об обращениях через личный кабинет налогоплательщика.
Ну и конечно неизбежно возникают гонки, когда событие сгенерировано, а получатель еще не подписался на него.
Последний у желто-черного оператора с клавиатурой стоит в районе 7000 рублей.
Я понял, о чем речь — именно такой проблемы с датчиками у меня не было никогда. Как только он бампером случайно врезался в препятствие — тут же понимал это и отъезжал.
Но я правда стабильно его чистил раз в 1-2 недели — снимал щетку и вычищал все артефакты на ней.
Года через полтора у него перестало крутиться одно колесо — два похода в сервис-центр вроде бы решили проблему.
Через два года у него сдохли аккумуляторы — купил новые в китае.
Еще через полгода он сдох окончательно — подсветка дисплея горит, но никакой информации на нём нет. Поначалу какое-то время его еще можно было включить в рабочий режим вслепую (благо это делается одной кнопкой), но потом он перестал переходить в режим уборки, а при включении попискивает о какой-то ошибке (без экрана — непонятно). Всё никак не соберусь отдать его в сервис.
Проблем с датчиками не было.
Почему нельзя конвертировать видео на 240 стороджах? На сторадже всегда CPU загружен минимально и было бы логично конвертировать именно там.
И почему нельзя загружать файлы и раздавать файлы опять таки напрямую со стороджей? Насколько я понимаю, канал наружу — это 36 серверов? Они наверняка часто втыкают по диску из-за загрузки?
Хотя заканчивается это всегда примерно одинаково.
Если бы в вашей базе было пару сотен миллионов записей — можно было о чем-то говорить.
У меня сфинкс (еще какой-то лохматой версии) работает месяцами, рестартуется только при обновлениях на сервере. И при этом на сайте быстрый и внятный поиск.
Я всегда писал тесты, и все равно однажды в проекте вылез жуткий баг.
А друг племянника моего брата начал писать тесты на второй день проекта, а через месяц проект свернули!
Мой знакомый вообще придерживается мнения, что тесты вредны, т.к. время, потраченное на тесты, можно было потратить на улучшение кода.
В действительности, proxy_cache_lock работает только при создании нового элемента кеша, а при обновлении кеша работает proxy_cache_use_stale updating.
Во-вторых, вы говорите про 2700 запросов в секунду в пике. Предположим, кеш протух и его обновление занимает 100мс (т.е. бэкенд на этот запрос отвечает за 100мс). Соответственно, в момент протухания кеша на ваш бэкенд пойдет примерно 270 одинаковых запросов практически одновременно! И все эти клиенты получат ответ не ранее чем через 100мс, а скорее даже позже, т.к. ваш бэкенд в любом случае будет работать медленнее при множестве одновременных запросов.
В случае использования proxy_cache_lock на ваш бэкенд уйдет всего один запрос, который обновит кеш за 100мс и все клиенты, ждущие этот кеш (грубо говоря 269 клиентов) получат ответ за те же 100мс, но при этом бэкенд обработал один запрос вместо 270.
А почему вы не хотите сделать шардинг сами, на уровне приложения?