Скорость работы – Яндекс.Интернетометр — проверка скорости интернета

проверка, анализ и способы оптимизации

Почему скорость сайта имеет значение

Всем известно, что медленная работа сайта – это плохо. Если сайт периодически подтормаживает, то у посетителей возникают серьезные проблемы при решении своих задач и плюс это просто-напросто раздражает.

Но даже, если ситуация с веб-ресурсом относительно нормальная (сайт загружается быстро на большинстве устройств), то небольшие задержки в отображении сайта становятся причиной потери аудитории и падения процента конверсии.

Специалисты Amazon выяснили, что при падении скорости загрузки на 100 мс, у них сразу же на 1% снижаются продажи.

Большая часть интернет-аудитории для посещения сайтов сегодня использует мобильные устройства. А у них каналы доступа и внутренние ресурсы значительно медленнее, чем в персональных компьютеров.

Еще очень важен технический аспект проблемы, который является третьей причиной плохой скорости. Стоит понимать, что медленные сайты в основном используют больше ресурсных средств на хостинге. А это дополнительные расходы. Задержки при обработке данных серверами позволяют уменьшить пиковые нагрузки на сайт.

Поэтому проблема скорости загрузки сайта должна решатся сразу по нескольким направлениям. И эта статья призвана охватить все возможные способы и инструменты оптимизации скорости сайта и конкретных страниц.

Основные составляющие скорости сайта

Скорость загрузки сайта имеет два аспекта: клиент и сервер. Нужно понимать, что обе эти части влияют на итоговый результат. Но каждый из них имеет свои важные параметры.

Чтобы понять, как определяется время, за которое загружается страница сайта, давайте детальнее рассмотрим это явление. В конечном итоге мы выясним, как нам оптимизировать и клиентскую, и серверную части. Когда сайт загружается (при первом визите) – происходят такие операции:

1. DNS-запрос названия сайта.
2. Связь с сервером по проверке IP (по протоколу TCP).
3. Установка безопасного соединения при использовании протокола HTTPS (TLS соединение).
4. Запрос по URL-адресу HTML-страницы и ожидание сервера (на основе HTTP-протокола).
5. Загрузка HTML-кода страницы.
6. Анализ HTML-документа на стороне браузера и дальнейшее формирование серии запросов к ресурсам веб-документа.
7. Дальнейшая загрузка и разбор таблиц каскадных стилей (CSS). Загрузка и выполнение JS-кодов.
8. Дальше осуществляется рендеринг отображения страницы и активация JS-скриптов.
9. Следующий этап – подгрузка имеющихся шрифтов.
10. Отображение картинок и других элементов страниц.
11. Окончание отображения полной страницы, выполнение отстроченных скриптов и кодов.

В вышеописанном процессе некоторые этапы могут проходить одновременно, а иногда меняться местами, но суть при этом не меняется.

Оптимизация сервера связана с четырьмя первыми этапами. А стадии с 5 по 12-ю предполагают оптимизацию клиента. Время каждого этапа является индивидуальным для разных сайтов. Поэтому вам нужно узнать метрики сайта и запустить проверку скорости сайта для идентификации основных проблем.

Проверка скорости сайта

Самое важное, понять, что нам следует измерять.

1. Время для получения начального байта (TTFB). Это временный отрезок с начала загрузочного процесса и до получения первых данных. Этот параметр можно считать основной метрикой оптимизации сервера.
2. Начало отображения страницы (начало рендеринга, первые цвета). Такой показатель демонстрирует время до конца периода «белого экрана» в браузере, когда страница начинает прорисовываться.
3. Загрузка базовых элементов страницы (фактическое время загрузки). Оно включает обработку всех ресурсов для взаимодействия со страницей, после чего стрелки браузера, которые отображают загрузку ресурса, перестают вращаться.
4. Полная загрузка веб-страницы.  Время перед завершением основных действий браузера, когда уже обработаны все основные и отложенные модули кода.

Все вышеперечисленные параметры скорости измеряются в секундах. Но очень полезно при анализе 3 и 4 показателя обращать внимание на количество трафика. Это важно для того, чтобы оценить, как скорость соединения сказывается на времени загрузки. Дальше надо разобраться, как проверять скорость.

Одним из самых эффективных инструментов является набор инструментов разработчика, доступный в браузере. Самыми продвинутыми функциями панели располагает Chrome. На вкладке «Сеть» вы можете получить показатели тайминга загрузки для комплекса показателей, включая также и сам HTML-файл. Когда вы наводите курсор на элемент, то можете увидеть, сколько времени уходит на каждый из шагов в обработке ресурса. Для того, чтобы комплексно оценить картину загрузки можно использовать вкладку «Производительность». Она предоставляет всеобщую информацию до этапа декодирования графических элементов.

Если вам необходимо оценить скорость сайта и не требуется дополнительных деталей, начните анализ сайта на вкладке

«Аудит». Он проводится с использованием подключаемого модуля Lighthouse. В отчете вам представиться оценка скорости для мобильных устройств (как отдельных пунктов, так и в соответствии с вашими базовыми показателями) и нескольких других форм отчетности.

Для быстрой оценки оптимизации клиентской составляющей, можно использовать службу Google PageSpeed Insights, либо Sitechecker (наш сервис включает API-интерфейс сервиса Google).

Также, полезно оценить скорость загрузки сайта у реальных пользователей. Для этой цели хорошо подходят отчеты 2 известных систем веб-аналитики.

1. Отчет Яндекс Метрики по скорости страниц

Чтобы найти отчет, следуйте этому пути.

Яндекс.Метрика > Отчеты > Стандартные отчеты > Мониторинг > Время загрузки страниц

2. Отчет Google Analytics по скорости страниц

Чтобы найти отчет, следуйте этому пути.

Google Analytics > Поведение > Скорость сайта > Предложения по скорости

Следует ориентироваться на такие показатели скорости загрузки сайта: начало рендеринга проходит за 1 секунду, а процесс загрузки самой страницы в пределах 3-5 секунд. В подобном формате вы не получите нареканий на скорость загрузки сайта от пользователей, а время обработки кода не сможет ограничить его эффективную работу. Нужно чтобы описанные цифры были достигнуты реальными посетителями, а анализ доступа был релевантным с разных, иногда даже устаревших девайсов.

Оптимизация сервера

Оптимизация скорости сервера для всех представляется как самая очевидная и беспрекословная мера, на которую ориентируются разработчики. Прежде всего стоит понимать, что сервер контролируется системными администраторами, которые могут оптимизировать его работу. Причин проседания скорости из-за серверных проблем может быть вагон и маленькая тележка, но все же есть некоторые позиции, которые стоит рассмотреть в первую очередь.

1. Хостинг (серверные ресурсы)

Это первостепенная причина проседания скорости у множества небольших веб-ресурсов. Для загрузки сайта в большинстве случаев попросту не хватает системных ресурсов, среди которых скорость диска либо производительность процессора. Как правило, изменение хостинга положительно влияет на улучшение скорости загрузки сайта.

При любой минимальной возможности улучшить такие ресурсы, стоит попытаться сделать это. Но если ценник дополнительных ресурсов начинает превышать стоимость оптимизационных работ, то следует воспользоваться техниками, указанными ниже.

2. DBMS (сервер базы данных)

Вот мы и обращаемся к корню всех бед: низкой скорости программного кода. Самый распространенный случай, когда веб-приложения затрачивают больше всего времени на обращения к базам данных. И это вполне логично, ведь главная задача таких утилит состоит в сборе данных и конвертировании их согласно текущей модели.

Решить трудности с медлительными ответами базы данных помогут два шага: регулировка DBMS и оптимизация запросов со схемами данных.

