Время ответа сервера opencart: Время ответа сервера. Opencart 3

Почему время ответа сервера превышает положенные 3 секунды и как с этим бороться?

Содержание

  • Неприятные последствия

  • Как определить, долгий ли ответ сервера у вашего сайта?

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

  • Как «побороть» долгий ответ сервера?

  • И в завершении


Если временной промежуток между отправкой запроса поискового робота к страницам ресурса и получением ответа больше 3 секунд (то есть 300 миллисекунд), ответ сервера считается долгим. Эта ошибка, согласно классификации Яндекс.Вебмастера, относится к критичным. Чем она чревата? Почему возникает? И как её устранить? Ответы на эти вопросы ищите в нашей статье.


В Яндекс Справке критичные ошибки, выявленные при диагностике сайта в Вебмастере, описываются как те, что «могут вести к исключению отдельных страниц или всего сайта из результатов поиска». В эту группу, наравне с долгим ответом сервера, также попали некорректная настройка SSL-сертификата и страницы-дубли с GET-параметрами.


Когда говорят о времени ожидания ответа сервера, используют аббревиатуру TTFB, что расшифровывается как time-to-first-bite (время до получения первого байта). Иными словами, тот промежуток времени, за который происходит первоначальное соединение между браузером и сайтом. Чем этот промежуток меньше, тем лучше. В плюсе остаются все: и сервер, и пользователь.

  • Посетитель сайта оперативно получает нужную ему информацию. Может быстро приступить к её изучению.

  • Ему не приходится тратить время, ожидая, пока отобразится искомый контент. В среднем, если время ответа сервера превышает 3-4 секунды, пользователь покидает сайт и уходит на другой.

  • Отзывчивый сайт с хорошим показателем TTFB получает потенциального клиента, а не возросшее количество отказов.

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

  • Оптимизация сервера и повышение скорости его работы позволяют снять часть нагрузки с «железа».


TTFB в идеале должен находиться в пределах 300 миллисекунд (некоторые допускают 400 миллисекунд). Если ответ сервера возникает раньше, здорово! Например, вот такие показатели демонстрирует сайт Студии ЯЛ.



Один из способов мы вам уже показали – воспользоваться Яндекс.Вебмастером. А точнее инструментом, который так и называется «Проверка ответа сервера». При этом даже необязательно регистрироваться. Достаточно добавить ссылку на анализируемый сайт и в поле «Робот» выбрать робота, который вас интересует. Теперь жмём «Проверить» и через несколько секунд изучаем результат.



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


Ищите нужную информацию следующим образом:

  1. Заходим на Яндекс.Метрику, вводим в строку URL сайта;

  2. Открываем графу «Отчёты», затем «Стандартные отчёты», «Мониторинг», «Время загрузки станиц».

  3. Уточняем промежуток времени, который вас интересует, и удобный вид графика.

  4. Спускаемся ниже, смотрим данные по разным параметрам, в том числе и «Ответ сервера».


Узнать, не превышает ли время ответа сервера 3 секунды, можно и через Google Analytics. Система имеет довольно сложный интефейс, поэтому отыскать требующийся раздел проще всего через поисковую строку. Забейте слова «скорость» или «speed». Дальше выбирайте отчёт «Скорость сайта» и подраздел «Обзор».



Достаточно простым и удобным считается сервис Bitcatcha, показывающий время ответа сервера в разных уголках мира. Что приятно, он бесплатный и им можно пользоваться без регистрации. Для начала работы нужно лишь вбить в специальную строку ссылку на сайт. Вот, например, какие данные сервис собрал по сайту Студии ЯЛ.



Следующий способ – прописывание в футере скрипта для проверки времени ответа. Выглядит это так:



Если помимо долгого ответа сервера вы обеспокоены медленной загрузки страниц сайта, выясните ее скорость при помощи таких сервисов, как Google PageSpeed Insights, Pingdom Tools, Gmetrix и Free Website Speed Test. Подробнее об их преимуществах и недостатках рассказали в обзоре популярных сервисов-помощников.


Увеличение времени ответа сервера может быть спровоцировано целым рядом факторов. Перечислим самые распространённые:

Пренебрежение модулями кэширования


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

Неправильная настройка базы данных


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


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

«Перемудрённая» логика обработки данных


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

Зависимость от сторонних сервисов, на которые полагается сайт


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

Некорректно выбранный тип сервера


Частотная ошибка – использование сервера Apache, а не Nginx. Дело в том, что Apache не способен работать с большим массивом запросов – это не подразумевает его архитектура. Как следствие, даже при передаче статических файлов могут быть заметны существенные задержки ответа сервера.


Слабый хостинг


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

Особенности CMS


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


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

  1. Для начала проверьте, может, увеличение времени ответа сервиса вызывали «кривые» плагины, которые используются в CMS. Оцените корректность работы дополнений. Проведите тест: отключите плагины, понаблюдайте, как изменилась скорость работы сайта. Если разница заметная, то поочередно подключайте дополнения, выявляя таким образом «слабые звенья». Определив проблемный плагин, избавьтесь от него.

  2. Иногда уменьшить время ответа сервера удаётся с помощью смены шаблона. Чтобы выяснить, поможет ли этот шаг, также проводим эксперимент. Меняем нынешний шаблон на другой, вставляем туда свой код, переносим нужные для работы проекта данные. Оцениваем изменения. Скорость загрузки сайта выросла? Тогда проблема действительно была в шаблоне, а значит, он реально требовал замены.

  3. Скорость загрузки сайта может страдать из-за атаковавших сервер вирусов. Для их выявления используют онлайн-сервисы или скрипты, прописываемые в коде.

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

  5. Также можно уменьшить время ответа сервера, установив плагин для сжатия данных.

  6. Мы уже упоминали ситуации, когда требуется произвести смену хостинга. Заметили, что все проекты, размещаемые на «железе» вашего провайдера, подтормаживают? Меняйте провайдера или местонахождение дата-центра, на котором располагается контент вашего веб-ресурса.

  7. Ну и как обойтись без кэширования страниц? Включить эту функцию можно в настройках CMS или в ручном режиме в файле .htacess.


Определение времени ответа сервера обязательно выполняется при запуске кампании по SEO-продвижению, улучшению юзабилити сайта, повышению конверсии. Также без этого шага немыслимы работы по повышению скорости ресурса. TTFB нужно проверять на каждом типе страниц – от карточек товаров до разделов и категорий. И этот процесс, и оптимизация времени ответа сервера подразумевают применение определённых знаний и навыков. Без помощи высококлассных специалистов тут не обойтись.


Если вы хотите, чтобы над вашим проектом работали профессионалы, обратитесь в Студию ЯЛ. Мы оперативно выявим, почему время ответа сервера у вашего сайта превышает нормативные 3 секунды, и предложим оптимальный способ устранения проблемы. Оставить заявку на услуги Студии ЯЛ или задать интересующие вопросы можно по телефонам 8 (383) 209-18-36 и 8-800-600-36-20.


 Другие материалы:

  • Как продвигать свой адалт-сайт: изучаем теорию, делимся наработками

  • Как сервисы продают кликджекинг, законен ли он, и что об этом думает Яндекс

  • Что такое поисковые фильтры Яндекса, и как под них не попасть

Время Ответа Сервера — Правильно замерять, гарантированно сократить

По рекомендациям Google время ответа сервера должно составлять менее 50 млс. , но лишь 1% сайтов в интернете обладают этим показателем! Внедрите сегодня наши рабочие способы сокращения отклика, для гарантированного повышения позиций в Google и Yandex!

При продвижении любого сайта, важнейшим фактором ранжирования сайта в результатах поисковой выдачи является время ответа сервера, скорость загрузки сайта, объем и качество кода.
Второе по важности, после уникального, необычно-интересного и читаемого текста, ссылочной массы. Если хотите, чтобы Ваш сайт был в ТОП-е результатов поиска — отнеситесь к этому показателю крайне серьёзно и ответственно!

Специалистами MOZ были проведены массовые исследования, доказавшие существенное влияние времени отклика сервера на позиции сайтов!

Время ответа сервера — что это, где оно берется и какие технические факторы на него влияют?

TTFB (Time To First Byte) — время до получения первого байта страницы, после отправки запроса на её получение браузером, эмулятором, программой.

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

  • Когда уходит запрос к серверу, он проходит через расстояние от пользователя(кто отправил запрос) к серверу. Это расстояние (клиент-сервер) подразумевается под понятием «шнурок»
  • Браузер отправляет данные серверу: куки, IP-адрес, оборудование, откуда пришел, хост с какого пришел и другие данные (их много).
  • HTTP сервер Apache принимает и слаживает данные, отправленные браузером в качестве заголовков, берет данные сервера, для работы скриптов в глобальный массив «SERVER»
  • Сервер начинает читать сайт, начиная с файла index.php (по умолчанию), анализировать синтаксис кода и исполнять. Чем больше кода, используемых условий и вызываемых функций — тем больше действий и времени на их совершение.
  • На выходе, получается, синтерпретированный HTML-код страницы, который отдается браузеру.
  • HTTP сервер Apache конвертирует html-код в байт-код, возвращая по «шнурку» обратно клиенту, отправившему запрос на получение страницы сайта.

Каждый из перечисленных этапов к получению любой веб-страницы сайта забирает время, но второй этап чтения и обработки файлов сайта (время интерпретации) забирает более 80% ответа сервера.

Почему сервер долго отвечает?

Большинство сайтов, созданных на CMS-системах, фреймворках, библиотеках, ООП, содержат в себе мусорный код (шлак), заставляя сервер выполнять миллионы ненужных действий и операций. Миллионы!!! Почему так происходит и какие причины этих бессмысленных действий:

  • По результатам многократного тестирования экспертами, использование большинством веб-студий вех CMS-систем, фреймворков, библиотек и ООП в PHP (процедурного стиля программирования) замедляют ответ сервера в 500 раз. Эти популярные программные продукты, подключают все библиотеки, классы, и начинают их читать и выполнять подряд (процедурно). Это создает большую нагрузку на оборудование сервера и забирает много времени. При малейших изменениях сайт «сыпется».
  • Отсутствие индивидуальной и грамотно-продуманной архитектуры проекта и индивидуального написания программного чистого кода сайтов (HTML, CSS, JavaScript, PHP).
  • Использование готовых баз данных, например, MySQL. Любые операции з данными (чтение, запись, удаление), требуют в 2 раза больше времени, чем те же операции с файлами, а только одно подключение к MySQL требует больше времени, чем время интерпретации сайта на чистом коде. А подключений много!

Было замеряно время интерпретации сайтов, на готовых CMS-системах и фреймворках, которые выполняют самые простые задачи:

Обратите внимание! Различные тестирования должны проводиться на одном оборудовании и при равных условиях. Тестирования проводились на оборудовании Emachines E729Z, с процессором Intel Pentium CPU P6200, 2 ядра (2. 13 GHz). На любом другом оборудовании, результаты будут отличаться.

  • WordPress — 0.47002696990967 сек.
  • Joomla — 0.31301784515381 сек.
  • OpenCart — 0.12800693511963 сек.
  • YII — 0.29201698303223 сек.

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

  • WordPress — у 467-500 раз
  • Joomla — у 313 раз
  • OpenCart — у 128 раз
  • YII — у 292 раза
  • Bitrix — у 238 раз
  • Более лёгкие CMS, фреймворки проигрывают чуть меньше, но это, к большому сожалению, никак не спасает ситуацию.

Обратите внимание: на время ответа сервера влияет сам сервер (компьютер, хранящий Ваш сайт), скорость и качество интернет-кабеля, нагрузка на ЦП сервера и кабель, и как не странно, операционная система.

Несколько полезных моментов:

  • Хостинг, независимо от цены, хранит в себе много сайтов (около сотни и более) и как правило, они созданы на CMS-системах, Framework, которые работают у 180-500 раз медленнее, что в результате сам ПК хостинга работает медленно.
  • На 95% хостингах подключен интернет-кабель скоростью в 100 МБ/сек. и таковой скорости, к сожалению, очень мало для такого количества сайтов.
  • ОС существенно влияет на скорость ответа сервера и в этом я сам многократно был убежден. Я арендовал 5 VDS (выделенных серверов) с установленной операционкой «Cent OS». Открыл PageSpeed, указал ссылку на пустой PHP-скрипт и получил скорость ответа в 500 млс. Конечно это медленная скорость ответа и я сменил ОС на «Ubuntu». Снова открыл «PageSpeed», указывая ссылку на пустой PHP-скрипт и ответ сервера составил 20 млс. Такая ситуация была на всех пятерых VDS-серверах! Отсюда вывод: каждой ОС свойственна разная скорость работы, поэтому рекомендую выбирать Ubuntu, поскольку она лёгкая и шустрая!

Какое идеальное время ответа сервера?

  • Хуже некуда — даже чуть более 200 мс.
  • Самый идеальный — до 50 мс.(рекомендуемый поисковыми системами)

Чем меньше — тем лучше! Представьте, что Вы владелец поисковой системы и программе-боту Вашей ПС нужно просканировать миллионы сайтов за сутки. Разве будет выгодно ждать ответ от сервера некачественного сайта, чтобы его просканировать?
Или лучше просканировать сайт, который в 500 раз быстрее отвечает?

Получается вместо одного некачественного сайта, можно просканировать 500 сайтов с мгновенным ответом и качественным кодом. Поисковые системы GOOGLE и YANDEX внедрили алгоритм, который сканирует и гарантированно одобряет сайты в топ с идеальным временем ответа сервера и качественным HTML, CSS и JavaScript-кодом при равных условиях.

Узнаем точное время ответа сервера

Безусловно, время ответа сервера нужно измерять инструментами от поисковых систем.

  • PageSpeed сервис от Google. Вбейте адрес проверяемого сайта, нажав на кнопку «Анализировать» дождитесь результатов анализа. Время ответа сервера будет указано в пункте «Диагностика», или в «Успешные аудиты». Найдя строку «Короткое время ответа сервера (время до получения первого байта)» Вы увидите время ответа сервера.
  • Yandex Webmaster Если сайт продвигается в Яндексе, советую измерять время ответа сервера именно этим способом, а так же приобретать хостинг в России. Для проверки перейдите в пункт «проверка ответа сервера» и указав ссылку на проверяемый сайт Вы увидите результат и время ответа.

Обратите внимание! Расстояние от сервера Google и Yandex к серверу, хранящим сайт разное и за счет «шнурка» результаты проверки будут отличаться. Обязательно делайте несколько замеров подряд, найдя средние результаты.

Google PageSpeed

Yandex Webmaster

Как сократить время ответа сервера

Из вышенаписанного помним, что время интерпретации (чтение и обработка файлов сайта) влияет на ответ сервера более, чем на 80%.

Большинство веб-студий и «разработчиков» утверждают в один голос, что даже на практике время ответа сервера 200 мс получить невозможно.
Отвечу: на любых популярных CMS-системах, библиотеках, фреймворках, добиться ответа даже до 200 мс невозможно и что тут уже говорить о идеальном времени менее 50 мс.

