#производительность — Public Fediverse posts

Как избежать утечек памяти во Flutter

Утечки памяти — одна из тех проблем, которые долго могут оставаться незаметными в мобильном приложении, а затем приводить к росту потребления ресурсов, снижению производительности и нестабильной работе интерфейса. Чаще всего причиной становятся ошибки в управлении жизненным циклом объектов, подписок и контроллеров. В данной статье рассмотрим, какие ошибки чаще всего приводят к утечкам памяти во Flutter, как их обнаруживать и какие практики помогают избежать подобных проблем в реальных проектах.

https://habr.com/ru/articles/1035256/

#Flutter #memory_leaks #утечки_памяти #dispose #Flutter_DevTools #StreamSubscription #state_management #tracker #производительность

Как избежать утечек памяти во Flutter

Утечки памяти — одна из тех проблем, которые долго могут оставаться незаметными в мобильном приложении, а затем приводить к росту потребления ресурсов, снижению производительности и нестабильной работе интерфейса. Чаще всего причиной становятся ошибки в управлении жизненным циклом объектов, подписок и контроллеров. В данной статье рассмотрим, какие ошибки чаще всего приводят к утечкам памяти во Flutter, как их обнаруживать и какие практики помогают избежать подобных проблем в реальных проектах.

https://habr.com/ru/articles/1035256/

#Flutter #memory_leaks #утечки_памяти #dispose #Flutter_DevTools #StreamSubscription #state_management #tracker #производительность

Как избежать утечек памяти во Flutter

Утечки памяти — одна из тех проблем, которые долго могут оставаться незаметными в мобильном приложении, а затем приводить к росту потребления ресурсов, снижению производительности и нестабильной работе интерфейса. Чаще всего причиной становятся ошибки в управлении жизненным циклом объектов, подписок и контроллеров. В данной статье рассмотрим, какие ошибки чаще всего приводят к утечкам памяти во Flutter, как их обнаруживать и какие практики помогают избежать подобных проблем в реальных проектах.

https://habr.com/ru/articles/1035256/

#Flutter #memory_leaks #утечки_памяти #dispose #Flutter_DevTools #StreamSubscription #state_management #tracker #производительность

Как избежать утечек памяти во Flutter

Утечки памяти — одна из тех проблем, которые долго могут оставаться незаметными в мобильном приложении, а затем приводить к росту потребления ресурсов, снижению производительности и нестабильной работе интерфейса. Чаще всего причиной становятся ошибки в управлении жизненным циклом объектов, подписок и контроллеров. В данной статье рассмотрим, какие ошибки чаще всего приводят к утечкам памяти во Flutter, как их обнаруживать и какие практики помогают избежать подобных проблем в реальных проектах.

https://habr.com/ru/articles/1035256/

#Flutter #memory_leaks #утечки_памяти #dispose #Flutter_DevTools #StreamSubscription #state_management #tracker #производительность

Почему ваш Go‑сервис ломается под 1000 RPS и как найти узкое место за полчаса

Go-сервис может идеально проходить функциональные тесты и уверенно отвечать на локальных прогонах, а потом внезапно развалиться под 1000 RPS: p99 улетает в секунды, в логах появляются таймауты, throughput проседает, а часть запросов вообще не получает HTTP-ответа. В статье разберём, как подойти к такой деградации без гадания: прогнать нагрузку через vegeta и wrk2, правильно прочитать p50/p99 и status codes, проверить пул соединений к базе, настройки HTTP-клиента, горутины, GC, таймауты и быстро понять, где именно сервис начинает терять устойчивость.

https://habr.com/ru/companies/otus/articles/1031438/

#Go #нагрузочное_тестирование #backend #микросервисы #p99 #latency #vegeta #wrk2 #pprof #производительность

Почему ваш Go‑сервис ломается под 1000 RPS и как найти узкое место за полчаса

Go-сервис может идеально проходить функциональные тесты и уверенно отвечать на локальных прогонах, а потом внезапно развалиться под 1000 RPS: p99 улетает в секунды, в логах появляются таймауты, throughput проседает, а часть запросов вообще не получает HTTP-ответа. В статье разберём, как подойти к такой деградации без гадания: прогнать нагрузку через vegeta и wrk2, правильно прочитать p50/p99 и status codes, проверить пул соединений к базе, настройки HTTP-клиента, горутины, GC, таймауты и быстро понять, где именно сервис начинает терять устойчивость.

https://habr.com/ru/companies/otus/articles/1031438/

#Go #нагрузочное_тестирование #backend #микросервисы #p99 #latency #vegeta #wrk2 #pprof #производительность

Почему ваш Go‑сервис ломается под 1000 RPS и как найти узкое место за полчаса

Go-сервис может идеально проходить функциональные тесты и уверенно отвечать на локальных прогонах, а потом внезапно развалиться под 1000 RPS: p99 улетает в секунды, в логах появляются таймауты, throughput проседает, а часть запросов вообще не получает HTTP-ответа. В статье разберём, как подойти к такой деградации без гадания: прогнать нагрузку через vegeta и wrk2, правильно прочитать p50/p99 и status codes, проверить пул соединений к базе, настройки HTTP-клиента, горутины, GC, таймауты и быстро понять, где именно сервис начинает терять устойчивость.

https://habr.com/ru/companies/otus/articles/1031438/

#Go #нагрузочное_тестирование #backend #микросервисы #p99 #latency #vegeta #wrk2 #pprof #производительность

Почему ваш Go‑сервис ломается под 1000 RPS и как найти узкое место за полчаса

Go-сервис может идеально проходить функциональные тесты и уверенно отвечать на локальных прогонах, а потом внезапно развалиться под 1000 RPS: p99 улетает в секунды, в логах появляются таймауты, throughput проседает, а часть запросов вообще не получает HTTP-ответа. В статье разберём, как подойти к такой деградации без гадания: прогнать нагрузку через vegeta и wrk2, правильно прочитать p50/p99 и status codes, проверить пул соединений к базе, настройки HTTP-клиента, горутины, GC, таймауты и быстро понять, где именно сервис начинает терять устойчивость.

