:) вас, видимо, часто критикуют на других пабликах, что у вас прямо оборонительная позиция)
Причиной могут быть обстоятельства — если только форс-мажорные, что редкость и не о них речь.
Чаще бывает, что это лишь психологический барьер для человека,
который вовсе не является объективной проблемой — всего лишь так мозг человека устроен,
что привязывается к чему-то постоянному, но это постоянное совсем не обязательно
является хорошим предложением рынка (труда в нашем случае).
Поэтому вопреки своему ощущению комфорта всегда следует делать
простые ни к чему не обязывающие исследованица рынка — просматривать какие бывают вакансии и т.п.
У большинства все таки требуется дождаться, когда их урежут в зарплате так, что они офигеют или не будет роста и кризис самоактуализации наступит или какая-то другая крупная проблема, которая прямо таки заставит исследовать рынок.
Так зачем было доводить до стресса, если можно когда все и так вроде бы неплохо
просто ради интереса прощумать рынок.
Об этом же даже говорит ник «i can choose» — у каждого человека должно быть право свободного выбора
Еще не лишним к теме будет дополнить, что часто люди привыкают к комфорту —
есть наработанные связи, зарплата, какое-то взаимопонимание с коллегами и так далее
Если вас достойно оценивает по сравнению с рыночным предложением —
тогда конечно все ок.
Но часто руководитель будет понимать силу такого комфорта
и даже знать, что в действительности вам гораздо легче чем кажется найти более интересную более дорогую работу,
но вы скорее всего даже не попробуете, потому то эти легкие шаги отделены от вас чисто психологическим барьером ничего не менять, «удобно как есть».
Изучаю AngularJS и не смог понять сути, что такое фабрика, сервис и провайдеры, читая эту статью.
Разобрался почему — вещи названы не своими именами, примеры:
«Фабрика это сервис...»
Это не так.
.factory — это не сервис.
.factory — это рецепт (синтаксический сахар), который создает новый сервис из переданной функции.
Источник: docs.angularjs.org/guide/providers
Почему это очень путает новичка? Потому что он видит утверждение «Фабрика — это сервис».
Запоминает.
И потом по ходу вникания в примеры не может сопоставить информацию, обнаруживая противоречия —
так фабрика это сервис или это метод, который создает для нас сервис (привычное понимание фабрики в ООП)
«Провайдер это фабрика, настроенная особым образом.»
Это уже радикальное искажение информации.
Провайдер — это объект, который поставляет экземпляр сервиса:
Providers are objects that provide (create) instances of services and expose configuration APIs that can be used to control the creation and runtime behavior of a service. In case of the $route service, the $routeProvider exposes APIs that allow you to define routes for your application.
После повторного прочтения этой статьи (когда я разобрался в реальном положении вещей и нативной документации),
я вижу, что в описанном есть смысл — автор пытается, упрощая, объяснить суть,
но в итоге здесь информация так искажена, что будет понятна только тому, кто уже разбирается в сути (тогда он мысленно поправит ошибки).
Упрощать информацию — это благая цель. Но не искажайте ее, пожалуйста.
Во имя тех, кто верит хабру и будет пытаться разобраться по вашим статьям,
а не по оригинальной длиной документации.
Можно ло будет открыть 10 неперсонифецированных кошельков и по тысяче перевести 10К?
Хоть гемор, но вариант? Может, даже сервисы появятся, которые автоматизируют такую схему?
Да, согласен. Если имеем такую конфигурацию БД или SLEEP() внутри транзакций, может понадобится дополнительная логика для работы со Sleep-соединениями.
Но бездумно убивать Sleep-запросы нельзя, например их могут создавать «долгоиграющие» php-скрипты выполняющие энкодинг видео и держащие соединение с БД.
Правильно ли, что если у вас всплывает проблема (без багов никто не пишет, это аксиома — правильно?), то вы предлагаете на выбор:
1. Моментально ее решить (пусть хоть в субботу ночью)
2. Не обращать внимание на то, что пока вы будете решать проблему, продакшн будет хромать
3. Выключить продакшн, чтобы пока что как бы не было видно, что у вас баг? :)
Т.е. если есть намеренная блокировка, например бэкапера или генератора кэша — то здесь мы получим пару «подвисших до лучших времен» запросов.
Но если у нас есть намеренная блокировка запросов сотен клиентов, то либо система не очень хорошо спроектирована,
либо это весьма специфическая область, для которой да — подход обозначенный в статье не применим.
Указанное:
> Скрипт полезен в системах, где применяется методология разработки не ставящая целью «преждевременную» оптимизацию всех возможных участков системы,
а где первичная оптимизация производится в очевидных bottleneck-ах, и последующая — в выявляемых в процессе эксплуатации системы.
Продиктовано принципом:
> Предельно отсроченное принятие решений. Решение следует принимать не на основе предположений и прогнозов, а после открытия существенных фактов.
Согласен с тем, что, скажем, в неаджайловых методологиях разработки такие скрипты лучше не применять.
Абсолютно верно: > задуматься о правильности архитектуры вашей системы и поисках решений по ее улучшению.
Собственно
> Скрипт полезен в системах, где применяется методология разработки не ставящая целью «преждевременную» оптимизацию всех возможных участков системы,
а где первичная оптимизация производится в очевидных bottleneck-ах, и последующая — в выявляемых в процессе эксплуатации системы.
Хотя, возможно, у этой утилиты есть ключ «убить вообще все запросы», если достигнуто указанное условие.
Тогда да — она, чуть более грубо, но будет решать ситуацию, связанную с взаимоблокировками.
Это будет убивать каждые 3 секунды все запросы висящие больше 30 секунд, если таковых накопится 15 штук.
И в принципе это решение, вполне неплохое.
Но если подойти к проблеме более детально, то при пике нагрузки обычно случается примерно такое:
1. Появилось 100 запросов за 10 секунд и они повесили друг друга
2. Следующие 20 секунд еще 200 запросов к ним «присоеденились». Теперь у нас 300 взаимоблокирующих запросов
3. Через 30 секунд с начала этой ситуации мы убьем только 100 старших (т.к. только они попадут под условие «старше 30 секунд»)
Но к этому времени у нас уже будет 100 20-секундных и 100 10-секнудных запросов — итого 200 тяжелых запросов, которые «не дают продохнуть» базе данных
Интересная утилита.
Правда, на первый взгляд, она сама не поддерживает сложную логику,
как например «Убить все запросы старше 3 секунд, если в системе обнаружено 15 запросов, висящих дольше 30 секунд»
Безусловно, эту логику можно реализовать в bash скрипте
В статье больше предлагается не скрипт как непосредственный инструмент, а бизнес-логика
Администратор может реализовать приведенный псевдо-код в виде schedule routine, php-скрипта, bash использующего mk-kill и т.п.
> «Некоторые запросы делают lock-и, блокирующие другие запросы»? Вы имеете в виду GET_LOCK()?
Не важно — либо явно лочат командой, либо лочат таблицу за счет долгой выборки из этой таблицы
Тогда механизм не подойдет.
Вообще, несколько странно, если в высоконагруженной системе намеренно предусматриваются запросы блокирующие другие на длительное время.
Причиной могут быть обстоятельства — если только форс-мажорные, что редкость и не о них речь.
Чаще бывает, что это лишь психологический барьер для человека,
который вовсе не является объективной проблемой — всего лишь так мозг человека устроен,
что привязывается к чему-то постоянному, но это постоянное совсем не обязательно
является хорошим предложением рынка (труда в нашем случае).
Поэтому вопреки своему ощущению комфорта всегда следует делать
простые ни к чему не обязывающие исследованица рынка — просматривать какие бывают вакансии и т.п.
У большинства все таки требуется дождаться, когда их урежут в зарплате так, что они офигеют или не будет роста и кризис самоактуализации наступит или какая-то другая крупная проблема, которая прямо таки заставит исследовать рынок.
Так зачем было доводить до стресса, если можно когда все и так вроде бы неплохо
просто ради интереса прощумать рынок.
Об этом же даже говорит ник «i can choose» — у каждого человека должно быть право свободного выбора
есть наработанные связи, зарплата, какое-то взаимопонимание с коллегами и так далее
Если вас достойно оценивает по сравнению с рыночным предложением —
тогда конечно все ок.
Но часто руководитель будет понимать силу такого комфорта
и даже знать, что в действительности вам гораздо легче чем кажется найти более интересную более дорогую работу,
но вы скорее всего даже не попробуете, потому то эти легкие шаги отделены от вас чисто психологическим барьером ничего не менять, «удобно как есть».
Разобрался почему — вещи названы не своими именами, примеры:
«Фабрика это сервис...»
Это не так.
.factory — это не сервис.
.factory — это рецепт (синтаксический сахар), который создает новый сервис из переданной функции.
Источник: docs.angularjs.org/guide/providers
Почему это очень путает новичка? Потому что он видит утверждение «Фабрика — это сервис».
Запоминает.
И потом по ходу вникания в примеры не может сопоставить информацию, обнаруживая противоречия —
так фабрика это сервис или это метод, который создает для нас сервис (привычное понимание фабрики в ООП)
«Провайдер это фабрика, настроенная особым образом.»
Это уже радикальное искажение информации.
Провайдер — это объект, который поставляет экземпляр сервиса:
Источник: docs.angularjs.org/tutorial/step_07
После повторного прочтения этой статьи (когда я разобрался в реальном положении вещей и нативной документации),
я вижу, что в описанном есть смысл — автор пытается, упрощая, объяснить суть,
но в итоге здесь информация так искажена, что будет понятна только тому, кто уже разбирается в сути (тогда он мысленно поправит ошибки).
Упрощать информацию — это благая цель. Но не искажайте ее, пожалуйста.
Во имя тех, кто верит хабру и будет пытаться разобраться по вашим статьям,
а не по оригинальной длиной документации.
> Кому же все должны? Очевидно — друг другу.
Более вероятно, что отстающие должны впереди идущим.
Хоть гемор, но вариант? Может, даже сервисы появятся, которые автоматизируют такую схему?
Но бездумно убивать Sleep-запросы нельзя, например их могут создавать «долгоиграющие» php-скрипты выполняющие энкодинг видео и держащие соединение с БД.
Правильно ли, что если у вас всплывает проблема (без багов никто не пишет, это аксиома — правильно?), то вы предлагаете на выбор:
1. Моментально ее решить (пусть хоть в субботу ночью)
2. Не обращать внимание на то, что пока вы будете решать проблему, продакшн будет хромать
3. Выключить продакшн, чтобы пока что как бы не было видно, что у вас баг? :)
Но если у нас есть намеренная блокировка запросов сотен клиентов, то либо система не очень хорошо спроектирована,
либо это весьма специфическая область, для которой да — подход обозначенный в статье не применим.
Это для методологии Lean software development
Ну и доработан американцами (Lean software development):
ru.wikipedia.org/wiki/Бережливая_разработка_программного_обеспечения
Указанное:
> Скрипт полезен в системах, где применяется методология разработки не ставящая целью «преждевременную» оптимизацию всех возможных участков системы,
а где первичная оптимизация производится в очевидных bottleneck-ах, и последующая — в выявляемых в процессе эксплуатации системы.
Продиктовано принципом:
> Предельно отсроченное принятие решений. Решение следует принимать не на основе предположений и прогнозов, а после открытия существенных фактов.
Согласен с тем, что, скажем, в неаджайловых методологиях разработки такие скрипты лучше не применять.
Собственно
> Скрипт полезен в системах, где применяется методология разработки не ставящая целью «преждевременную» оптимизацию всех возможных участков системы,
а где первичная оптимизация производится в очевидных bottleneck-ах, и последующая — в выявляемых в процессе эксплуатации системы.
Шаг (2) алгоритма преследует эту цель
Тогда да — она, чуть более грубо, но будет решать ситуацию, связанную с взаимоблокировками.
И в принципе это решение, вполне неплохое.
Но если подойти к проблеме более детально, то при пике нагрузки обычно случается примерно такое:
1. Появилось 100 запросов за 10 секунд и они повесили друг друга
2. Следующие 20 секунд еще 200 запросов к ним «присоеденились». Теперь у нас 300 взаимоблокирующих запросов
3. Через 30 секунд с начала этой ситуации мы убьем только 100 старших (т.к. только они попадут под условие «старше 30 секунд»)
Но к этому времени у нас уже будет 100 20-секундных и 100 10-секнудных запросов — итого 200 тяжелых запросов, которые «не дают продохнуть» базе данных
Правда, на первый взгляд, она сама не поддерживает сложную логику,
как например «Убить все запросы старше 3 секунд, если в системе обнаружено 15 запросов, висящих дольше 30 секунд»
Безусловно, эту логику можно реализовать в bash скрипте
В статье больше предлагается не скрипт как непосредственный инструмент, а бизнес-логика
Администратор может реализовать приведенный псевдо-код в виде schedule routine, php-скрипта, bash использующего mk-kill и т.п.
Не важно — либо явно лочат командой, либо лочат таблицу за счет долгой выборки из этой таблицы
Вообще, несколько странно, если в высоконагруженной системе намеренно предусматриваются запросы блокирующие другие на длительное время.