Как сравнить php/mysql сайта

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

:: fn_dblog
Это позволяет Вам запрашивать журнал транзакций для базы данных.

USE mydatabase;
SELECT *
FROM ::fn_dblog(NULL, NULL)

http://killspid.blogspot.com/2006/07/using-fndblog.html

23
задан Mihai 26 November 2015 в 20:52
поделиться

5 ответов

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

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

Например, вы можете запустить 50 клиентов, каждый из которых выполняет тестовый план 10 раз.

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

Это позволяет вам настраивать различные параметры, пробовать разные стратегии кэширования и проверять реальное влияние этих изменений на мир.

16
ответ дан 29 November 2019 в 02:30
поделиться

Вы можете использовать инструмент ApacheBench (ab, обычно является частью пакета веб-сервера apache) для стресс-тестирования (1k запросы с 10 клиентами = ab -c 10 -n 1000 http: // url ) скрипта, который, как вы подозреваете, может быть достаточно медленным. Он покажет вам распределение времени ответа (в 90% случаев запрос обрабатывается менее чем за 200 мс).

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

Что касается количества пользователей, которые он может обслуживать - вы можете использовать свой любимый браузер и имитировать посещение обычного пользователя, взять файл access_log и просуммировать отправленные байты (одно из последних чисел в строке журнала). Например, это было 5 КБ текста / html + 50 КБ png / jpg / и т. Д. = 55 КБ на посещение пользователя. Плюс заголовки и т. Д., Скажем, 60 КБ за посещение * 1 м = 60 ГБ трафика в день. Достаточно ли у вас пропускной способности для этого? (60 ГБ / 86,4 кбит / с = 700 кбит / с).

8
ответ дан 29 November 2019 в 02:30
поделиться

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

Для мониторинга я измеряю время выполнения каждого запроса в моем объекте абстракции БД. Затем для каждого запроса, который занимает больше X миллисекунд (введите свой собственный X), я пишу строку в свой файл журнала запросов, который идентифицирует файл сценария PHP и номер строки, в которой появился запрос (используйте debug_backtrace () , чтобы найти эту информацию) вместе с другими соответствующими контекстными данными (например, идентичность пользователя, дата-время и т. Д.).

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

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

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

5
ответ дан 29 November 2019 в 02:30
поделиться

Что наиболее важно, вам необходимо определить, какой должна быть производительность: вы можете всегда найти области для оптимизации. Однако улучшение времени отклика с 750 мс до 650 мс не стоит потраченного времени.

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

Если это ваше приложение, используйте xdebug для профилирования вашего PHP-кода. Затем используйте WinCacheGrind или KCacheGrind для анализа вывода. Это может вас удивить.

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

2
ответ дан 29 November 2019 в 02:30
поделиться

У меня нет опыта работы с инструментами тестирования, но в некоторых случаях я создаю простую таблицу с полями id , ipaddress , parsetime , запросы . Просто вставляйте новую строку каждый раз, когда страница обновляется или вызывается (в ситуациях с ajax). Затем проанализируйте данные, собранные за неделю / месяц / квартал / год. Это не ваша предпочтительная ситуация, но простой способ получить некоторую статистику в короткие сроки.

Некоторые результаты тестов PHP: http://www.google.nl/search?hl=nl&source=hp&q=php+benchmark&meta=&aq=f&oq=

0
ответ дан 29 November 2019 в 02:30
поделиться
Другие вопросы по тегам:

Похожие вопросы: