Назад | Перейти на главную страницу

TTFB Дольше в Google Cloud, чем AWS с той же конфигурацией

Длинный тайник, первый плакат в сети StackExchange.

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

Я установил блок EC2 бесплатного уровня в качестве промежуточной машины на Ubuntu 14.04 с LEMP, в частности, на Nginx и PHP7 с WordPress. Мы создали сайт, все работает нормально. TTFB составляет 505 миллисекунд.

Я устанавливаю блок облачных вычислений бесплатного уровня в качестве производственной машины с той же конфигурацией, но TTFB составляет 14 секунд. Знайте, что спецификации на коробке Google немного лучше, чем на EC2. g1-small (1 виртуальный ЦП, 1,7 ГБ памяти) по сравнению с t2-micro (1 виртуальный ЦП, 1 ГБ памяти). SSD с обеих сторон.

Я пробовал много вещей, в том числе многие методы диагностики проблем TTFB, которые указаны в этом ответе. https://serverfault.com/a/350422. Я также пробовал увеличить объем памяти для PHP и WordPress. Я пробовал устанавливать пакеты и плагины, которые люди предлагают для оптимизации производительности. Я особенно борюсь с тем фактом, что моему промежуточному экземпляру ничего из этого не требовалось. Прежде чем вы спросите «почему бы вам просто не сделать все это на AWS», знайте, что использование Google Cloud Compute для производства является обязательным требованием для этого проекта.

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

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

ИЗМЕНИТЬ ОДИН: Отвечая на вопросы ниже. Большое спасибо за предложение помощи.

Два сервера находятся в одном географическом местоположении? Насколько велика разница?

Экземпляр EC2 находится на востоке США или в Вирджинии. Экземпляр GCE находится в US-West1a, который, как я полагаю, находится в Орегоне. Я нахожусь в Нью-Йорке, поэтому географической разницы недостаточно, чтобы оправдать 14-секундный TTFB. Кроме того, инструменты, которые я использовал, имеют географическое положение, такое как Даллас (разумная середина между двумя городами), и также сообщают о TTFB за 14 секунд.

Первое, что нужно выяснить, это где задержка. Измените свой вопрос, включив> изгиб веб-сайта Google, соответствующую запись журнала доступа Nginx, любую> соответствующую запись журнала ошибок Nginx и журналы доступа / ошибок PHP. Необходимо включить доступ к PHP> журналам. Также посмотрите «сверху», пока происходит завиток, и сделайте> типичный снимок экрана. Наконец, поделитесь тестами webpagetest.org для> обеих сред, чтобы продемонстрировать проблему, запутанные, если ваши доменные имена> являются секретными - поисковые роботы все равно находят все домены. - Тим 3 часа назад

У меня недостаточно очков репутации, чтобы опубликовать изображение или ссылку на другое изображение, но когда я запускаю его, появляется всплывающее окно php-fpm7.0 и mysqld.

PID USER PR NI VIRT RES SHR S% CPU% MEM TIME + COMMAND 24625 www-data 20 0 374680 43352 30376 S 0.7 2.5 0: 00.90 php-fpm7.0 21244 mysql 20 0 870388 71088 11012 S 0.3 4.1 0: 10.57 mysqld

Здесь нет ничего нового в этом запросе

В журналах PHP-FPM ничего нет.

Ничего из этого запроса, но я сделал запрос браузера до этого, и вот что находится в медленном журнале (я установил окно на 5 секунд):

[07-May-2017 06:01:48]  [pool www] pid 24625
script_filename = /var/www/html/wordpress/index.php
[0x00007fad55e12810] mysqli_real_connect() /var/www/html/wordpress/wp-
includes/wp-db.php:1540
[0x00007fad55e126f0] db_connect() /var/www/html/wordpress/wp-includes/wp-db.php:658
[0x00007fad55e12620] __construct() /var/www/html/wordpress/wp-content/themes/xxxx/inc/artist-products.php:7
[0x00007fad55e12590] edb_db_init() /var/www/html/wordpress/wp-content/themes/xxxx/inc/db/items.php:258
[0x00007fad55e124d0] edb_get_product_link() /var/www/html/wordpress/wp-content/themes/xxxx/inc/artist-products.php:23
[0x00007fad55e123c0] edb_display_frontpage_items() /var/www/html/wordpress/wp-content/themes/xxxx/page-templates/home.php:95
[0x00007fad55e121e0] [INCLUDE_OR_EVAL]() /var/www/html/wordpress/wp-includes/template-loader.php:74
[0x00007fad55e12140] [INCLUDE_OR_EVAL]() /var/www/html/wordpress/wp-blog-header.php:19
[0x00007fad55e120a0] [INCLUDE_OR_EVAL]() /var/www/html/wordpress/index.php:17

https://www.screencast.com/t/vxHTCcyf

https://www.screencast.com/t/22OXgA7T

Самое очевидное, что можно попробовать, - это написать скрипт приветствия php> barebones и измерить ttfb этого, если вы этого не сделали. Если это где-то около 14, то> у вас проблема, не имеющая ничего общего с wordpress или базой данных. > «Google Cloud не имеет сброса вывода» применяется к HTTP-ответам Google App Engine>, которые возвращаются блоком, поэтому это не применимо к> вычислительным экземплярам.

Ага, я сделал это. Hello World и другие статические файлы отвечают быстро. PHPInfo также быстро реагирует. Если я правильно помню, все простые и статические файлы были около 700 мс TTFB. Благодарим за пояснения по поводу промывки выходных данных, относящихся только к App Engine. По крайней мере, я знаю там является простое решение, которое мне просто не хватает.

Единственное, что дает мне возможность работать, это медленное ведение журнала PHP. 

[07-May-2017 00:56:39]  [pool www] pid 24793
script_filename = /var/www/html/wordpress/index.php
[0x00007fad55e14810] mysqli_real_connect() /var/www/html/wordpress/wp-includes/wp-db.php:1540
[0x00007fad55e146f0] db_connect() /var/www/html/wordpress/wp-includes/wp-db.php:658
[0x00007fad55e14620] __construct() /var/www/html/wordpress/wp-content/themes/xxxx/inc/artist-products.php:7
[0x00007fad55e14590] edb_db_init() /var/www/html/wordpress/wp-content/themes/xxxx/inc/db/items.php:258
[0x00007fad55e144d0] edb_get_product_link() /var/www/html/wordpress/wp-content/themes/xxxx/inc/artist-products$
[0x00007fad55e143c0] edb_display_frontpage_items() /var/www/html/wordpress/wp-content/themes/xxxx/page-templat$
[0x00007fad55e141e0] [INCLUDE_OR_EVAL]() /var/www/html/wordpress/wp-includes/template-loader.php:74
[0x00007fad55e14140] [INCLUDE_OR_EVAL]() /var/www/html/wordpress/wp-blog-header.php:19
[0x00007fad55e140a0] [INCLUDE_OR_EVAL]() /var/www/html/wordpress/index.php:1

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

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

Практически все аспекты производительности в GCP связаны с количеством процессоров - например, 2 ГБ сети на ядро ​​процессора. Кроме того, в Google Cloud g1-micro это разделяемое ядро машина. По ссылке:

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

В AWS t2.micro классифицируется как взрывной - что на первый взгляд похоже на модель общего ядра Google, но несколько отличается:

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

Чтобы выполнить точное сопоставление, я настоятельно рекомендую использовать более производительные типы инстансов с обеих сторон, чтобы гарантировать доступность ресурсов, например, Amazon m3.medium и Google n1-standard-1 - оба имеют 1 процессор и 3,75 ГБ оперативной памяти.

Чтобы удалить географию из вашего возможного списка виновников, я бы также разместил ваш экземпляр AWS в us-west-2, который также находится в Орегоне - он может быть дальше от вашего местоположения, но, по крайней мере, вы будете тестировать два экземпляра, которые находятся на одинаковом расстоянии, а не один рядом и один далеко.

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