https://habr.com/ru/companies/otus/articles/1031438/

#Go #нагрузочное_тестирование #backend #микросервисы #p99 #latency #vegeta #wrk2 #pprof #производительность

Без рук: автоматизируем нагрузочное тестирование изменений в CI

Нагрузочное тестирование — одна из самых избегаемых тем, когда речь заходит о контроле качества ПО. Корпорации, конечно, не обходят его стороной, но если говорить о продуктах меньшего масштаба, то нагрузочное тестирование часто пропускается. Команда (и, в целом, справедливо) полагает, что продукт справится с нагрузкой — на малых объёмах это обычно прокатывает. А потом внезапно наступает день, когда пользователей стало больше, а система не готова. Почему команды не тащат нагрузку в релизный цикл? Потому что это чаще всего просто не окупается: нужно выбрать движок, описать сценарий, гонять тесты вручную или тратить время на создание собственной обвязки для встраивания в CI, придумать критерии качества и анализировать результаты. Всё это занимает значительное время, а на короткой дистанции часто оказывается оверинжинирингом. Но если формирование требований упростить концептуально невозможно, то всё остальное вполне можно собрать в переиспользуемый инструмент, позволяющий командам легко интегрировать нагрузочное тестирование и регрессионный анализ в свой процесс доставки. В CI/CD мы хотели простую штуку: на каждый PR запускать короткий перф‑смоук и получать ответ уровня «PASS / WARNING / DEGRADATION», а не 15 минут медитировать над CSV и тратить ценное время на анализ, который, вероятно, не пригодится в ближайшей перспективе. Посмотрим, к чему мы в итоге пришли.

https://habr.com/ru/articles/1033590/

#нагрузочное_тестирование #регрессионное_тестирование #locust #devops #locomotive #python #github_actions #performance_testing #cicd #производительность

Без рук: автоматизируем нагрузочное тестирование изменений в CI

Нагрузочное тестирование — одна из самых избегаемых тем, когда речь заходит о контроле качества ПО. Корпорации, конечно, не обходят его стороной, но если говорить о продуктах меньшего масштаба, то нагрузочное тестирование часто пропускается. Команда (и, в целом, справедливо) полагает, что продукт справится с нагрузкой — на малых объёмах это обычно прокатывает. А потом внезапно наступает день, когда пользователей стало больше, а система не готова. Почему команды не тащат нагрузку в релизный цикл? Потому что это чаще всего просто не окупается: нужно выбрать движок, описать сценарий, гонять тесты вручную или тратить время на создание собственной обвязки для встраивания в CI, придумать критерии качества и анализировать результаты. Всё это занимает значительное время, а на короткой дистанции часто оказывается оверинжинирингом. Но если формирование требований упростить концептуально невозможно, то всё остальное вполне можно собрать в переиспользуемый инструмент, позволяющий командам легко интегрировать нагрузочное тестирование и регрессионный анализ в свой процесс доставки. В CI/CD мы хотели простую штуку: на каждый PR запускать короткий перф‑смоук и получать ответ уровня «PASS / WARNING / DEGRADATION», а не 15 минут медитировать над CSV и тратить ценное время на анализ, который, вероятно, не пригодится в ближайшей перспективе. Посмотрим, к чему мы в итоге пришли.

https://habr.com/ru/articles/1033590/

#нагрузочное_тестирование #регрессионное_тестирование #locust #devops #locomotive #python #github_actions #performance_testing #cicd #производительность

Без рук: автоматизируем нагрузочное тестирование изменений в CI

Нагрузочное тестирование — одна из самых избегаемых тем, когда речь заходит о контроле качества ПО. Корпорации, конечно, не обходят его стороной, но если говорить о продуктах меньшего масштаба, то нагрузочное тестирование часто пропускается. Команда (и, в целом, справедливо) полагает, что продукт справится с нагрузкой — на малых объёмах это обычно прокатывает. А потом внезапно наступает день, когда пользователей стало больше, а система не готова. Почему команды не тащат нагрузку в релизный цикл? Потому что это чаще всего просто не окупается: нужно выбрать движок, описать сценарий, гонять тесты вручную или тратить время на создание собственной обвязки для встраивания в CI, придумать критерии качества и анализировать результаты. Всё это занимает значительное время, а на короткой дистанции часто оказывается оверинжинирингом. Но если формирование требований упростить концептуально невозможно, то всё остальное вполне можно собрать в переиспользуемый инструмент, позволяющий командам легко интегрировать нагрузочное тестирование и регрессионный анализ в свой процесс доставки. В CI/CD мы хотели простую штуку: на каждый PR запускать короткий перф‑смоук и получать ответ уровня «PASS / WARNING / DEGRADATION», а не 15 минут медитировать над CSV и тратить ценное время на анализ, который, вероятно, не пригодится в ближайшей перспективе. Посмотрим, к чему мы в итоге пришли.

https://habr.com/ru/articles/1033590/

#нагрузочное_тестирование #регрессионное_тестирование #locust #devops #locomotive #python #github_actions #performance_testing #cicd #производительность

Без рук: автоматизируем нагрузочное тестирование изменений в CI

Нагрузочное тестирование — одна из самых избегаемых тем, когда речь заходит о контроле качества ПО. Корпорации, конечно, не обходят его стороной, но если говорить о продуктах меньшего масштаба, то нагрузочное тестирование часто пропускается. Команда (и, в целом, справедливо) полагает, что продукт справится с нагрузкой — на малых объёмах это обычно прокатывает. А потом внезапно наступает день, когда пользователей стало больше, а система не готова. Почему команды не тащат нагрузку в релизный цикл? Потому что это чаще всего просто не окупается: нужно выбрать движок, описать сценарий, гонять тесты вручную или тратить время на создание собственной обвязки для встраивания в CI, придумать критерии качества и анализировать результаты. Всё это занимает значительное время, а на короткой дистанции часто оказывается оверинжинирингом. Но если формирование требований упростить концептуально невозможно, то всё остальное вполне можно собрать в переиспользуемый инструмент, позволяющий командам легко интегрировать нагрузочное тестирование и регрессионный анализ в свой процесс доставки. В CI/CD мы хотели простую штуку: на каждый PR запускать короткий перф‑смоук и получать ответ уровня «PASS / WARNING / DEGRADATION», а не 15 минут медитировать над CSV и тратить ценное время на анализ, который, вероятно, не пригодится в ближайшей перспективе. Посмотрим, к чему мы в итоге пришли.