Настройка DBMS (к примеру, MySQL) может привести к улучшению параметров скорости в несколько раз. Такое случается, если до этого никто не оптимизировал саму базу данных. Иногда результат превосходит все ожидания и составляет десятки процентов.

Настройкой запросов и схем данных управлять довольно сложно. В разрезе такой оптимизации прирост скорости достигается на несколько порядков предыдущей её величины. Чтобы зафиксировать медленные запросы понадобится агрегация статистики загрузки базы данных для длительного промежутка времени. Потом файл логов следует проанализировать и зафиксировать список главных кандидатов на переработку.

3. Влияние CMS и программного кода

Распространено мнение, что определяющим фактором для скорости сайта является его движок (система управления контентом / CMS). Это приводит к тому, что вебмастера делят все движки на быстрые и медленные. Но это очень далеко от истины.

Загрузка серверных ресурсов имеет привязку к коду и использованной CMS – это факт. Но самые востребованные системы уже давно научились оптимизировать свои ресурсы и достигать максимальной производительности, избегая проблем со скоростью.

Тем не менее, в добавок к основному коду движка, на сайте часто устанавливаются дополнительные модули и расширения. Именно плагины часто стают причиной существенного снижения скорости и влияют на нее очень негативно.

Найдите страницы с лишним кодом

Запустите аудит сайта и найдите страницы с соотношением текста к коду меньше 10%

Довольно часто проблемы с быстротой загрузки возникают при неправильном применении системы. Хороший пример в этом контексте – создание интернет-магазина на движке, предназначенном для ведения блогов (такое часто бывает, например, с WordPress). А иногда CMS для генерации небольших сайтов используют как основу для разработки портала.

4. Кэширование

Самым эффективным и наиболее полезным способом ускорения сайта является кэширование. Речь идет здесь прежде всего о серверном кэшировании, а не о кэше хедеров.

Когда для определения результата (выполнения страницы) нужно затратить огромные ресурсы, то стоит закэшировать результаты и время от времени их обновлять. Это простой и комплексный подход: система кэширования относится к составляющим языков программирования, веб-серверов и системы управления контентом.

Нужно понимать, что кэширование страниц поможет ускорить сайт и сократит формирование страницы до нескольких миллисекунд. Но здесь могут помешать две трудности:

• далеко не все ресурсы могут кэшироваться;
• кэш следует правильно отключать / сбрасывать.

Если указанные проблемы не преграда – кэширование советуют, как один из максимально эффективных методов ускорения ресурсов сервера.

5. Оптимизация TCP, TLS, HTTP/2

В этом подпункте будут объединены искусные методы оптимизации сети, которые также дают рост серверной скорости. И хотя влияние здесь не столь впечатляющее как при других способах, оно достигается только за счет настроек. Другой плюс – такая оптимизация бесплатная.

В настройке TCP сегодня нуждаются многие большие проекты и те сервера, где передается большой трафик. Важно понимать, что сетевые подсистемы обновляются на регулярной основе, с каждым выпуском нового ядра Linux. Поэтому их стоит обновлять. Правильная настройка TLS (HTTPS) поможет вам добиться высокого уровня безопасности и минимизирует время установки безопасного соединения. Рекомендуем использовать обновления, выпущенные Mozilla.

Новая версия HTTP-протокола – HTTP/2, создана для того, чтобы ускорить загрузку сайтов. Хотя стандарт появился относительно недавно, уже сегодня его активно использует каждый пятый сайт. В целом, механизм акселерации скорости работы сайтов уже налажен в HTTP/2. Но теперь важно сократить эффект задержек сети при загрузке страницы (множественные запросы). Вместе с тем, ускорение на HTTP/2 не всегда проходит гладко, поэтому не стоит возлагать большие надежды на этот протокол.

Клиентская оптимизация

В отличие от оптимизации сервера, клиентская сторона ориентирована на всё, что происходит в браузере пользователей. Из-за этого усложняется контроль (поскольку используются разные девайсы и типы браузеров) и появляется много разнообразных способов оптимизации. Давайте рассмотрим самые действенные и универсальные методы, которые можно применить практически на всех веб-ресурсах.

1. Критический путь оптимизации CSS и JS

Критический путь рендеринга (critical rendering path) – это набор ресурсов для начала рендеринга страницы в браузере. В основном такой набор включает HTML-документ сам по себе, веб-шрифты, стили и JS-коды.

Главная задача при оптимизации скорости сайта здесь будет состоять в двойном сокращении: времени (включая задержки сети) и трафика (подразумевая медленные соединения).

Наиболее простой способ определиться с критическим курсом – запустить инструменты аудита, которые доступны в браузере Chrome (в панели разработчика). Плагин Lighthouse определяет его структуру и время загрузки, при этом особое внимание уделяется медленному соединению.

Основная техника сокращения критического пути: удалить всё, что является лишним, или то, что можно отложить. К примеру, значительную часть Java Script кода допустимо откладывать до загрузки страницы. Для этого вызов JS-ресурса помещают в конец HTML-кода или пользуются атрибутом Async.

Для отложенной загрузки CSS-стилей достаточно применить динамическое соединение этих компонентов через JS (ожидание события domContentLoaded).

2. Оптимизация веб-шрифтов

Веб-шрифты стали признанным стандартом в сфере дизайна. Но, как и другие составляющие страницы, они плохо влияют на отображение страницы и её скорость. По своей природе, шрифты – дополнительный ресурс, который следует получить перед началом отображения текста.

Ситуация усугубляется фактом, что указатели на файлы шрифтов находятся внутри таблиц стилей, которые также часто замедляют вывод ресурсов. Многие пользователи и разработчики облюбовали общие сервисы веб-шрифтов (среди которых Google Fonts), а они вызывают еще большую медлительность, поскольку предполагают несколько дополнительных соединений и взаимодействие с CSS.

Главной целью оптимизации становится сокращение объема трафика, потраченного на веб-шрифты и получение их в максимально краткий срок. Для сокращения трафика следует использовать современные прогрессивные форматы: WOFF для совместимости и WOFF2 для браузеров. Другой аспект – использование кодировки. Вы можете включать только те наборы знаков, которые есть на вашем веб-ресурсе (Латиница, Кириллица и т. д.).

Чтобы повлиять на быстрое отображение веб-шрифтов, можно использовать спецификацию rel=”preload” и свойство отображения шрифтов в CSS. Предварительная загрузка поможет максимально быстро сообщить браузеру о необходимости загрузки файла шрифтов. Она обеспечит гибкий способ отображение шрифтов, а также управление поведением браузера в случае задержки файла (не придется ждать более трех секунд).

3. Оптимизация изображений

Картинки занимают большую часть веса современных сайтов. Главной методикой оптимизации изображений является уменьшение их размеров. Для этого нужно использовать подходящий формат и инструменты для сжатия:

• PNG для изображений с прозрачностью и текстом;
• JPEG для фото и более комплексных графических изображений;
• SVG в случае с векторной графикой.

Кроме указанных форматов, недавно появился еще и новый стандарт: WebP от Google. Он сможет заменить сразу два вышеупомянутых стандарта (PNG и JPEG), поскольку поддерживает сжатие с и без потери качества. Он применяется для файлов со слоями и анимационных картинок.

Для использования WebP достаточно создать в нем копию картинки и предоставить её браузерам, которые поддерживают этот формат.

Чтобы оптимизировать PNG можно использовать множество удобных сервисов для сжатия размера. К наиболее известным относятся OptiPNG, PNGout, EWWW Image Optimizer и другие.

При работе подобных программ, выбирается самый лучший способ сжатия, а вся лишняя необязательная информация удаляется из файла. Здесь стоит обратить внимание на аспект качества: некоторые утилиты используют алгоритмы, которые приводят к его потере, и поэтому они вряд ли подойдут многим пользователям. Ведь большинство ожидает получить на выходе изображение с теми же характеристиками.

Для JPEG также существует два типа оптимизации: без потери и с потерей качества. В большинстве случаев рекомендуется использовать инструмент Mozilla JPEG package. Он разработан с целью улучшить компрессию в этом формате. Для конвертации без потери качества смотрите в сторону jpegtran, а если качество вторично – cjpeg.

4. Кэширование хедера (header)

Это простейший способ для оптимизации клиента. Он применим к кэшированию в браузере редких ресурсов: шрифтов, картинок, стилей, скриптов и даже кода страниц в целом. Благодаря этому методу, каждый из указанных типов обращается к серверу только один раз.

При использовании сервера Nginx, просто добавьте инструкцию:

add_header Cache-Control "max-age=31536000, immutable";

С этого момента у браузера будет возможность закэшировать все ресурсы на годичный период (это происходит в большинстве случаев). Браузер имеет право кэшировать ресурсы до года (что наблюдается почти всегда). Новый параметр указывает, что ресурс не изменится.

Но остается открытым вопрос: что нужно для изменения кэшированных ресурсов? Ответ простой – следует поменять их адреса. Например, вы можете добавить версию в имя файла.

5. Сжатие данных

Обязательной практикой является сжатие любых текстовых данных при переносе с сервера в браузер. Большинство веб-серверов включают функцию gzip-сжатия. Однако, простой активации сжатия недостаточно.

Во-первых, коэффициент сжатия настраивается и должен приближаться к максимальному.

Во-вторых, вы можете использовать статическое сжатие, которое поможет сделать предварительную обработку данных и разместить их на диске. После этого сервер начнет поиск сжатых файлов и незамедлительно будет их передавать.

В-третьих, можно применять более совершенные способы компрессии: zopfli (совместим с gzip) и brotli (новый алгоритм сжатия). Стоит отметить, что Brotli будет работать только с веб-ресурсом на протоколе HTTPS. Поскольку эти методы (особенно zopfli) обходятся для сжатия очень дорого, эксперты советуют использовать их в статической версии.

Чтобы увеличить результат сжатия файлов, нужно предварительно использовать минификацию: очистить ненужные переводы строк и других неиспользуемых элементов. Этот процесс отличается в зависимости от выбранного формата. Но не менее важно провести меры по сжатию других текстовых данных на веб-ресурсе.

Использование CDN

Использование CDN (сеть доставки контента / content delivery network) для ускорения работы веб-сайта – очень разрекламированный способ, который кроме технологической составляющей включает много маркетинговых добавок.

1. Как CDN появился

В первую очередь CDN был задуман, как средство разгрузки каналов трансляции и медийных ресурсов. К примеру, при просмотре live-видео, десятки тысяч пользователей создают большое давление на пропускные возможности серверов. В добавок к этому, для обеспечения качественной и бесперебойной связи с большим количеством удаленных клиентов и серверов нужны мощнейшие ресурсы и сделать это очень сложно (поскольку сеть нестабильна, а издержки существенные).

Чтобы решить эту проблему были созданы CDN, то есть распределенные сети, к которым могли подключаться клиенты (например, аудитория каналов). Узлы сетей при этом уже находятся на сервере. Было сокращено количество обращений к серверу, хотя к CDN в это время обращались миллионы раз, но её стабильность обеспечена кэшированием контента.

В наши дни CDN позиционируются, как инструменты для увеличения скорости сайтов. Считается, что они сокращают расстояние передачи данных между контентом и клиентом (посетителем веб-ресурса).

2. Возможное влияние

Можно ли ускорить веб-ресурс при использовании CDN? На самом деле ответ утвердительный. Соединение пользователя с ближайшим сервером (по времени) устанавливается быстрее и эффективнее подключаются TCP и TLS протоколы. А если контент размещен на сервере CDN, то юзер может быстрее получить нужные данные.

Во-вторых, CDN не может просто распространять контент без изменений, она оптимизирует файлы на своей стороне и придает им более компактную форму: сжимает изображения, применяет сжатие для тестирования и т. д. Подобные улучшения позволяют сократить время загрузки.

3. Недостатки использования CDN

Минусы являются дополнением к преимуществам инструмента: файлы могут не находится в кэше узлов CDN. Как следствие, они еще не запрашивались либо не могут быть кэшированными (речь идет об HTML-документах). В подобных ситуациях мы получаем добавочные задержки между сетью передачи контента и собственным сервером.

Несмотря на факт, что CDN разработан для увеличения скорости доступа к сайту, может случится так, что сетевой маршрут будет более оптимальным без использования CDN.

Наконец, сети доставки контента являют собой системы со сложной структурой, поэтому в их работе часто происходят сбои, что вызывает нестабильность и другие проблемы. При использовании CDN мы увеличиваем уровень сложности работы системы в целом.

Фиксируем результаты

Представьте ситуацию, в которой вам удалось получить требуемую скорость веб-ресурса. При таком раскладе посетители и владельцы сайта будут счастливы. Можно ли забывать о проблемах скорости при этом? Нет, конечно. Для достижения качественного функционирования сайта, нужно анализировать скоростные параметры сайта и поддерживать их в надлежащем состоянии.

Любой успешный интернет-проект постоянно растет и меняется, обновления касаются как общих шаблонов (оформления сайта, его интерфейсов), так и содержания. Вместе с тем меняется и код ресурса (особенности работы сервера и клиента).

Любая трансформация может влиять на скорость работы сайта. Чтобы измерить такие эффекты, следует внедрять сервис синтетического мониторинга скорости сайта еще на стадии его разработки. Поэтому, любые проблемы в этом плане должны быть предвосхищены еще до того, как их начнут замечать пользователи.

Чтобы оптимизировать входящий контент, необходимо интегрировать успешные алгоритмы оптимизации в движок сайта. Прежде всего это касается работы со сжатием изображений.

Ускорение работы сайта – это очень динамическая сфера: здесь всё время применяются новые протоколы и стандарты и меняется их взаимодействие с браузерами. По этой причине актуальным становится анализ технологии проекта и используемых на нем программных процессов.

sitechecker.pro

От чего зависит скорость работы компьютера?

Часто меня спрашивают, от чего зависит скорость компьютера? Решил написать статью на эту тему, чтобы детально рассмотреть факторы, которые влияют на быстродействие системы. Ведь понимание этой темы дает возможность ускорять работу ПК.

Железо

Скорость компьютера напрямую зависит от конфигурации вашего ПК. Качество комплектующих влияет на производительность ПК, а именно..

Жесткий диск

Операционная система тысячи раз обращается к жесткому диску. Более того, сама ОС стоит на винчестере. Чем больше его объём, скорость вращения шпинделя, кэш память, тем быстрее будет работать система. Также важно количество свободного места на диске C (обычно там стоит Windows). Если менее 10% от общего объема – ОС замедляется. Мы писали статью, что делать, если на диске C: мало места. Посмотрите, нет ли там ненужных файлов, программ, неиспользуемых драйверов. Раз в месяц желательно дефрагментировать ЖД. Обратите внимание, SSD диски намного производительнее, чем HDD.

Оперативная память

Объем ОЗУ – самый важный фактор, влияющий на скорость работы компьютера. Временная память хранит промежуточные данные, машинные коды и инструкции. Одним словом – чем больше, тем лучше. Проверить оперативную память можно с помощью утилиты memtest86.

Центральный процессор

Компьютерный мозг важен так же, как и ОЗУ. Стоит обратить внимание на тактовую частоту, кэш память и количество ядер. В общем, скорость работы компьютера зависит от тактовой частоты и кэша. А количество ядер обеспечивает многозадачность.

Система охлаждения

Высокая температура комплектующих негативно сказывается на скорости работы компьютера. А перегрев может привести к поломке ПК. Поэтому система охлаждения играет большую роль.

Видеопамять

Если вы любите поиграть в видеоигры, то этот пункт для вас. Высокое FPS (количество кадров в секунду) в играх не возможно без хорошей видеокарты. Мало видеопамяти – лаги и подвисания в играх, все элементарно. У нас есть подробная статья об причинах торможения компьютерных игр.

Материнская плата

Это объединяющая платформа, которая позволяет взаимодействовать всем вышеописанным комплектующим. Благодаря ей, все остальные части ПК работают слажено и корректно. Низкое FSB (пропускная способность, частота шины) только замедляет работу PC. Пыль на мат. плате нужно регулярно убирать, т.к она способствует перегреву. Также рекомендуем время от времени проверять стабильность работы компьютера.

Программное обеспечение

Скорость работы компьютера также зависит от установленного ПО и OC. Например, если у вас слабый ПК, вам больше подойдет Windows XP или Linux. Они менее требовательны к ресурсам. Для средней и высокой конфигурации подойдет любая ОС.

Много программ в автозапуске грузят систему, в итоге появляются подвисания и торможение. Для достижения высокой производительности закрывайте ненужные приложения. Держите свой ПК в чистоте и порядке, вовремя обновляйте драйвера.

Вредоносное ПО замедляет работу Windows. Пользуйтесь антивирусами и регулярно проводите глубокую проверку. Можете почитать, как самостоятельно избавиться от вирусов. Желаю удачи.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

mypclife.ru

От чего зависит производительность (быстродействие) компьютера

Самые основные параметры, которые влияют на скорость работы компьютера – аппаратные. Именно от того, какое железо установлено на ПК зависит как он будет работать.

Процессор

Его можно назвать сердцем компьютера. Многие просто уверенны, что основной параметр, который влияет на скорость работы ПК – тактовая частота и это правильно, но не полностью.

Конечно, количество Ггц важно, но и количество ядер процессора, также играет немаловажную роль. Не стоит сильно углубляться в подробности, упростим: чем выше частота и больше ядер – тем быстрее ваш компьютер.

Оперативная память

Опять же, чем больше гигабайт этой памяти тем лучше. Оперативная память или сокращенно ОЗУ – временная память, куда записываются данные программ для быстрого доступа. Однако, после выключения ПК все они стираются, то есть, она является непостоянной – динамической.

И тут имеются свои нюансы. Большинство в погоне за количеством памяти ставят кучу планок разных производителей и с разными параметрами, тем самым не получают нужного эффекта. Чтобы прирост производительности был максимальный, нужно ставить планки с одинаковыми характеристиками.

Данная память также обладает тактовой частотой, и чем она большем, тем лучше.

Видеоадаптер

Он может быть дискретный и встроенный. Встроенный находится на материнской плате и его характеристики весьма скудны. Их хватает лишь для обычной офисной работы.

Если вы планируете играть в современные игры, пользоваться программами, которые обрабатывают графику, то вам нужна дискретная видеокарта. Тем самым вы поднимите производительность вашего ПК. Это отдельная плата, которую нужно вставлять в специальный разъем, который находится на материнской плате.

Материнская плата

Она является самой большой платой в блоке. От нее напрямую зависит производительность всего компьютера, так как все его компоненты располагаются на ней или подключаются именно к ней.

Жесткий диск

Это запоминающее устройство, где мы храним все свои файлы, установленные игры и программы. Они бывают двух видов: HDD и SSD. Вторые работают намного быстрее, потребляют меньше энергии и они тихие. У первых, также, есть параметры влияющие на производительность ПК – скорость вращения и объем. И опять, чем они выше тем лучше.

Блок питания

Он должен снабжать энергией все компоненты ПК в достаточном объеме иначе производительность в разы снизится.

Программные параметры

Также, на скорость работы компьютера влияют:

• Состояние установленной операционной системы.
• Версия ОС.

Установленная ОС и программное обеспечение должны быть правильно настроенными и не содержать вирусов, тогда производительность будет отличной.

Конечно, время от времени нужно переустанавливать систему и все программное обеспечение, дабы компьютер работал быстрее. Также, нужно следить за версиями ПО, ведь старые могут работать медленно из-за содержащихся в них ошибках. Нужно использовать утилиты, очищающие систему от мусора и повышающие ее производительность.

Читайте также:

composs.ru

Скорость работы корпоративных приложений / Habr

Cовременные процессоры очень и очень быстры, но вместе с тем, работая на крупном предприятии, всё время сталкиваешься с невероятной тормознутостью программного обеспечения. Никуда не годится, когда процедура закрытия месяца в бухгалтерии идёт больше суток и если что-то где то не так, то расчёт приходится запускать заново.
В статье рассмотрены фундаментальные причины медлительности приложений и даны опорные цифры, которые послужат опорой для выбора архитектуры будущих программ.

Рассмотрим типовую схему современного приложения

Общая скорость работы приложения обуславливается двумя категориями:
1) скоростью работы каждого из звеньев приложения;
2) скоростью взаимодействия между звеньями приложения.

По первому пункту, слабым звеном может быть только база данных, поскольку мы всегда можем поставить рядом ещё один сервер и распараллелить сервера приложений и веб-сервера.

Разберём второй пункт. Разные звенья приложения работают как минимум в разных процессах операционной системы, поэтому для взаимодействия двух звеньев между собой операционной системе нужно, как минимум, два раза переключится между процессами. Значит, даже если сервер приложений и база данных находятся на одном компьютере, то из-за накладных расходов времени, мы не можем рассчитывать на выполнение более 8000 SQL-запросов за секунду. В сетевом взаимодействии задействовано ещё больше процессов, соответственно и число запросов уменьшается практически до 1000. Взаимодействие между веб-сервером, веб-клиентом и сервером приложений обычно гораздо менее интенсивное, чем между сервером приложений и базой данных. Единственное, связь между пользователем и веб-сервером характеризуется относительно большим временем отклика, особенно на спутниковых каналах. Так что тучу ajax-запросов устраивать тоже не стоит (чем часто грешили первые ajax-приложения). Но вернёмся к базе данных.

В нормальном режиме работы, тысячи запросов в секунду вполне хватает. Проблемы начинаются, при какой-либо массовой обработке данных. Но особенно критичным данное ограничение становится при использовании объектных надстроек, в том числе и такой популярной, как система 1С. Особенность применения ООП в том, что оно порождает кучу мелких обращений к базе данных. И из этой ситуации сейчас существует два выхода:
а) разместить логику приложения внутри базы данных;
б) кэшировать данные внутри сервера приложений.

Выбрав вариант «а», вы сможете увеличить скорость примерно на два порядка порядок: до 100 000 запросов в секунду. Неудобство в том, что при этом мы вынуждены логику реализовывать на встроенном языке базы данных. Вариант с С# или Java –процедурами не подходит, т.к. такие процедуры выполняются в виртуальной машине, которая фактически является отдельным процессом и по времени взаимодействия практически не отличается от внешнего сервера приложений. И хотя встроенный язык программирования не очень приспособлен для реализации логики приложения, во многих банках используется именно такой подход. В основном в таком случае используется, конечно же, Oracle со своим встроенным PL/SQL.

