Mysql
 sql >> база данни >  >> RDS >> Mysql

Измервател на времето за пинг - това наистина ли е вярно?

За щастие това обикновено не означава това.

Липсващата променлива във вашето уравнение е как вашата база данни и вашия сървър за приложения и всичко друго във вашия стек обработва паралелност .

За да илюстрирам това стриктно от гледна точка на MySQL, написах тестова клиентска програма, която установява фиксиран брой връзки към MySQL сървъра, всяка в своя собствена нишка (и така, може да издаде заявка към сървъра приблизително по едно и също време) .

След като всички нишки сигнализират обратно, че са свързани, до всички се изпраща съобщение едновременно, за да изпратят заявката си.

Когато всяка нишка получи сигнала „стартиране“, тя разглежда текущото системно време, след което изпраща заявката до сървъра. Когато получи отговора, отново преглежда системното време и след това изпраща цялата информация обратно към основната нишка, която сравнява времето и генерира изхода по-долу.

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

Заявката беше SELECT SQL_NO_CACHE COUNT(1) FROM ... (таблица InnoDB с около 500 реда в нея).

threads  1 min 0.001089 max 0.001089 avg 0.001089 total runtime 0.001089
threads  2 min 0.001200 max 0.002951 avg 0.002076 total runtime 0.003106
threads  4 min 0.000987 max 0.001432 avg 0.001176 total runtime 0.001677
threads  8 min 0.001110 max 0.002789 avg 0.001894 total runtime 0.003796
threads 16 min 0.001222 max 0.005142 avg 0.002707 total runtime 0.005591
threads 32 min 0.001187 max 0.010924 avg 0.003786 total runtime 0.014812
threads 64 min 0.001209 max 0.014941 avg 0.005586 total runtime 0.019841

Времената са в секунди. Мин./макс./ср. са най-добрите/най-лошите/средните времена, наблюдавани при изпълнение на една и съща заявка. При едновременност от 64 забелязвате, че най-добрият случай не е толкова различен от най-добрия случай само с 1 заявка. Но най-големият извод тук е колоната общо време на изпълнение. Тази стойност е разликата във времето от момента, когато първата нишка е изпратила заявката си (всички те изпращат заявката си по същество по едно и също време, но "точно" едно и също време е невъзможно, тъй като нямам 64-ядрена машина, която да стартира тестов скрипт включен) до момента, когато последната нишка е получила своя отговор.

Наблюдения:добрата новина е, че 64-те заявки, които отнемат средно 0,005586 секунди, определено не изискват 64 * 0,005586 секунди =0,357504 секунди за изпълнение... дори не изискват 64 * 0,001089 (време за най-добрия случай)69 =606. от тези заявки са стартирани и завършени в рамките на 0,019841 секунди... или само около 28,5% от времето, което теоретично би им отнело да се изпълняват една след друга.

Лошата новина, разбира се, е, че средното време за изпълнение на тази заявка при едновременност от 64 е над 5 пъти по-високо от времето, когато се изпълнява само веднъж... а в най-лошия случай е почти 14 пъти по-високо. Но това все пак е далеч по-добре, отколкото би предполагала линейна екстраполация от времето за изпълнение на една заявка.

Нещата обаче не се мащабират безкрайно. Както можете да видите, производителността се влошава с едновременност и в един момент тя ще тръгне надолу - вероятно доста бързо - когато достигнем кое от двете затруднения се случи първо. Броят на таблиците, естеството на заявките, всяко заключване, което се среща, допринасят за това как сървърът се представя при едновременни натоварвания, както и производителността на вашето хранилище, размерът, производителността и архитектурата, на паметта на системата и вътрешните елементи на MySQL – някои от които могат да бъдат настроени, а други не.

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

Едно голямо неизвестно от вашите бенчмаркове е колко от това време се изразходва от базата данни в отговор на заявките, колко от времето е изразходвано от сървъра на приложения за изпълнение на логическата дейност и каква част от времето се изразходва от кода, който е изобразяване на резултатите от страницата в HTML.




  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Заобиколно решение на Mysql за функциите на прозореца

  2. MySQL - какво прави блокирането на прескачане в my.cnf?

  3. SQL обединяване на данни от множество таблици с MYSQL

  4. Премахнете клаузата за ограничение от MySQL Workbench

  5. Сравняване на Null с друга стойност в MySQL Trigger