https://habr.com/ru/articles/1033590/

#нагрузочное_тестирование #регрессионное_тестирование #locust #devops #locomotive #python #github_actions #performance_testing #cicd #производительность

Как я сделал трёхуровневый кэш сообщений в мессенджере на React Native — и что узнал по дороге

Я делаю мессенджер ONEMIX на React Native. К моменту, когда я начал писать этот пост, в нём уже больше десятка экранов, групповые WebRTC-звонки через LiveKit, E2E на Double Ratchet + Sealed Sender, push-нотификации с cold-start навигацией и десктоп-версия на Electron. Но самым важным куском, который определяет ощущение от приложения, оказался не звук и не видео. А то, насколько быстро открывается чат. Если вы хоть раз делали список сообщений на React Native, вы знаете эту боль: открыл чат — пустой экран на 200–800 мс, потом подгрузка, потом скачок при докрутке наверх. В Telegram такого не бывает: открыл — мгновенно увидел последние сообщения, прокрутил наверх — никаких пустот, история идёт сплошной лентой. Я разбирался с этим несколько месяцев. В итоге пришёл к трёхуровневой архитектуре кэша, которую и хочу разобрать. Это не теория — это код, который сейчас работает в продакшне. Покажу как реализовано, какие были тупики и какие решения оказались критичными.

https://habr.com/ru/articles/1033502/

#react_native #sqlite #кэширование #expo #мессенджер #drizzle_orm #мобильная_разработка #производительность #архитектура #telegram

Как я сделал трёхуровневый кэш сообщений в мессенджере на React Native — и что узнал по дороге

Я делаю мессенджер ONEMIX на React Native. К моменту, когда я начал писать этот пост, в нём уже больше десятка экранов, групповые WebRTC-звонки через LiveKit, E2E на Double Ratchet + Sealed Sender, push-нотификации с cold-start навигацией и десктоп-версия на Electron. Но самым важным куском, который определяет ощущение от приложения, оказался не звук и не видео. А то, насколько быстро открывается чат. Если вы хоть раз делали список сообщений на React Native, вы знаете эту боль: открыл чат — пустой экран на 200–800 мс, потом подгрузка, потом скачок при докрутке наверх. В Telegram такого не бывает: открыл — мгновенно увидел последние сообщения, прокрутил наверх — никаких пустот, история идёт сплошной лентой. Я разбирался с этим несколько месяцев. В итоге пришёл к трёхуровневой архитектуре кэша, которую и хочу разобрать. Это не теория — это код, который сейчас работает в продакшне. Покажу как реализовано, какие были тупики и какие решения оказались критичными.

https://habr.com/ru/articles/1033502/

#react_native #sqlite #кэширование #expo #мессенджер #drizzle_orm #мобильная_разработка #производительность #архитектура #telegram

Как я сделал трёхуровневый кэш сообщений в мессенджере на React Native — и что узнал по дороге

Я делаю мессенджер ONEMIX на React Native. К моменту, когда я начал писать этот пост, в нём уже больше десятка экранов, групповые WebRTC-звонки через LiveKit, E2E на Double Ratchet + Sealed Sender, push-нотификации с cold-start навигацией и десктоп-версия на Electron. Но самым важным куском, который определяет ощущение от приложения, оказался не звук и не видео. А то, насколько быстро открывается чат. Если вы хоть раз делали список сообщений на React Native, вы знаете эту боль: открыл чат — пустой экран на 200–800 мс, потом подгрузка, потом скачок при докрутке наверх. В Telegram такого не бывает: открыл — мгновенно увидел последние сообщения, прокрутил наверх — никаких пустот, история идёт сплошной лентой. Я разбирался с этим несколько месяцев. В итоге пришёл к трёхуровневой архитектуре кэша, которую и хочу разобрать. Это не теория — это код, который сейчас работает в продакшне. Покажу как реализовано, какие были тупики и какие решения оказались критичными.

https://habr.com/ru/articles/1033502/

#react_native #sqlite #кэширование #expo #мессенджер #drizzle_orm #мобильная_разработка #производительность #архитектура #telegram

Как я сделал трёхуровневый кэш сообщений в мессенджере на React Native — и что узнал по дороге

Я делаю мессенджер ONEMIX на React Native. К моменту, когда я начал писать этот пост, в нём уже больше десятка экранов, групповые WebRTC-звонки через LiveKit, E2E на Double Ratchet + Sealed Sender, push-нотификации с cold-start навигацией и десктоп-версия на Electron. Но самым важным куском, который определяет ощущение от приложения, оказался не звук и не видео. А то, насколько быстро открывается чат. Если вы хоть раз делали список сообщений на React Native, вы знаете эту боль: открыл чат — пустой экран на 200–800 мс, потом подгрузка, потом скачок при докрутке наверх. В Telegram такого не бывает: открыл — мгновенно увидел последние сообщения, прокрутил наверх — никаких пустот, история идёт сплошной лентой. Я разбирался с этим несколько месяцев. В итоге пришёл к трёхуровневой архитектуре кэша, которую и хочу разобрать. Это не теория — это код, который сейчас работает в продакшне. Покажу как реализовано, какие были тупики и какие решения оказались критичными.

https://habr.com/ru/articles/1033502/

#react_native #sqlite #кэширование #expo #мессенджер #drizzle_orm #мобильная_разработка #производительность #архитектура #telegram

Убивает ли ваша деструктуризация производительность?

Я давно хотел написать статью или пост на эту тему, поскольку заметил проблему с некорректным пониманием синтаксиса так называемой «деструктуризации» в JavaScript. Эта информация будет особенно интересна разработчикам, использующим React , где деструктуризация (например, в хуке useState ) встречается повсеместно.