Рассмотрим далее вариант «б». Если «на пальцах», то реализация логики при данном варианте выглядит следующим образом: загружаем большими блоками все данные, которые могут понадобиться в массивы в памяти. Обрабатываем. Выгружаем результаты обработки в базу данных. Из базы данных строки загружаются очень быстро – порядка миллиона штук в секунду. Обрабатываются данные тоже очень быстро. Проблема в загрузке данных в базу. Здесь у нас опять 1000 строк в секунду. Нестандартными приёмами можно загружать до 100 000 строк в секунду. Для очень крупных предприятий такой метод не подходит, т.к. объёмы данных таковы, что не помещаются в оперативной памяти. Вместе с тем, такой способ наиболее подходит для оптимизации 1С, не нужно только забывать, что линейный поиск очень медленен даже в оперативной памяти и вам придётся делать собственную реализацию индексов.

Откуда же взялась граница в 100 000 строк в секунду, которую мы никак не можем преодолеть, используя базу данных. Ответ прост – это примерная средняя скорость построения индексов в базе данных. Да, несмотря на то, что современный процессор может отсортировать 100 млн строк за полсекунды, Oracle тратит около 20 секунд на построения индекса в 1 млн элементов. Это надо иметь ввиду при разработке приложения. И даже этих 100 тысяч строк в секунду можно добиться только благодаря процедурам на строенном языке либо массовой загрузкой данных из файла. При использовании SQL-комманд, мы получим максимум 10 000 запросов в секунду. Можно повысить общую скорость путём кластеризации, но время отклика повысить очень и очень сложно.

Напомню, что речь идёт о массовой обработке данных, например закрытия месяца или закрытия года. В повседневном режиме обычной скорости работы вполне хватает.

Теперь поговорим о перспективах. Сейчас тихо и незаметно происходит настоящая революция в компьютерной технике – переход на 64-бита. И это не просто возможность установить больше 4 гигабайт памяти – такая возможность была ещё на Pentium II путём использования расширенных режимов процессора. 64 бита, это возможность включить любой объём данных в адресное пространство процессора. Вкупе с развитием твёрдотельных дисков, которые по своей сути больше похожи на оперативную память, нежели на классические жёсткие диски, это кардинально меняет облик будущих систем обработки данных. По всей видимости, в скором будущем мы увидим объединение сервера приложения и базы данных. Первые шаги сделаны: Oracle купила технологию Java, а Microsoft уже встраивает SQL-запросы в язык C#. Т.е. они стараются засунуть логику внутрь своей СУБД. Недостатком данного подхода является то, что логика, строящаяся на принципах ООП не очень хорошо ложиться на реляционную модель данных – при этом на порядок увеличивается число запросов к базе данных. Впрочем, крупные банки, которые будут использовать данный подход, могут себе позволить вообще не переходить на новые технологии разработки. Так, ИТ-департамент Сбербанка по численности сопоставим с общей численностью персонала. В компаниях же производственного сектора программистов гораздо меньше и новые технологии здесь, как ни странно, более востребованы.

Другой подход противоположный – встраивание базы данных внутрь сервера приложений. Из существующих технологий наиболее близкими являются NoSQL-базам данных. При таком подходе, мы можем использовать всю мощь современного процессора. Производительность приложений сходу повышается в тысячи, в миллионы раз. Но, при таком подходе используется ООП, главной особенностью которого является необходимость в быстром доступе к случайным областям базы данных. Наиболее эффективно это можно реализовать путём маппирования файла базы данных в адресное пространство сервера приложений. Необходимо отметить, что, такие популярные языки программирования, как C#, 1C, Java, не имеют средств, для прямой работы с памятью, и, поэтому, для них необходимо создавать дополнительные прослойки unsafe-кода, для возможности такой работы.

Оценим объём необходимой оперативной памяти. Повсеметное использование мультимедиа-технологий даёт немного не правильные представления об объёмах памяти, занимаемой информацией. Сейчас возможно прозвучит неожиданно, но 1 мегабайт может уместить в себе томик Войны и Мира. В этом легко убедится, перемножив количество страниц в книге, число строк текста на старанице и число букв в строке. Мы получим примерно 1 млн символов. Далеко не каждый пользователь, не владеющий навыками слепой печати, «вбивает» в компьютер по несколько томов Толстого ежегодно. Даже продовщица, непрерывно сканирующая продукты в магазине порождает всего порядка 10 мегабайт информации за год. Для офисных же пользователей, мы можем смело ставить 1 мегабайт в год на человека. Да, есть вордовские файлы, скан-копии документов, фото, музыка, фильмы — но, согласитесь, все эти виды информации лежат в базе данных «как есть» и никак не обрабатываются (за исключением полнотекстового индексирования), поэтому и в оперативной памяти они не нуждаются.

Выводы. ООП, доказавшее, за 30 лет своего существаования, свою эффективность, не может использоваться нами полностью, т.к. оно плохо совместимо с реляционными базами данных. В топике даны ориентировочные цифры, используя которые, можно выбрать оптимальную глубину внедрения ООП, и знать границы возможностей будущего приложения.

habr.com

Как узнать скорость работы (производительность) процессора

Разные модели процессоров работают по разному. Один процессор работает медленно и комп поэтому тормозит, другой процессор работает быстро и комп летает. Но как скорость работы процессора определять не в абстрактных категориях быстро/медленно а в абсолютных единицах?

Во-первых определимся с терминами

Вместо «скорость работы процессора» правильней говорить «производительность процессора». Производительность означает кол-во операций, выполняемых процессором за единицу времени. Чем больше процессор выполняет операций за единицу времени, тем он «быстрее» и соответственно производительней. Чем меньше операций процессор выполняет за единицу времени, тем он менее производительный и соответственно более тормознутый.

Зачем нужно знать производительность процессора?

Производительность процессора нужно знать для оценки состояния компьютера и принятии решения о его модернизации.

Например, нам кажется, что комп работает медленно. Нужно принять решение: просто заменить процессор на материнской плате или купить новый системный блок целиком. Кроме того может оказаться, что процессор у нас отличный, тормозить из-за него комп не может, значит тормоза не из-за проца а по какой-то другой причине(перегрев, вздувшиеся конденсаторы, вирусы в системе и т.д.)

Есть правильные и неправильные способы определить производительность процессора

Самый распространенный и при этом неправильный способ- определять производительность процессора по тактовой частоте.
Единственный правильный способ- измерить производительность с помощью специальных тестов. При этом самому тестировать ничего не надо, все уже сделано другими товарищами и выложено в интернет, нужно просто знать где смотреть.

Почему неправильно определять производительность по частоте процессора?

Потому что частота процессора это только одна из характеристик процессора, при том сейчас уже не самая главная. Сравнивать процы только по тактовой частоте это как сравнивать самолеты только по длине крыльев.

Но когда-то, до начала 2000-х, действительно производительность прямо равнялась частоте процессора. Кто имел дело с компами того поколения знает, что Пентиум 300 МГц работал значительно быстрее Пентиума 166 МГЦ, а Пентиум 800 МГц работал еще быстрее. Потому никто не заморачивался и все определяли производительность в частоте.
Тем более, что процессоры тогда и назывались тупо по мегагерцам: Pentium 166 MHz, K6-2 333 MHz и т.д.

Потом все изменилось. Разработчики развивали внутреннюю архитектуру процессоров и смогли делать их более быстрыми не только за счет поднятия тактовой частоты. Т.е. тактовая частота уже перестала быть главным критерием при оценке скорости работы процессора.

Этот факт стал отражаться и в названиях процессоров. Т.к. народ уже привык к тому, что тактовая частота= производительность= название процессора и перестроиться сразу на новые рельсы было сложно(а вернее убыточно для производителя-новатора), хитрые маркетологи стали обзывать новые модели процессоров некими числами. Эти числа значали что-то вроде «как наш процессор с маленькой частотой работал еслиб вместо улучшения его архитектуры мы тупо повысили частоту». Но все потребители думали, что эти цифры- мегагерцы.

