Спасибо, очень приятно.
С раскрытием всего исходного кода есть небольшое осложнение. Дело в том, что моя разработка, как и всё что я делаю в рабочее время, принадлежит компании. Пытаюсь согласовать публикацию под LGPL или чем-то похожим, но потребуется время и добрая воля руководства чтобы это осуществилось.
Спасибо.
Однако, непонятно что Вы имеете ввиду, ссылаясь на этот продукт. Исходную задачу он не решает. Да и практическое применение, вот так сходу, придумать у меня не получилось. Возможно я что-то упускаю…
Добрый день.
Спасибо за вопрос.
Согласен, утверждение про Capacity management можно назвать спорным. Однако, мы здесь опять сталкиваемся с неопределённостью в определении что есть «оптимальная (или допустимая) производительность». Насколько медленно должно работать приложение, чтобы бизнес счёл его недоступным? Предоставляя средства оперативного мониторинга производительности мы можем определить эти границы в свих метриках и далее использовать их том числе и для Availability management.
В своей работе мне приходится сталкиваться с ситуациями, когда команды поддержки устраняют (ну или думают что устраняют) проблемы с производительностью своих приложений при помощи хаотического увеличения мощностей инфраструктуры. Это, как правило, не даёт желаемого результата или приводит лишь к временному облегчению. APA анализ помогает обнаружить наиболее оптимальные и дешёвые средства устранения проблем: изменение настроек приложения или его кода, оптимизация инфраструктуры. Многие рекомендации APA можно лишь с большой натяжкой отнести к области capacity management.
Конечно же, мы анализируем и логи, но в нашей практике они, как правило, не сильно помогают. Логи хороши, если что-то совсем не работает. Подавляющее большинство производителей приложений не предоставляют достаточное логирование проблем с производительностью. Могу также сказать, что если проблема может хоть как-то идентифицироваться в логах – ко мне не приходят, однако, без работы я не сижу.
С раскрытием всего исходного кода есть небольшое осложнение. Дело в том, что моя разработка, как и всё что я делаю в рабочее время, принадлежит компании. Пытаюсь согласовать публикацию под LGPL или чем-то похожим, но потребуется время и добрая воля руководства чтобы это осуществилось.
Однако, непонятно что Вы имеете ввиду, ссылаясь на этот продукт. Исходную задачу он не решает. Да и практическое применение, вот так сходу, придумать у меня не получилось. Возможно я что-то упускаю…
Не думаю, что это допустимо на данном ресурсе. Явное упоминание названия продукта или его производителя может трактоваться как реклама.
Спасибо за вопрос.
Согласен, утверждение про Capacity management можно назвать спорным. Однако, мы здесь опять сталкиваемся с неопределённостью в определении что есть «оптимальная (или допустимая) производительность». Насколько медленно должно работать приложение, чтобы бизнес счёл его недоступным? Предоставляя средства оперативного мониторинга производительности мы можем определить эти границы в свих метриках и далее использовать их том числе и для Availability management.
В своей работе мне приходится сталкиваться с ситуациями, когда команды поддержки устраняют (ну или думают что устраняют) проблемы с производительностью своих приложений при помощи хаотического увеличения мощностей инфраструктуры. Это, как правило, не даёт желаемого результата или приводит лишь к временному облегчению. APA анализ помогает обнаружить наиболее оптимальные и дешёвые средства устранения проблем: изменение настроек приложения или его кода, оптимизация инфраструктуры. Многие рекомендации APA можно лишь с большой натяжкой отнести к области capacity management.
Конечно же, мы анализируем и логи, но в нашей практике они, как правило, не сильно помогают. Логи хороши, если что-то совсем не работает. Подавляющее большинство производителей приложений не предоставляют достаточное логирование проблем с производительностью. Могу также сказать, что если проблема может хоть как-то идентифицироваться в логах – ко мне не приходят, однако, без работы я не сижу.