Как измерить / протестировать скорость MySQL, Postgresql, MongoDB, где так много слоев кэша? - PullRequest
1 голос
/ 26 сентября 2010

Я думаю, что с SQLite3, по крайней мере, он не сохраняет кэшированные страницы, потому что нет сервера, и каждая запись завершает работу SQLite3, поэтому он не может напрямую выполнять кэширование.В MySQL, Postgresql или MongoDB будет слой, который, когда считается, что данные уже сохранены, фактически находится в кеше памяти СУБД ... для последующей записи на диск.

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

А также кэш жесткого диска.При размере 8 МБ, возможно, когда тест вставляет данные, создавая базу данных объемом 800 МБ, ошибка может составлять 1% или менее.

Но как быть с другими уровнями?Там действительно должно быть сбрасывать до уровня ОС.В противном случае на компьютерах, имеющих 4 ГБ ОЗУ или 8 ГБ ОЗУ, вся база данных может легко находиться в ОЗУ, если она считается достаточно быстрой.Как мы скажем тесту сбросить данные до физического уровня жесткого диска или, по крайней мере, из уровня ОС?

1 Ответ

1 голос
/ 26 сентября 2010

Когда вы проводите бенчмаркинг, вы никогда не сможете отменить все оптимизации скорости на каждом уровне вплоть до уровня ОС или даже уровня ЦП, включая кеширование. Тебе это не нужно. Что вы можете сделать, это оценить производительность в различных состояниях жизненного цикла вашей системы. Кроме того, если вы знаете, какие данные кэшируются, когда (приблизительно) вы можете сделать тест до и после этого. Например - чистый запуск, доступ к первому набору данных БД, последующий доступ к БД и т. Д. Лучше всего сначала установить узкие места, а затем тестировать только там. Еще одна хорошая практика - это моделировать нагрузку на систему в реальном времени и измерять ее. Любые синтаксические тесты практически бессмысленны. Удачи;)

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