Посмотрим на названия процессоров этого слома эпох. Вот процессор AMD Athlon XP 1900+. Все по привычке думали, что цифра «1900»  означает тактовую частоту, но на самом деле тактовая частота у него была 1600 МГц. У Athlon 2500+ Barton тактовая частота была уже 1833 МГц.

Неразберихи добавляло то, что фирма Интел упорно продолжала называть свои процессоры по частоте и, например, проц Intel Pentium-4 2.4 GHz имел тактовую частоту 2.4 GHz.

К середине 2000-х подобная система наименований перестала устраивать уже всех и производители перешли в названиях просто на индексы, рассмотреть в которых мегагерцы стало невозможным: Intel D815, Intel E1500, AMD X2 250, Intel T2350 и т.д.
Новые названия как бы шепчут нам «забудь про частоту, это напускное, не главное, гляди в суть».

А суть теперь стала состоять в том, что тактовая частота мало о чем говорит.
Например, тот же Pentium-4 2.4 GHz c тактовой частотой 2.4 ГГц работает в 3.5 раза медленнее, чем Intel E1200 с тактовой частотой 1.6 ГГц.

Вот почему когда мне говорят про свой домашний комп, что «у процессора частота 2.2 ГГц», это для меня ниочём, я не могу никак оценить производительность и дать совета.

До сих пор заблуждение о том, что тактовая частота равна производительности столь велико, что не только обычные пользователи но даже некоторые компьютерщики  продолжают тупить по старинке.

Как правильно определить производительность процессора?

Производительность процессора правильно определять в единицах производительности, расчитанных с помощью специальных тестовых программ. Есть много сайтов, где приведены результаты таких тестов в различных тестовых программах для каждой модели.

Лично мне больше всего нравится сайт cpubenchmark.net. Кажется, там наиболее полная база данных по тестам процессоров с использованием программы PassMark.
Что бы узнать производительность процессора, достаточно на сайте сверху в строке поиска набрать модель процессора и перейти по результату поиска.

Для примера найдем производительность процессора E1500:

Производительность E1500 равна 1148 баллам согласно рейтингу программы PassMark.
Тут же для удобства- кратенькая табличка для оценки тестируемого процессора относительно других моделей. Где-то на сайте есть и полная таблица со всеми процессорами.

Определяем состояние компьютера- виноват процессор или нет

Находим название модели процессора в свойствах системы:

Вот у меня процессор E5400. Дальше находим производительность этого процессора на сайте cpubenchmark.net: 1608 баллов.

Много это или мало? Как я уже писал в Апгрейд процессора на материнской плате Socket 775, сейчас для комфортного домашнего и офисного использования(без крутых игрушек) с Windows 7 достаточно процессора с производительностью от 1500 баллов.
Процессором с производительностью не менее 900 баллов в Win7 пользоваться еще терпимо.
Если производительность меньше 900 баллов(на сейчас, на февраль 2016-го), то я бы советовал использовать только WinXP.

Поэтому если комп с процессором E5400 сильно тормозит в Win7, проблема не в процессоре а в чем-то другом. Чаще всего в вирусах и глюках операционной системы, реже- в перегреве материнской платы.

Например, был недавно на одной фирме и там аномально тормозит комп с E6550 (1501 балл) и 2 Гб оперативки, при чем тормозит в Win XP. Ясно, что проблема не в устаревшем оборудовании а в чем-то другом и вместо покупки нового компьютера достаточно вылечить старый.

Определяем возможность апгрейда процессора

Бывает так, что производительность процессора объективно низкая, скажем 400 баллов, нас совсем не устраивает и мы хотим поставить более шустрый процессор. Имеет ли смысл ставить другой процессор или придется покупать весь набор материнская плата+проц+оперативка? Тут все зависит от сокета процессора и модели материнской платы.

Алгоритм принятия решения будет такой:
1. Определяем модель нашей материнской платы с помощью программы Everest или Aida64, там же определяем сокет процессора.
2. Находим список поддерживаемых процессоров данной МП. Я обычно ищу через гугл по запросу «<название МП> cpu support».
3. Определяем производительность этих процессоров.
4. Если производительность самых производительных процов для нашей МП ниже 1000-1500 баллов, менять процессор смысла нет и нужно заменить весь набор МП+проц+ОЗУ. Если МП поддерживает процы с производительностью 1000-1500 баллов и выше, проводим замену только процессора.

Подробнее на примере материнских плат с сокет 775 я писал тут: Апгрейд процессора на материнской плате Socket 775

Вот случай из моей практики месячной давности: есть СБ с процессором AMD Sempron 2600+, у него производительность 373 балла- никуда не годится. Нужно ставить более быстрый.
По указанному выше алгоритму определил, что МП имеет сокет 754 и поддерживает максимальный процессор Athlon64 3700+ c 597 баллами.
Вывод- менять шило на мыло смысла нет, поменял весь набор МП+проц+ОЗУ на бюджетное б/у с процессорм E6550. На ближайшие годы хватит.

В любом случае нужно знать производительность процессора, это может сэкономить деньги при обслуживании своего компьютера.

www.comp-man.info

Анализ ключевых показателей производительности — часть 1 / Microsoft corporate blog / Habr

Тестирование и анализ производительности — тема, которую хотелось бы обсуждать побольше. Мы начинаем публикацию перевода руководства от небезызвестной команды Patterns&Practices о том, с чем нужно есть ключевые показатели производительности. За перевод — спасибо Игорю Щегловитову из Лаборатории Касперского, нашему бессменному автору материалов про тестирование. Остальные наши статьи по теме тестирования можно найти по тегу mstesting

Введение

Анализ производительности – дисциплина сложная. Она изучает систему на предмет выполнения требований производительности и определяет причины, если эти требования оказываются не достигнутыми. Статья Performance Analysis Primer из этого цикла содержит введение в эту тему, описывая инструменты и подходы, применяемые в облачной разработке для того, чтобы достичь хорошей производительности.

Цель данного руководства – научиться исследовать производительность системы. В частности, в данном руководстве содержится описание ключевых метрик производительности, на которые вам следует обратить внимание, а также то, как использовать эти метрики для определения того, насколько хорошо работает ваша система.

Примечание: Многие проблемы производительности в крупных приложениях обусловлены тем, что они не воспроизводятся под сравнительно низкой нагрузкой, под высокой же (стрессовой) нагрузкой они приводят к существенному замедлению или сбоям системы. Важным аспектом разработки масштабируемых систем является предотвращение данных ситуаций. Чтобы помочь вам с этой задачей, мы опубликовали статью, содержащую набор анти-паттернов производительности для облачных систем (cloud-based anti-patterns).

Понятие ключевых показателей производительности

Производительность системы определяется следующими факторами:

• Сколько операций может выполнить система за определенный период времени? (пропускная способность)
• Сколько операций могут быть выполнены одновременно? (параллелизм)
• Как долго система выполняет операцию? (время отклика/задержка)
• Сколько резервной мощности требуется системе для обеспечения роста нагрузки? (запас ресурсов)
• Сколько исключений система генерит под нагрузкой? (частота ошибок)

Эти факторы могут оказаться очевидными, но, конечно, они будут меняться в зависимости от уровня нагрузки на систему. При достаточном количестве ресурсов и невысокой нагрузке большинство систем выполняет операции быстро. Критический момент наступает, когда нагрузка увеличивается до какого-то предельного уровня. Как система будет обрабатывать несколько миллионов параллельных запросов или запросов, потребляющих большие объемы доступных ресурсов? На графике показан типичный профиль функционирования тестового облачного сервиса, который принимает и обрабатывает запросы пользователей. График иллюстрирует, как пропускная способность и среднее время отклика изменяются с ростом пользовательской нагрузки. Данный график получен в процессе контролируемого нагрузочного тестирования. Горизонтальная ось – время. Тест предполагает, что для выполнения каждого запроса требуется примерно одинаковое время и количество ресурсов. Интервалы времени между запросами подчиняются нормальному распределению, что моделирует реалистичное поведение виртуальных пользователей.