https://habr.com/ru/articles/966268/

#javascript #v8 #производительность #код #деструктуризация_объекта #оптимизация

[Перевод] 10 приёмов профессионала для ускорения кода на Python

Команда Python for Devs подготовила перевод статьи о том, как делать код на Python быстрее без переписывания проектов с нуля. В статье 10 практичных приёмов — от sets и bisect до локальных функций и предвыделения памяти — которые дают реальный прирост скорости в типовых сценариях.

https://habr.com/ru/articles/969848/

#python #оптимизация #оптимизация_кода #производительность #sets #bisect #itertools #память #циклы #скорость

Вы неправильно используете clone() в Rust

clone() в Rust часто появляется в коде в тот момент, когда borrow checker снова «мешает просто дописать фичу». Компилятор успокаивается, задача закрывается, но в проекте постепенно накапливаются лишние копирования, аллокации и API, которые требуют владения там, где хватило бы ссылки. В статье разберём типичные места, где clone() используют как затычку: от Vec и String до замыканий, HashMap и многопоточного кода.

https://habr.com/ru/companies/otus/articles/1029174/

#Rust #clone #borrow_checker #владение #заимствование #аллокации #производительность #HashMap #Arc #Rc

Вы неправильно используете clone() в Rust

clone() в Rust часто появляется в коде в тот момент, когда borrow checker снова «мешает просто дописать фичу». Компилятор успокаивается, задача закрывается, но в проекте постепенно накапливаются лишние копирования, аллокации и API, которые требуют владения там, где хватило бы ссылки. В статье разберём типичные места, где clone() используют как затычку: от Vec и String до замыканий, HashMap и многопоточного кода.

https://habr.com/ru/companies/otus/articles/1029174/

#Rust #clone #borrow_checker #владение #заимствование #аллокации #производительность #HashMap #Arc #Rc

Вы неправильно используете clone() в Rust

clone() в Rust часто появляется в коде в тот момент, когда borrow checker снова «мешает просто дописать фичу». Компилятор успокаивается, задача закрывается, но в проекте постепенно накапливаются лишние копирования, аллокации и API, которые требуют владения там, где хватило бы ссылки. В статье разберём типичные места, где clone() используют как затычку: от Vec и String до замыканий, HashMap и многопоточного кода.

https://habr.com/ru/companies/otus/articles/1029174/

#Rust #clone #borrow_checker #владение #заимствование #аллокации #производительность #HashMap #Arc #Rc

Вы неправильно используете clone() в Rust

clone() в Rust часто появляется в коде в тот момент, когда borrow checker снова «мешает просто дописать фичу». Компилятор успокаивается, задача закрывается, но в проекте постепенно накапливаются лишние копирования, аллокации и API, которые требуют владения там, где хватило бы ссылки. В статье разберём типичные места, где clone() используют как затычку: от Vec и String до замыканий, HashMap и многопоточного кода.

https://habr.com/ru/companies/otus/articles/1029174/

#Rust #clone #borrow_checker #владение #заимствование #аллокации #производительность #HashMap #Arc #Rc

Теперь готовлю только так: перенос Drupal 8 в Kubernetes

В новой статье делимся опытом переноса пачки новостных сайтов на Drupal 8 в Kubernetes. Узнайте, почему просто перенести Drupal в Kubernetes — плохая идея. И как избежать переплаты за ресурсы. Мы также расскажем, как werf помогла автоматизировать сборку Docker-образов и упростить CI/CD, как правильно организовать CronJobs в Kubernetes, чтобы они не влияли на работоспособность системы, и поделимся секретами кэширования Redis и nginx для увеличения производительности Drupal 8 в разы.

https://habr.com/ru/companies/oleg-bunin/articles/885596/

#drupal #кубернетис #производительность #redis #кэширование #nginx #scaling #cronjob #защита_от_ddos #неконсистентность

Как мы отслеживаем производительность веб-сервисов, или Дело «Скорости»

Салют, Хабр! Я Паша, вхожу в группу обеспечения производительности интерфейсов. Эту статью мы написали с Сергеем @TrueNort — руководителем группы. В SberDevices её называют командой «Скорость». Под надзором «Скорости» более двадцати веб-сервисов, каждый из которых должен работать быстро и точно. А значит, нужна система мониторинга производительности с гибкими настройками, чуткой реакцией на изменения и оперативными сообщениями о проблемах. В статье расскажем, зачем мы нормируем метрики логарифмами, как скрипт превращает данные из ClickHouse в алёрты и как удобнее отображать данные. Словом, поделимся нашим опытом контроля производительности веб-ресурсов.

https://habr.com/ru/companies/sberdevices/articles/1006020/

#sber #вебресурсы #Grafana #ClickHouse #GigaChat #фронтенд #производительность #Core_Web_Vitals

Как мы отслеживаем производительность веб-сервисов, или Дело «Скорости»

Салют, Хабр! Я Паша, вхожу в группу обеспечения производительности интерфейсов. Эту статью мы написали с Сергеем @TrueNort — руководителем группы. В SberDevices её называют командой «Скорость». Под надзором «Скорости» более двадцати веб-сервисов, каждый из которых должен работать быстро и точно. А значит, нужна система мониторинга производительности с гибкими настройками, чуткой реакцией на изменения и оперативными сообщениями о проблемах. В статье расскажем, зачем мы нормируем метрики логарифмами, как скрипт превращает данные из ClickHouse в алёрты и как удобнее отображать данные. Словом, поделимся нашим опытом контроля производительности веб-ресурсов.

https://habr.com/ru/companies/sberdevices/articles/1006020/

#sber #вебресурсы #Grafana #ClickHouse #GigaChat #фронтенд #производительность #Core_Web_Vitals

Как мы отслеживаем производительность веб-сервисов, или Дело «Скорости»

