Не смотря на то, что статья и перевод были написаны довольно давно, надеюсь, кто-то знающий увидит данное сообщение. Сошлюсь на оригинал статьи.
If each consumer pulls messages then depending on how many they pull the distribution of work can get pretty uneven. The more uneven the distribution of messages the more latency.
Скажем у нас есть 2 случая. В обоих случаях у нас есть 2 потребителя. В первом случае первый потребляет в 2 раза больше, чем второй, например, т.к. у него больше ресурсов. Во втором случае они потребляют с одинаковой скоростью. Почему во втором случае меньше задержка?
Знаю, что прошло уже много времени, но возник вопрос. Я когда-то для себя решил обратный подход использовать (margin-top/left, а не margin-bottom/right), т.к. если компонента нет, то и отступа нет. Это крайне удобно, когда элементы размещаются в контейнере слева направо, сверху вниз. Если порядок в контейнере обратный, тогда margin-bottom/right.
Подскажите, почему обычно используются margin-right/bottom? Это же неудобно, когда компонент может быть опционален. Но даже если он не опционален, то получится, что в одном месте так, в другом сяк. Поэтому для себя решил еще давно, что именно компонент должен себя отталкивать, как и новый человек в очереди должен сам занять дистанцию от последнего, а не его должны отодвигать.
Полностью согласен. Давно бы уже переехал, если бы ценники не были в 2,5-3 раза дороже. Тут при любом размере сервера встает вопрос зачем столько переплачивать. Возьмем, например, слабенький CX31: 2 VCPU, 8 GB RAM, 80 GB SSD (9.20 евро/мес). У селектел аналогичный стоит 3 936,18 руб/мес (39.85 евро/мес). Даже в 4 раза дороже получается. Я конечно понимаю, что все оборудование привозится, а значит тут оно в любом случае будет дороже, но не в 4 же раза. Особенно, когда подобных серверов не один или используются сервера помощнее. Например, вместо 4-5к ценник будет 16-20к в мес. Поэтому никто и не переезжает, если есть возможность. И это камень в огород не только селектел, а вообще всех, кто здесь предоставляет сервера.
Чтобы подтянуть знания в TypeScript крайне рекомендую выделить пару дней и решить все задачки https://github.com/type-challenges/type-challenges без гугла, максимум с офф докой. Довольно много задачек там крайне интересные и нетривиальные.
Получается нужна база координат/идентификаторов всех вышек? Под идентификатором понимаю какой-то уникальный сигнал от вышки, скажем какие-то первые биты должны быть уникальны для каждой вышки, чтобы можно было распознать рядом с какой вышкой мы находимся.
По-моему, это как раз таки эффективный, простой и быстрый (что еще важнее) способ побороть данную проблему. Думаю, что третьим лицам не так легко получить доступ ко множеству вышек, а если такой кейс будет, то можно будет отследить кто получал доступ к ним и когда, вычислив злоумышленника. Напротив, используя GPS можно легко и достаточно точно прилететь туда, куда нужно. Поэтому искажение GPS выглядит как минимум логичным шагом (+ быстрым и недорогим, по сравнению с другими способами) по крайней мере на время.
Мне одному режет глаза, что у isObject тут лишняя проверка на undefined? `!= null` проверяет не только на null, но и на undefined. Надо бы `!== null`, т.к. следующее условие `typeof val === 'object'` уберет undefined.
Подскажите, можно ли чистить простой электрощеткой (не ультразвуковой) плобмированные зубы и коронки? Сколько не спрашиваю у зубных врачей, половина говорит, что можно, половина, что нельзя.
Может ли пломба и коронка от этого как то расшататься?
И еще возник вопрос по поиску по JSONB. Если структура большинства JSON объектов одинаковая (напр, как в примере во всех объектах есть days_of_week), то получается при поиске по ключу-значению (напр, '{"days_of_week": [5]}') будут всегда в начале выбираться все записи (т.к. у них всех есть ключ days_of_week), а потом функция согласованности будет выбирать те, которые имеют нужное значение? Получается, что поиск по ключу-значению будет всегда медленным, если ключ содерживатся почти во всех записях, верно?
Жалобы присылались в Роскомнадзор, следовательно почту никто не ддосил. И не думаю, что те, кто подавали жалобу преследовали цель довести до отказа сервер.
Тормоза сбербанка онлайн были 2 раза по 5 минут — не критично.
Видимо мне не везет всегда при входе в сбер онлайн, но стабильно из 10 раз примерно раза 4 у меня он не работает.
Когда регистрировал 2ю карту сбера, сказали что в сбере онлайн у меня просто появится еще одна карта и можно будет работать с ними с одного аккаунта. Однако ничего подобного не произошло. Пришлось брать отдельный логин пароль для еще одной карты. Очень удобно.
Не смотря на то, что статья и перевод были написаны довольно давно, надеюсь, кто-то знающий увидит данное сообщение. Сошлюсь на оригинал статьи.
Скажем у нас есть 2 случая. В обоих случаях у нас есть 2 потребителя. В первом случае первый потребляет в 2 раза больше, чем второй, например, т.к. у него больше ресурсов. Во втором случае они потребляют с одинаковой скоростью. Почему во втором случае меньше задержка?
Знаю, что прошло уже много времени, но возник вопрос. Я когда-то для себя решил обратный подход использовать (margin-top/left, а не margin-bottom/right), т.к. если компонента нет, то и отступа нет. Это крайне удобно, когда элементы размещаются в контейнере слева направо, сверху вниз. Если порядок в контейнере обратный, тогда margin-bottom/right.
Подскажите, почему обычно используются margin-right/bottom? Это же неудобно, когда компонент может быть опционален. Но даже если он не опционален, то получится, что в одном месте так, в другом сяк. Поэтому для себя решил еще давно, что именно компонент должен себя отталкивать, как и новый человек в очереди должен сам занять дистанцию от последнего, а не его должны отодвигать.
Полностью согласен. Давно бы уже переехал, если бы ценники не были в 2,5-3 раза дороже. Тут при любом размере сервера встает вопрос зачем столько переплачивать. Возьмем, например, слабенький CX31: 2 VCPU, 8 GB RAM, 80 GB SSD (9.20 евро/мес). У селектел аналогичный стоит 3 936,18 руб/мес (39.85 евро/мес). Даже в 4 раза дороже получается. Я конечно понимаю, что все оборудование привозится, а значит тут оно в любом случае будет дороже, но не в 4 же раза. Особенно, когда подобных серверов не один или используются сервера помощнее. Например, вместо 4-5к ценник будет 16-20к в мес. Поэтому никто и не переезжает, если есть возможность. И это камень в огород не только селектел, а вообще всех, кто здесь предоставляет сервера.
Чтобы подтянуть знания в TypeScript крайне рекомендую выделить пару дней и решить все задачки https://github.com/type-challenges/type-challenges без гугла, максимум с офф докой. Довольно много задачек там крайне интересные и нетривиальные.
Получается нужна база координат/идентификаторов всех вышек? Под идентификатором понимаю какой-то уникальный сигнал от вышки, скажем какие-то первые биты должны быть уникальны для каждой вышки, чтобы можно было распознать рядом с какой вышкой мы находимся.
По-моему, это как раз таки эффективный, простой и быстрый (что еще важнее) способ побороть данную проблему. Думаю, что третьим лицам не так легко получить доступ ко множеству вышек, а если такой кейс будет, то можно будет отследить кто получал доступ к ним и когда, вычислив злоумышленника. Напротив, используя GPS можно легко и достаточно точно прилететь туда, куда нужно. Поэтому искажение GPS выглядит как минимум логичным шагом (+ быстрым и недорогим, по сравнению с другими способами) по крайней мере на время.
Мне одному режет глаза, что у isObject тут лишняя проверка на undefined? `!= null` проверяет не только на null, но и на undefined. Надо бы `!== null`, т.к. следующее условие `typeof val === 'object'` уберет undefined.
Подскажите, можно ли чистить простой электрощеткой (не ультразвуковой) плобмированные зубы и коронки? Сколько не спрашиваю у зубных врачей, половина говорит, что можно, половина, что нельзя.
Может ли пломба и коронка от этого как то расшататься?
И еще возник вопрос по поиску по JSONB. Если структура большинства JSON объектов одинаковая (напр, как в примере во всех объектах есть days_of_week), то получается при поиске по ключу-значению (напр, '{"days_of_week": [5]}') будут всегда в начале выбираться все записи (т.к. у них всех есть ключ days_of_week), а потом функция согласованности будет выбирать те, которые имеют нужное значение? Получается, что поиск по ключу-значению будет всегда медленным, если ключ содерживатся почти во всех записях, верно?
Огромное спасибо за серию статей по индексам! Потрясающе написано.
Подскажите, а почему на второй картинке мы спускаемся в лексему "нек"? Как GIN понимает, что чтобы найти "кудряв", надо опуститься именно в "нек"?
Видимо мне не везет всегда при входе в сбер онлайн, но стабильно из 10 раз примерно раза 4 у меня он не работает.
Когда регистрировал 2ю карту сбера, сказали что в сбере онлайн у меня просто появится еще одна карта и можно будет работать с ними с одного аккаунта. Однако ничего подобного не произошло. Пришлось брать отдельный логин пароль для еще одной карты. Очень удобно.