Примечание: реалистичное пользовательское поведение является важной чертой нагрузочного тестирования. Без применения данного подхода результаты могут оказаться неверными. Дополнительные сведения см. в статье Editing Think Times to Simulate Website Human Interaction Delays in Load Tests Scenarios.

Профиль производительности в зависимости от пользовательской нагрузки для простого облачного сервиса

Сначала пропускная способность низкая, но при повышении нагрузки она растет до некоторого предела, который зависит от возможностей (емкости) самого сервиса. Эта емкость, скорее всего, задается на этапе разработки или определяется используемыми сервисом ресурсами. Она может быть ограничена:

• Объемом сетевого трафика между клиентами и сервисом
• Загрузкой процессора, количеством потоков и объемом доступной памяти
• Если сервис использует БД, то сюда можно добавить количество доступных подключений к БД, объем трафика между сервисом и БД и др.
• Емкостью внешних систем, от которых зависит сервис. Например, емкость Azure SQL Database определяется термином DTUs (Database Throughput Units). Если вы превышаете выделенный вам DTUs, то последующие запросы к БД не будут выполнены до приобретения дополнительной емкости. Другие службы имеют ограничения на физические ресурсы (потоки, память, соединения и тп)

Примечание: убедитесь в том, что инструмент, который вы используете для тестирования производительности, не выдает ложных результатов. Например, если инструмент не способен предоставить достаточное количества агентов тестирования, для моделирования требуемой нагрузки, то пропускная способность может быть определена неверно.
Однако этот график не всегда показывает полную картину. Несмотря на то, что на нем видна максимальную пропускную способность, латентность (задержка) с дальнейшим увеличением производительности будет расти. Это означает, что все больше и больше запросов будут попадать в очередь ожидания. В какой то момент эти запросы могут начать падать в таймауте и клиенту будут возвращаться соответствующие результаты. Помимо этого, если сервис использует веб-сервер, например, IIS, то после превышения предела внешних соединений самого веб-сервера последний начнет отвергать новые соединения.

Еще одно примечание: нехватку емкости сервиса, от которого зависит ваша система, называют «back-end pressure» (внешним давлением). Во многих системах такие сервисы часто является факторами, ограничивающими производительность. Эти сервисы часто являются внешними, их управление может быть передано (либо уже контролируется) другим лицам, которые могут повлиять на производительность.
Рисунок иллюстрирует профиль нагрузки той же тестовой облачной службы под высокой нагрузкой.

В этом графике видно, что, как только нагрузка достигает 600-та пользователей, запросы начинают падать в таймауте и система начинает генерировать исключения. Увеличение нагрузки приводит к увеличению генераций ошибок. Обратите внимание, что частота успешных запросов также будет падать. Отмечу, что среднее время запроса также падает, т.к. сервис очень быстро начинает отклонять запросы. Важный момент – измерение времени отклика не является показателем того, насколько система хорошо работает.
Еще одна сложность состоит в том, чтобы учесть, что система может быть достаточно устойчивой, чтобы восстановиться (хотя бы временно) и что число запросов, ожидающих в очереди исчезнет, а последующие запросы будут обработаны успешно. Система может войти в период, когда колебания частоты успешно выполненных запросов будут циклически сменяться интенсивностью отказов. На рисунке показан график, иллюстрирующий это феномен, который отражает антипаттерн Improper Instantiation.

Колебания частоты успешных и неуспешных вызовов сервиса под возрастающей нагрузкой

В этом примере система восстанавливается периодически, а затем опять падает. Обратите внимание, что частота исключений продолжает расти с каждым последующим пиком, это указывает на то, что в какой-то момент система полностью выйдет из строя.

Основная цель этих графиков – это подчеркнуть взаимосвязь между факторами, которые помогают определить «самочувствие» системы находящейся под нагрузкой: она либо здорова, либо вот-вот рухнет, либо что-то среднее. Нагрузочное тестирование в тестовой среде может помочь вам определить допустимую емкость ваших сервисов и оценить, понадобится ли вам масштабирование для того, чтобы удовлетворить требования производительности.

На графиках выше речь шла о простой (идеальной) ситуации, когда тестируемые сервисы изолированы. Но в реальном мире существуют проблемы посторонних шумов». Пользователи ведут себя непредсказуемо, и выполняют одновременно множество разнообразных операций. В этом случае производительность системы в произвольный момент времени будет определяться совокупностью точечных операций, выполняемых в это время.

Если пользователи начинают получать ошибки либо работа системы замедляется, то это может быть связано не с конкретным участком логики, но суммарной нагрузкой на систему. Всё это подчеркивает важность непрерывного мониторинга производительности. Если вы владеете точной и актуальной информацией о производительности, то вы сможете быстро реагировать на внезапные всплески пользовательской активности, требующие дополнительного объема ресурсов для обработки запросов. Данные о производительности, которые вы собираете, должны включать достаточное количество контекстной информации, чтобы можно было свести различные метрики в полноценное видение жизненного цикла системного процесса. Эта информация имеет жизненно-важное значение во время анализа производительности. Она помогает вам понять, как различные параллельные процессы, из которых состоит ваша система, могут сосуществовать, взаимодействовать и конкурировать друг с другом. Процесс сбора такой информации подробно описан в статье Performance Analysis Primer.

Разбор показателей по уровням абстракции:

В большинстве систем существует множество метрик, которые можно собирать и анализировать. Без тщательного рассмотрения вы очень легко можете потеряться во множестве собираемых данных либо пропустить важное значение, забыв собрать ключевые метрики. Классификация ниже помогает упорядочить метрики по определенным уровням абстракции. Осуществив правильное распределение, вы можете сфокусироваться только на тех данных, которые определяют производительность соответствующего уровня. В этой серии статей будут описываться следующие уровни абстракции:

• Client Metrics. Данные метрики сконцентрированы на измерении производительности клиентских приложений. Например, как долго клиентское приложение выполняет действия локально и обрабатывает ответ от серверной части. Эти метрики покрывают такие данные, как объем используемой памяти и загрузку CPU. На мобильном устройстве высокая загрузка CPU и частое использование сети может привести к уменьшению срока службы батареи, а использование слишком большого объема памяти вообще может помешать приложению запуститься.
• Business Metrics. Сюда включаются данные, определяющие бизнес-процессы. Они касаются деятельности конечных пользователей. Эти показатели должны включать ключевые бизнес-операции, которые выполняет система
• Application Metrics. Данные метрики сосредоточены на измерении активности и производительности прикладного уровня (исходный код приложения, фреймворк, среда исполнения, например .NET Framework, ASP.NET, CLR, и т.п.). Цель этих метрик – помочь вам исследователь поток выполнения вашего приложения при большом количестве параллельных запросов, проанализировать потребляемые ресурсы и оценить вероятность проблем с производительностью
• System Metrics. Это данные о производительности низкого уровня (уровень базовой инфраструктуры). Они обычно нацелены на ключевые показатели эффективности, связанные с памятью, сетевой утилизацией, активностью диска, использованием процессора
• Service Metrics. Сюда относятся данные, связанные с производительностью внешних сервисов, таких как Azure Storage, инфраструктурой обмена сообщений, внешним кэшем, БД и другими внешними сервисами, которые ваше приложение может использовать. Эти данные не отражают чистую производительность внешних сервисов, а всего лишь содержат информацию об исполнении запросов, которые ваша система им отправляет.