Салют, Хабр! Я Паша, вхожу в группу обеспечения производительности интерфейсов. Эту статью мы написали с Сергеем @TrueNort — руководителем группы. В SberDevices её называют командой «Скорость». Под надзором «Скорости» более двадцати веб-сервисов, каждый из которых должен работать быстро и точно. А значит, нужна система мониторинга производительности с гибкими настройками, чуткой реакцией на изменения и оперативными сообщениями о проблемах. В статье расскажем, зачем мы нормируем метрики логарифмами, как скрипт превращает данные из ClickHouse в алёрты и как удобнее отображать данные. Словом, поделимся нашим опытом контроля производительности веб-ресурсов.

https://habr.com/ru/companies/sberdevices/articles/1006020/

#sber #вебресурсы #Grafana #ClickHouse #GigaChat #фронтенд #производительность #Core_Web_Vitals

Как мы отслеживаем производительность веб-сервисов, или Дело «Скорости»

Салют, Хабр! Я Паша, вхожу в группу обеспечения производительности интерфейсов. Эту статью мы написали с Сергеем @TrueNort — руководителем группы. В SberDevices её называют командой «Скорость». Под надзором «Скорости» более двадцати веб-сервисов, каждый из которых должен работать быстро и точно. А значит, нужна система мониторинга производительности с гибкими настройками, чуткой реакцией на изменения и оперативными сообщениями о проблемах. В статье расскажем, зачем мы нормируем метрики логарифмами, как скрипт превращает данные из ClickHouse в алёрты и как удобнее отображать данные. Словом, поделимся нашим опытом контроля производительности веб-ресурсов.

https://habr.com/ru/companies/sberdevices/articles/1006020/

#sber #вебресурсы #Grafana #ClickHouse #GigaChat #фронтенд #производительность #Core_Web_Vitals

TAPe‑детекция против COCO и SOTA: как мы обошли RF‑DETR и YOLO, с легкостью уложившись в 100k параметров (вместо 100M)

Мы довели TAPe‑детекцию на COCO до уровня лучших SOTA‑моделей по точности, но с двумя порядками выигрыша по параметрам и радикально меньшими требованиями к данным и ресурсам. При этом модель держит 7–8 мс на изображение при mAP50 на уровне RF‑DETR‑2XL и работает почти одинаково быстро на GPU и CPU. В этом финальном посте нашего "дневника" мы подведем итоги эксперимента, покажем ключевые бенчмарки и объясним, почему TAPe‑подход позволяет реально экономить данные, железо и время разработки. В итоговой детекционной модели у нас меньше 100 000 параметров — примерно в 10 раз меньше, чем у ближайших «облегчённых» моделей уровня YOLO, и примерно в 1000 раз меньше, чем у сильных DETR‑подходов вроде RF‑DETR с 127 млн параметров. Прикоснуться к магии

https://habr.com/ru/articles/1023426/

#компьютерное_зрение #машинное_обучение #обнаружение_объектов #COCO #yolo #tape+ml #rfdetr #нейросети #аннотация_данных #производительность

Оценка потенциальной производительности информационных систем на задачах OLTP

Все мы сегодня наблюдаем неприятное явление деградации эффективности ПО. Эффективность проседает во всём, от неэффективного пользовательского интерфейса и до того, в чём компьютеры, вроде бы, просто обязаны быть самыми быстрыми, то есть в массовых задачах повседневной обработки информации. Решение задачи повышения производительности ПО не может быть получено без понимания, а на что мы в принципе можем рассчитывать? Именно такую отправную точку и предлагается рассмотреть в данном тексте. Далее показаны потенциальные возможности ПО на самых массовых на сегодня задачах, заключающихся во взаимодействии оператора с информационными системами. Англоязычное название этой группы задач - on-line transaction processing (OLTP). К этому классу, в том числе, относится всё взаимодействие с браузером, которые представляют клиентскую часть системы. За кадром, невидимая для операторов, остаётся почти чистая задача параллельной обработки множества запросов.

https://habr.com/ru/articles/789074/

#производительность #эффективность #oltp

Оценка потенциальной производительности информационных систем на задачах OLTP

Все мы сегодня наблюдаем неприятное явление деградации эффективности ПО. Эффективность проседает во всём, от неэффективного пользовательского интерфейса и до того, в чём компьютеры, вроде бы, просто обязаны быть самыми быстрыми, то есть в массовых задачах повседневной обработки информации. Решение задачи повышения производительности ПО не может быть получено без понимания, а на что мы в принципе можем рассчитывать? Именно такую отправную точку и предлагается рассмотреть в данном тексте. Далее показаны потенциальные возможности ПО на самых массовых на сегодня задачах, заключающихся во взаимодействии оператора с информационными системами. Англоязычное название этой группы задач - on-line transaction processing (OLTP). К этому классу, в том числе, относится всё взаимодействие с браузером, которые представляют клиентскую часть системы. За кадром, невидимая для операторов, остаётся почти чистая задача параллельной обработки множества запросов.

https://habr.com/ru/articles/789074/

#производительность #эффективность #oltp

[Перевод] 5 ключевых изменений в Python 3.14 глазами инженера

Команда Python for Devs подготовила перевод статьи о ключевых изменениях в Python 3.14. Автор разбирает релиз через призму внутреннего устройства интерпретатора и производительности: свободная многопоточность, конкурентные интерпретаторы, удалённая отладка, инкрементальная сборка мусора и новый Tail Calling интерпретатор.

https://habr.com/ru/articles/978836/

#cpython #gil #производительность #интерпретатор #байткод

[Перевод] Python 3.14 без GIL: что это значит для веб-разработки

Команда Python for Devs подготовила перевод статьи о том, как "free-threaded" Python меняет правила игры для веб-сервисов. Автор сравнивает Python 3.14 с GIL и без него на реальных ASGI и WSGI приложениях — и приходит к неожиданному выводу: несмотря на локальные просадки в производительности, "free-threaded" Python уже сейчас может упростить масштабирование и снизить накладные расходы.

https://habr.com/ru/articles/967244/

#Python #GIL #freethreading #вебсервисы #ASGI #WSGI #производительность #конкурентность #Granian #FastAPI

[Перевод] Почему Python такой медленный? И вот что об этом думают эксперты