Чтобы получить время ответа сервера, почти нулевое (7-50 мс) — нужен программист, который не использует «ШЛАК», а хорошо знает HTML, CSS, JavaScript, PHP, имеет опыт более 7 лет и пишет сайты, придерживаясь следующих обязательных правил:

  • Всегда продумывайте несколько раз архитектуру (ядро) сайта. Рисуйте архитектуру файлов и папок на листе бумаги.
  • Тщательно продумайте структуру (ядро) базы данных Вашего проекта. Делайте это под каждый проект индивидуально. Прорабатывайте структуру базы письменно.
  • Пишите чистый HTML, CSS, JavaScript, PHP код индивидуально, под конкретные задачи (чтобы можно быстро изучить, дополнить, отредактировать код (скрипт). Эксперту в этой области индивидуальное написание займёт далеко не больше времени, чем брать готовые решения.
  • Не используйте сторонние приложения баз данных, как MySQL и другие. Хорошо и грамотно продуманная индивидуально база работает быстрее в 2 раза.
  • НИКОГДА не пользуйтесь готовыми решениями (велосипедами), в частности CMS, Framework, библиотеки. В них много незадействованного кода, который не выполняется.
  • Всегда думайте, как написать скрипт, выполняющий как можно меньше действий, с целью максимального облегчения нагрузки на оборудование сервера и пользователя. Нужно знать и всегда проверять, какие функции быстрее работают. Взвешивать общую картину.

Если Вы не пишите на чистом коде и используете CMS, Framework, MySQL, ООП и др. готовые решения — могу посоветовать работающие способы:

  • Включите кэширование страниц, это позволит избежать созданию запросов к БД и обращение к скриптам, генерации страниц.
  • Удержитесь от использование шаблонизаторов в своих проектах.
  • Сменить хостинг на дорогой VDS, или VPS с ОС Ubuntu.

К большому сожалению эти рекомендации не помогут добиться идеального времени ответа сервера, ведь если причина в коде — не поможет самый дорогой сервер! Мы арендуем дешевый VPS-сервер за $6 и ответ сервера составляет 20-30 млс, поскольку мы придерживаемся вышеупомянутой схемы и не используем готовых решений вообще!

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

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

opencart — Время отклика сервера веб-сайта Open Cart велико

спросил

Изменено
3 года, 6 месяцев назад

Просмотрено
65 раз

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

  • открытая тележка

3

Самый простой способ — использовать модуль Cache, который реализует функции оптимизации скорости, такие как сжатие изображений, кэширование, минимизация файлов и CDN.

проверить на наличие ошибок

Вам необходимо проверить, есть ли у вас какие-либо проблемы в файле журнала (system/storage/logs/error.log), и если они есть, исправить их. ошибки могут привести к падению скорости.

сгладить структуру категорий

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

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

так что берегитесь тех.

найти лучший хостинг

И последнее, но не менее важное — ваш хостинг-провайдер. Проверьте, действительно ли ваш хостинг предоставляет вам быстрый сервер. Мы часто предлагаем остановить свой выбор на Digital Ocean, так как ребята проделали хорошую работу, предоставив высококачественные серверы по разумной цене. если вы хотите 10 долларов при регистрации в DO и чувствуете себя комфортно, если мы также получим 10 долларов, воспользуйтесь нашей ссылкой на Digital Ocean или просто посетите их веб-сайт digitalocean.com

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя электронную почту и пароль

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

php — время первого байта для сайта электронной коммерции opencart огромно

Задавать вопрос

спросил

Изменено
8 лет, 2 месяца назад

Просмотрено
1к раз

Я проверил статистику сайта на http://www. webpagetest.org/ для сайта электронной коммерции: он дал следующий отчет —-

 Документ завершен, полностью загружен
Время загрузки Первый байт Старт Индекс скорости рендеринга Элементы DOM
Первый просмотр 20.995 с 15,718 с 16,492 с 19760 1177 20,995 с 117 2 357 КБ 22 904 с 161 2 827 КБ
Повторный просмотр 9,804 с 8,200 с 8,623 с 9596 1177 9,804 с 10 351 КБ 11 276 с 37 476 КБ

Я проверил свой сервер с помощью команды top и проверил, что mysql занимает 99% CPU% времени и 214:26,79 в TIME+ .

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

 mysql> показать переменные типа 'innodb_buffer_pool_size';
+-------------------------+------------+
| Имя_переменной | Значение |
+-------------------------+------------+
| innodb_buffer_pool_size | 134217728 |
+-------------------------+------------+
1 ряд в наборе (0,00 сек)
mysql> показывать переменные типа 'innodb_flush_log_at_trx_commit';
+-----------------+--------+
| Имя_переменной | Значение |
+-----------------+--------+
| innodb_flush_log_at_trx_commit | 1 |
+-----------------+--------+
1 ряд в наборе (0,00 сек)
mysql> показывать переменные типа 'innodb_open_files';
+-------------------+-------+
| Имя_переменной | Значение |
+-------------------+-------+
| innodb_open_files | 300 |
+-------------------+-------+
1 ряд в наборе (0,00 сек)
mysql> показывать переменные типа 'innodb_table_locks';
+--------------------+-------+
| Имя_переменной | Значение |
+--------------------+-------+
| innodb_table_locks | НА |
+--------------------+-------+
1 ряд в наборе (0,00 сек)
mysql> показывать переменные типа 'innodb_thread_concurrency';
+---------------------------+--------+
| Имя_переменной | Значение |
+---------------------------+--------+
| innodb_thread_concurrency | 0 |
+---------------------------+--------+
1 ряд в наборе (0,00 сек)
mysql> показывать переменные типа 'join_buffer_size';
+------------------+---------+
| Имя_переменной | Значение |
+------------------+---------+
| присоединиться_buffer_size | 131072 |
+------------------+---------+
1 ряд в наборе (0,00 сек)
mysql> показывать переменные типа 'key_buffer_size';
+-----------------+-----------+
| Имя_переменной | Значение |
+-----------------+-----------+
| key_buffer_size | 16777216 |
+-----------------+-----------+
1 ряд в наборе (0,00 сек)
mysql> показывать переменные типа «max_connections»;
+-----------------+--------+
| Имя_переменной | Значение |
+-----------------+--------+
| макс_подключения | 151 |
+-----------------+--------+
1 ряд в наборе (0,00 сек)
mysql> показывать переменные типа «max_delayed_threads»;
+---------------------+--------+
| Имя_переменной | Значение |
+---------------------+--------+
| max_delayed_threads | 20 |
+---------------------+--------+
1 ряд в наборе (0,00 сек)
mysql> показывать переменные типа «max_heap_table_size»;
+---------------------+-----------+
| Имя_переменной | Значение |
+---------------------+-----------+
| max_heap_table_size | 16777216 |
+---------------------+-----------+
1 ряд в наборе (0,00 сек)
mysql> показывать переменные типа «max_tmp_tables»;
+----------------+--------+
| Имя_переменной | Значение |
+----------------+--------+
| max_tmp_tables | 32 |
+----------------+--------+
1 ряд в сете (0,01 сек)
mysql> показывать такие переменные, как 'thread_cache_size';
+-------------------+-------+
| Имя_переменной | Значение |
+-------------------+-------+
| thread_cache_size | 8 |
+-------------------+-------+
1 ряд в наборе (0,00 сек)
mysql> показывать переменные типа 'tmp_table_size';
+----------------+----------+
| Имя_переменной | Значение |
+----------------+----------+
| tmp_table_size | 16777216 |
+----------------+----------+
1 ряд в наборе (0,00 сек)
mysql> показывать переменные типа 'wait_timeout';
+---------------+-------+
| Имя_переменной | Значение |
+---------------+-------+
| время_ожидания | 28800 |
+---------------+-------+
1 ряд в наборе (0,00 сек)
mysql> показывать такие переменные, как 'myisam_sort_buffer_size';
+-------------------------+----------+
| Имя_переменной | Значение |
+-------------------------+----------+
| myisam_sort_buffer_size | 8388608 |
+-------------------------+----------+
1 ряд в наборе (0,00 сек)

Я думаю, что задержка первого байта в основном связана с конфигурацией mysql или opencart framework.