Спасибо за внимание. В следующей части мы рассмотрим эти метрики подробнее и перейдем к следующим темам.

Части статьи:
Анализ ключевых показателей производительности — часть 1
Анализ ключевых показателей производительности — часть 2, про анализ метрик пользовательских, бизнесовых и приложения
Анализ ключевых показателей производительности — часть 3, последняя, про системные и сервисные метрики.

habr.com

5 факторов, снижающих скорость работы компьютера

Скорость работы компьютера является одним из основных показателей качества его работы. Любой пользователь будет чувствовать себя комфортно и уверенно при быстрой и корректной работе своего ПК.

Что замедляет работу компьютера

Не секрет, что со временем компьютер начинает работать не так быстро, как сразу после покупки. Это происходит оп многим причинам. Основными источниками снижения скорости работы являются:

• Большое количество программ в Автозагрузке.
• Перегруженность реестра.
• Вирусные инфекции.
• Перегруженность и фрагментация жесткого диска.
• Настройки антивирусных программ.

Перечень далеко не полный, но вышеперечисленные факторы встречаются наиболее часто. Вы можете дополнить этот список в комментариях, если сочтете нужным.

Давайте разберемся с этими факторами более подробно.

Автозагрузка

Я долгое время работал системным администратором и при жалобах на снижение скорости работы ПК начинаю с анализа Автозагрузки.

При установке новых программ очень многие из них стремятся прописаться в Автозагрузке. Особенно при использовании «бесплатных» вариантов таких программ.

Этот процесс часто сопровождается установкой дополнительных программ, которые мы не планируем использовать. Нам достаточно ответить утвердительно на какой-нибудь вопрос на английском языке или не заметить активный чек-бокс и вместо одной программы на компьютер устанавливается две, а то и более.

В худшем случае мы можем «подхватить» какой-нибудь вирус.

Для анализа и очистки Автозагрузки рекомендуют использовать несколько способов:

• Посмотреть меню «Пуск». Пуск – Программы – Автозагрузка.
• При помощи системной программы Msconfig.
• При помощи сторонней утилиты CCleaner.

Как это можно сделать, Вы можете узнать, познакомившись с бесплатным курсом Василия Медведева «Турбокомпьютер».

Грязный реестр

Реестр OS Windows представляет собой Базу Данных, в которой содержится вся информация о программах, оборудовании, пользователях компьютера.

При установке , обновлении, удалении программ, добавлении или удалении устройств и пользователей эта База Данных увеличивается и загрязняется. Это повышает время доступа к нужной информации и снижает скорость работы.

Устранить все недостатки в работе системного Реестра нам поможет уже упоминавшаяся утилита CCleaner.

Можно заниматься очисткой реестра при помощи системной программы Reedit. Но для этого надо обладать определенными знаниями, так как при некорректной работе с этой программой можно вывести компьютер из строя.

Вирусная инфекция

При установке нелицензированных программ, полученных «экзотическим путем» или при неаккуратной работе в интернете, всегда есть риск заразить свой компьютер разными вирусами.

Как правило, зараженный компьютер начинает работать медленнее обычного.

Чтобы избежать этого, на ПК рекомендуют устанавливать антивирусные программы. Если Вы можете себе позволить купить лицензию на надежный антивирус, то я рад за Вас. Следуйте всем инструкциям и рекомендациям этой программы, и риск заражения будет сведен к минимуму.

Из бесплатных вариантов в последнее время я использую AVAST или AVIRA. Оба антивируса в целом неплохо справляются со своими функциями и не слишком надоедают сообщениями, предупреждениями и страшилками.

Для надежности могу Вам порекомендовать периодически использовать одноразовые бесплатные антивирусные утилиты от Лаборатории Касперского или компании Dr.WEB.

Особенно если заметили что-то подозрительное в работе своего компьютера.

Ссылки на эти ресурсы:

• Локальный Dr.Web — http://www.freedrweb.com/cureit/?lng=ru
• Локальный антивирус Касперского — http://www.kaspersky.ru/antivirus-removal-tool

Перегруженность и фрагментация жесткого диска

При работе на компьютере мы всю информацию храним на жестком диске – винчестере. Нам попадаются новые интересные программы, полезная и познавательная информация, фильмы, музыка, книги, графика…

Со временем места на диске становится все меньше и меньше.

К тому же эти файлы могут храниться на жестком диске не в одном месте, а по частям, в разных местах диска – сегментах (кластерах).

Это явление называется фрагментацией жесткого диска. Порой один файл может занимать сотни, а то и тысячи фрагментов.
Понятно, что скорость доступа к таким файлам будет невысокой.

Для устранения этих явлений необходимо сделать 2 вещи.

1. Очистить жесткий диск от лишней информации.
2. Провести дефрагментацию диска.

Очистка диска

Для очистки надо просмотреть всю информация. Котолрая накопилась у Вас и разделить ее на три части:

1. Нужная.
2. Ненужная.
3. Может пригодиться.

Нужную информацию оставляем, ненужную безжалостно удаляем. А та, которая в данный момент не нужна, но может понадобиться со временем – переносится на внешние носители. Это могут быть DVD диски или внешний жесткий диск. В крайнем случае эту информацию можно упорядочить и заархивировать.

Особенно следует обратить внимание на тот раздел диска, где у Вас установлена операционная система. Для надежной и быстрой работы следует следить, чтобы в этом разделе было минимум 30% свободного места.

Дефрагментация жесткого диска

После очистки диска от ненужной информации самое время приступить к дефрагментации.
Для этого можно использовать:

• Системные средства.
• Сторонние программы.

Системные программы успешно выполняют свои функции по дефрагментации, но по сервису и настройкам уступают сторонним.

Я могу порекомендовать Вам программу Defragger, которую периодически использую для дефрагментации жестких дисков.

Более подробно о том, почему возникает фрагментация и как эффективно проводить дефрагментацию можно узнать на том же курсе «Турбокомпьютер».

Настройки антивирусных программ

На скорость настройки работы компьютеров влияют и настройки антивирусных программ.

Большинство пользователей знают, что антивирус Касперского очень надежный, но в то же время он загружает ресурсы компьютера и заметно снижает скорость его работы.

Но не все знают, что при грамотной настойке, отключении функций, не нужных Вам при текущей работе и антивирус Касперского и другие антивирусы могут значительно снизить нагрузку на компьютер.

Еще хочу обратить Ваше внимание на такой момент. Многие неопытные пользователи могут по незнанию установить на свой компьютер два или более антивируса. В своей практике я с этим сталкивался довольно часто.

В этой ситуации скорость компьютера падает довольно значительно, порой в несколько раз. Все зависит от того какие антивирусы стоят и как они настроены.

Для исправления ситуации один из антивирусов необходимо сразу удалить.

Заключение.

В заключение давайте подведем итоги. Что следует делать для ускорения работы компьютера.

• Удалить лишние программы.
• Выявить вирусы и при наличии удалить их.
• Проверить сколько у Вас антивирусов, оставить один самый надежный и оптимизировать его работу под Ваши потребности.
• Убрать всю ненужную информацию с жесткого диска . Если есть возможность. То перенести часть информации на внешние носители.
• Почистить Автозагрузку и реестр.
• Диск, на котором расположена ОС Windows, должен содержать не менее 30% свободного места.

Как проделать все эти операции и еще некоторые другие, которые могут значительно ускорить работу Вашего компьютера, Вы можете узнать из курса Василия Медведева «Турбокомпьютер».

Если у Вас есть какие-либо дополнения, то отразите их в комментариях.

Поделитесь этой информацией со своими друзьями в социальных сетях.

Всем успехов.

Полезные Материалы:

inetmkt.ru