Команда Python for Devs подготовила перевод статьи о том, почему Python так медленный и что сообщество делает, чтобы это исправить. PyCon 2024 показал: Python ждут субинтерпретаторы, immortal objects, JIT-компиляция и другие технологии, которые могут ускорить его в разы.

https://habr.com/ru/articles/948858/

#python #производительность #gil #субинтерпретаторы #cython #jit #типизация #оптимизация #многопоточность #pycon

CSS-in-JS vs CSS Modules: что выбрать в 2026?

В 2026 году фронтенд-разработка продолжает развиваться: появляются новые фреймворки, улучшаются инструменты сборки, растут требования к производительности и пользовательскому опыту. Разработчики сталкиваются с выбором: использовать CSS Modules или CSS-in-JS решения. Эти подходы дают изоляцию стилей и интеграцию с компонентами, но различаются по реализации и ограничениям. Выбор системы стилизации влияет на разработку и ключевые метрики: размер бандла, скорость первого рендера, поведение при SSR, удобство отладки и поддержку кода. Неподходящий подход может привести к увеличению объёма JavaScript, проблемам с SSR и усложнению масштабирования. Данная статья не ставит цель назвать одного победителя. Вместо этого мы сравним основные подходы - CSS Modules и CSS-in-JS.

https://habr.com/ru/articles/1025688/

#CSSinJS #CSS_Modules #styledcomponents #frontend #React #SSR #производительность #CSS #вебразработка

CSS-in-JS vs CSS Modules: что выбрать в 2026?

В 2026 году фронтенд-разработка продолжает развиваться: появляются новые фреймворки, улучшаются инструменты сборки, растут требования к производительности и пользовательскому опыту. Разработчики сталкиваются с выбором: использовать CSS Modules или CSS-in-JS решения. Эти подходы дают изоляцию стилей и интеграцию с компонентами, но различаются по реализации и ограничениям. Выбор системы стилизации влияет на разработку и ключевые метрики: размер бандла, скорость первого рендера, поведение при SSR, удобство отладки и поддержку кода. Неподходящий подход может привести к увеличению объёма JavaScript, проблемам с SSR и усложнению масштабирования. Данная статья не ставит цель назвать одного победителя. Вместо этого мы сравним основные подходы - CSS Modules и CSS-in-JS.

https://habr.com/ru/articles/1025688/

#CSSinJS #CSS_Modules #styledcomponents #frontend #React #SSR #производительность #CSS #вебразработка

Выбор стека для веб-сайта: обзор типов рендеринга — SSR, SSG, CSR и другие

В современном мире веб-разработки выбор стратегии рендеринга сайта является одним из ключевых решений, определяющих его производительность , оптимизацию для поисковых систем (SEO) и пользовательский опыт . От того, как и где генерируется HTML-код вашего приложения, зависит скорость загрузки, интерактивность и даже стоимость инфраструктуры. В этой статье мы подробно рассмотрим основные типы рендеринга — Client-Side Rendering (CSR), Server-Side Rendering (SSR), Static Site Generation (SSG), Incremental Static Regeneration (ISR) и набирающие популярность React Server Components (RSC) — их преимущества, недостатки, влияние на SEO и производительность, а также приведем примеры технологических стеков для каждого подхода. Статья будет полезна для всех кто занимается разработкой сайта(вайбкодеры, веб-разработчки итп.)

https://habr.com/ru/articles/1000986/

#ебразработка #Рендеринг #SSR #SSG #CSR #ISR #React_Server_Components #SEO #Производительность #Стек_технологий

Выбор стека для веб-сайта: обзор типов рендеринга — SSR, SSG, CSR и другие

В современном мире веб-разработки выбор стратегии рендеринга сайта является одним из ключевых решений, определяющих его производительность , оптимизацию для поисковых систем (SEO) и пользовательский опыт . От того, как и где генерируется HTML-код вашего приложения, зависит скорость загрузки, интерактивность и даже стоимость инфраструктуры. В этой статье мы подробно рассмотрим основные типы рендеринга — Client-Side Rendering (CSR), Server-Side Rendering (SSR), Static Site Generation (SSG), Incremental Static Regeneration (ISR) и набирающие популярность React Server Components (RSC) — их преимущества, недостатки, влияние на SEO и производительность, а также приведем примеры технологических стеков для каждого подхода. Статья будет полезна для всех кто занимается разработкой сайта(вайбкодеры, веб-разработчки итп.)

https://habr.com/ru/articles/1000986/

#ебразработка #Рендеринг #SSR #SSG #CSR #ISR #React_Server_Components #SEO #Производительность #Стек_технологий

Почему тормозят AMD Epyc

Нам надо было закупить High-CPU, но так, чтобы это было одинаковое корпоративное железо для всех наших дата-центров по миру. Почему надо было закупить? Потому что есть маркетинг. Те хостинги, которые используют десктопное железо, вешают потрясающие числа на сайты. У многих красуются предложения с частотами по четыре, а то и по пять гигагерц. Понятно, что совесть у всех разная, и часто за этими цифрами скрываются обычные десктопные процессоры, а не серверные. Но клиент, который не вникает в детали, видит большое число и делает выбор. Так вот, нам надо было тоже завести такое большое число, потому что так порешал рынок. Мы давно придерживаемся принципа использовать только настоящее серверное железо, то есть корпоративный класс. У нас в основной линейке стоят проверенные серверные Intel, которые в пике выдавали 3,7 ГГц. И мы-то знали, что наши 3,7 ГГц по реальной производительности легко обгоняют многие разогнанные решения конкурентов. Но как это донести до человека, который просто сравнивает цифры на лендинге? Поэтому мы стали искать серверный процессор с высокой тактовой частотой, чтобы соответствовать нашей внутренней политике и при этом не проигрывать в слепом сравнении. Решили затестить AMD Epyc. Нашли модель с отличными ТТХ: много ядер, высокая частота. Купили партию железа. Думали, что сейчас включим, и он просто разорвёт наш текущий Intel. Это наш первый опыт с AMD. Нас немного смущал тренд на Реддите «Почему тормозят AMD Epyc», но казалось, что всё должно пойти хорошо. Конечно же, хорошо не пошло, иначе я этого не писал бы.

https://habr.com/ru/companies/ruvds/articles/961276/

#ruvds_статьи #процессор #amd #epyc #тест #виртуальная_машина #производительность #hyperv #vds

CSS-in-JS vs CSS Modules: что выбрать в 2026?

В 2026 году фронтенд-разработка продолжает развиваться: появляются новые фреймворки, улучшаются инструменты сборки, растут требования к производительности и пользовательскому опыту. Разработчики сталкиваются с выбором: использовать CSS Modules или CSS-in-JS решения. Эти подходы дают изоляцию стилей и интеграцию с компонентами, но различаются по реализации и ограничениям. Выбор системы стилизации влияет на разработку и ключевые метрики: размер бандла, скорость первого рендера, поведение при SSR, удобство отладки и поддержку кода. Неподходящий подход может привести к увеличению объёма JavaScript, проблемам с SSR и усложнению масштабирования. Данная статья не ставит цель назвать одного победителя. Вместо этого мы сравним основные подходы - CSS Modules и CSS-in-JS.

https://habr.com/ru/articles/1025688/

#CSSinJS #CSS_Modules #styledcomponents #frontend #React #SSR #производительность #CSS #вебразработка

CSS-in-JS vs CSS Modules: что выбрать в 2026?

В 2026 году фронтенд-разработка продолжает развиваться: появляются новые фреймворки, улучшаются инструменты сборки, растут требования к производительности и пользовательскому опыту. Разработчики сталкиваются с выбором: использовать CSS Modules или CSS-in-JS решения. Эти подходы дают изоляцию стилей и интеграцию с компонентами, но различаются по реализации и ограничениям. Выбор системы стилизации влияет на разработку и ключевые метрики: размер бандла, скорость первого рендера, поведение при SSR, удобство отладки и поддержку кода. Неподходящий подход может привести к увеличению объёма JavaScript, проблемам с SSR и усложнению масштабирования. Данная статья не ставит цель назвать одного победителя. Вместо этого мы сравним основные подходы - CSS Modules и CSS-in-JS.

https://habr.com/ru/articles/1025688/

#CSSinJS #CSS_Modules #styledcomponents #frontend #React #SSR #производительность #CSS #вебразработка

Оптимизация кода 1С и архитектуры вместо покупки железа (конкретная история)

За 15 лет в разработке и анализе производительности 1С я понял одну простую, но неприятную вещь: когда высоконагруженная система начинает тупить, мы инстинктивно виним платформу, железо или СУБД. Но в реальности, даже на тяжёлых бэкендах с тысячами пользователей, узкое горлышко — это почти всегда наш собственный код. Сегодня я расскажу, как мы построили систему мониторинга своими руками, сэкономили 20% на железе (которого у нас, к слову, не «терабайты и сотни ядер», а вполне вменяемые конфигурации) и почему стандартный APDEX может нагло врать вам в лицо. — Платформа 1С 8.3.24. — СУБД Postgres Pro. — Больше 40 серверов 1С в разных контурах (внутренний для сотрудников, внешний для поставщиков). — В пике — более 4000 пользователей. Ежечасно (!) крутятся тысячи фоновых заданий и сотни интеграционных сценариев.

https://habr.com/ru/companies/greenatom/articles/1003544/

#Рostgres_Pro #ClickHouse #оптимизация_кода #производительность #мониторинг_систем #SQLзапросы #RLS #APDEX

Оптимизация кода 1С и архитектуры вместо покупки железа (конкретная история)

За 15 лет в разработке и анализе производительности 1С я понял одну простую, но неприятную вещь: когда высоконагруженная система начинает тупить, мы инстинктивно виним платформу, железо или СУБД. Но в реальности, даже на тяжёлых бэкендах с тысячами пользователей, узкое горлышко — это почти всегда наш собственный код. Сегодня я расскажу, как мы построили систему мониторинга своими руками, сэкономили 20% на железе (которого у нас, к слову, не «терабайты и сотни ядер», а вполне вменяемые конфигурации) и почему стандартный APDEX может нагло врать вам в лицо. — Платформа 1С 8.3.24. — СУБД Postgres Pro. — Больше 40 серверов 1С в разных контурах (внутренний для сотрудников, внешний для поставщиков). — В пике — более 4000 пользователей. Ежечасно (!) крутятся тысячи фоновых заданий и сотни интеграционных сценариев.

https://habr.com/ru/companies/greenatom/articles/1003544/

#Рostgres_Pro #ClickHouse #оптимизация_кода #производительность #мониторинг_систем #SQLзапросы #RLS #APDEX

Оптимизация кода 1С и архитектуры вместо покупки железа (конкретная история)

За 15 лет в разработке и анализе производительности 1С я понял одну простую, но неприятную вещь: когда высоконагруженная система начинает тупить, мы инстинктивно виним платформу, железо или СУБД. Но в реальности, даже на тяжёлых бэкендах с тысячами пользователей, узкое горлышко — это почти всегда наш собственный код. Сегодня я расскажу, как мы построили систему мониторинга своими руками, сэкономили 20% на железе (которого у нас, к слову, не «терабайты и сотни ядер», а вполне вменяемые конфигурации) и почему стандартный APDEX может нагло врать вам в лицо. — Платформа 1С 8.3.24. — СУБД Postgres Pro. — Больше 40 серверов 1С в разных контурах (внутренний для сотрудников, внешний для поставщиков). — В пике — более 4000 пользователей. Ежечасно (!) крутятся тысячи фоновых заданий и сотни интеграционных сценариев.

https://habr.com/ru/companies/greenatom/articles/1003544/

#Рostgres_Pro #ClickHouse #оптимизация_кода #производительность #мониторинг_систем #SQLзапросы #RLS #APDEX

Оптимизация кода 1С и архитектуры вместо покупки железа (конкретная история)

За 15 лет в разработке и анализе производительности 1С я понял одну простую, но неприятную вещь: когда высоконагруженная система начинает тупить, мы инстинктивно виним платформу, железо или СУБД. Но в реальности, даже на тяжёлых бэкендах с тысячами пользователей, узкое горлышко — это почти всегда наш собственный код. Сегодня я расскажу, как мы построили систему мониторинга своими руками, сэкономили 20% на железе (которого у нас, к слову, не «терабайты и сотни ядер», а вполне вменяемые конфигурации) и почему стандартный APDEX может нагло врать вам в лицо. — Платформа 1С 8.3.24. — СУБД Postgres Pro. — Больше 40 серверов 1С в разных контурах (внутренний для сотрудников, внешний для поставщиков). — В пике — более 4000 пользователей. Ежечасно (!) крутятся тысячи фоновых заданий и сотни интеграционных сценариев.

https://habr.com/ru/companies/greenatom/articles/1003544/

#Рostgres_Pro #ClickHouse #оптимизация_кода #производительность #мониторинг_систем #SQLзапросы #RLS #APDEX

Производительность Windows 11 «комически низкая», в интерфейс внедряют рекламу. Люди возвращаются на Windows 10

На рынке операционных систем происходит странное. Доля Windows 11 не растёт, как положено для новинки, а снижается. Согласно апрельской статистике Statcounter , после достижения рекордного показателя 28,16% в феврале 2024 года доля Windows 11 упала до 26,19% в апреле. Тем временем доля Windows 10 за тот же период приблизилась к 70%. И это после того, как Microsoft объявила о завершении поддержки Windows 10 в октябре 2025 года . Что вообще происходит?

https://habr.com/ru/companies/ruvds/articles/818905/

#ruvds_статьи #Windows_11 #Windows_10 #производительность #Чёрное_зеркало #блокировка_рекламы #Bloatynosy #Winpilot #Adblock #резервное_копирование #Windows 12 #меню_Пуск #Recall #Copilot_Plus #NPU #Amperage #Windrecorder #OFGB #POPCNT #SSE 42

Пять возможностей PostgreSQL, о которых редко вспоминают

Привет, Хабр! Постгрес – не просто реляционная БД, а настоящий кладезь фич, о которых начинающий разработчик может и не догадываться. Всё началось с того, что PostgreSQL изначально писался на С/C++ и всегда тянуло к расширению стандартного SQL набора возможностей. Так однажды разработчики решили добавить в него JSONB , логику на уровне запросов и многое другое – что в итоге сделало его не хуже NoSQL-систем. Но вернёмся к малоизвестным фичам. Ниже – пять приёмов и возможностей, которые неожиданно полезны в повседневной работе.

https://habr.com/ru/companies/otus/articles/941456/

#psql #postgresql #базы_данных #оптимизация_запросов #права_доступа #диапазонные_типы #производительность

IQ, EI и AI — сила эмоционального интеллекта в цифровую эпоху

Эмоциональный интеллект всегда был важен, но развитие компетенций, лежащих в основе EI, будет приобретать все большее значение, поскольку автоматизация и искусственный интеллект заменяют все или часть многих профессий, а люди на рабочем месте все больше отличаются своими уникальными человеческими характеристиками и навыками. «Управление людьми», «координация действий с другими» и «эмоциональный интеллект» входят в « десятку главных навыков для 4-й промышленной революции » Всемирного экономического форума, но мы могли бы рассматривать их все как связанные с навыками и компетенциями эмоционального интеллекта. Организационное лидерство начали формально изучать и документировать в последнюю Промышленную революцию. В то время лидерство основывалось на принципах командования и контроля сверху вниз, производства и материальных активов. Мало кто задумывался о том, что подчиненные могут играть какую-либо роль в процессе лидерства . Если вы не были менеджером, вы могли бы быть роботом.

https://habr.com/ru/articles/869834/

#благополучие #производительность #стив_джобс #readiness #performance #ai #iq #wellbeing

Pretext – библиотека, которая считает текстовую вёрстку в 500 раз быстрее браузера. Зачем это нужно и как работает

28 марта 2026 года инженер Midjourney Cheng Lou выложил в открытый доступ библиотеку, которая за неделю набрала почти 40 тысяч звёзд на GitHub. И имя ей - Pretext . Это движок текстовой верстки на чистом TypeScript, который полностью обходит DOM и браузерный layout рефлоу. За этим стоит вполне большая проблема и красивое решение. Давайте разберемся, что это такое, зачем оно нужно, как устроено и стоит ли тащить к себе в проект.

https://habr.com/ru/articles/1020058/

#pretext #javascript #text_layout #производительность #dom_reflow #typescript #виртуализация #open_source

Процессор в вашем компьютере угадывает будущее. И ошибается в 5% случаев

В прошлую пятницу я объяснял джуну, почему его код на отсортированном массиве работает в шесть раз быстрее, чем на неотсортированном. Тот же массив, тот же алгоритм, и те же данные. Просто в другом порядке. Джун смотрел на меня как на сумасшедшего и, честно говоря, я его понимаю. Потому что ответ звучит безумно: процессор внутри вашего ноутбука постоянно пытается предсказать будущее. Буквально. Он гадает, какая ветка if выполнится ещё до того, как условие будет вычислено. И на отсортированных данных ему угадывать проще. Ну, давайте разбираться.

https://habr.com/ru/articles/1013098/

#branch_prediction #предсказание_ветвлений #оптимизация_кода #cpu #производительность #алгоритмы #архитектура_процессоров #spectre #конвейер

Проектирование микросервисов на Go: типичные сложности и лучшие практики

Баланс между производительностью, читаемостью и поддерживаемостью — ключевая задача при разработке микросервисов на Go. На практике всё сложнее из-за неочевидных факторов: от влияния частоты вызовов GC на время отклика до последствий избыточной вложенности в контрактах API. Если не учесть эти нюансы, даже грамотно спроектированный сервис может просаживаться по RPS (requests per second) — или его может быть сложно обновлять и дорабатывать. Меня зовут Артём Кущ. Я Go-разработчик в команде VK Видео. В статье поделюсь подходами к оптимизации микросервисов и расскажу, как балансировать между скоростью и простотой.

https://habr.com/ru/companies/vk/articles/1021702/

#go #highload #микросервисы #производительность #читаемость #поддерживаемость #оптимизация