PHP კონექტორების დაჩქარება Tarantool-ისთვის Async, Swoole და Parallel გამოყენებით

PHP ეკოსისტემაში ამჟამად არის ორი კონექტორი Tarantool სერვერთან მუშაობისთვის - ეს არის ოფიციალური PECL გაფართოება tarantool/tarantool-phpC-ში დაწერილი და tarantool-php/კლიენტიPHP-ში დაწერილი. ამ უკანასკნელის ავტორი მე ვარ.

ამ სტატიაში მსურს გაგიზიაროთ ორივე ბიბლიოთეკის შესრულების ტესტირების შედეგები და ვაჩვენო, თუ როგორ, კოდის მინიმალური ცვლილებებით, შეგიძლიათ მიაღწიოთ შესრულების 3-5 ზრდას (სინთეტიკურ ტესტებზე!).

რას ვამოწმებთ?

ჩვენ შევამოწმებთ ზემოთ ხსენებულებს სინქრონული კონექტორები მუშაობს ასინქრონულად, პარალელურად და ასინქრონულად პარალელურად. 🙂 ასევე არ გვინდა შევეხოთ თავად კონექტორების კოდს. ამჟამად არსებობს რამდენიმე გაფართოება, რომ მიაღწიოთ იმას, რაც გსურთ:

• სვული - მაღალი ხარისხის ასინქრონული ჩარჩო PHP-სთვის. გამოიყენება ისეთი ინტერნეტ გიგანტების მიერ, როგორიცაა Alibaba და Baidu. 4.1.0 ვერსიიდან გამოჩნდა ჯადოსნური მეთოდი SwooleRuntime::enableCoroutine(), რომელიც საშუალებას გაძლევთ „კონვერტირდეთ სინქრონული PHP ქსელის ბიბლიოთეკები ასინქრონულ ბიბლიოთეკებში ერთი კოდის ხაზით“.
• Async ბოლო დრომდე იყო ძალიან პერსპექტიული გაფართოება PHP-ში ასინქრონული მუშაობისთვის. რატომ ბოლო დრომდე? სამწუხაროდ, ჩემთვის უცნობი მიზეზის გამო, ავტორმა წაშალა საცავი და პროექტის მომავალი ბედი გაურკვეველია. მომიწევს მისი გამოყენება одним ჩანგლებიდან. Swoole-ს მსგავსად, ეს გაფართოება საშუალებას გაძლევთ მარტივად ჩართოთ შარვალი მაჯის მოძრაობით, რათა ჩართოთ ასინქრონულობა TCP და TLS ნაკადების სტანდარტული იმპლემენტაციის ჩანაცვლებით მათი ასინქრონული ვერსიებით. ეს კეთდება პარამეტრის საშუალებით "async.tcp = 1".
• პარალელურად - საკმაოდ ახალი გაფართოება ცნობილი ჯო უოტკინსისგან, ისეთი ბიბლიოთეკების ავტორი, როგორიცაა phpdbg, apcu, pthreads, pcov, uopz. გაფართოება უზრუნველყოფს API-ს PHP-ში მულტირედინგისთვის და პოზიციონირებულია, როგორც pthreads-ის შემცვლელი. ბიბლიოთეკის მნიშვნელოვანი შეზღუდვა ის არის, რომ ის მუშაობს მხოლოდ PHP-ის ZTS (Zend Thread Safe) ვერსიასთან.

როგორ გავტესტოთ?

მოდით გავუშვათ Tarantool-ის ინსტანცია გამორთულია წინასწარ ჩაწერით (wal_mode = არცერთი) და გაზრდილი ქსელის ბუფერი (წაკითხვა = 1 * 1024 * 1024). პირველი ვარიანტი აღმოფხვრის დისკთან მუშაობას, მეორე შესაძლებელს გახდის ოპერაციული სისტემის ბუფერიდან მეტი მოთხოვნის წაკითხვას და ამით მინიმუმამდე დაიყვანოს სისტემური ზარების რაოდენობა.

ბენჩმარკებისთვის, რომლებიც მუშაობენ მონაცემებთან (ჩასმა, წაშლა, წაკითხვა და ა.შ.), საორიენტაციო ნიშნის დაწყებამდე შეიქმნება memtx სივრცე, რომელშიც პირველადი ინდექსის მნიშვნელობები იქმნება შეკვეთილი მთელი რიცხვების გენერატორის მიერ. (თანმიმდევრობა).
სივრცე DDL ასე გამოიყურება:

space = box.schema.space.create(config.space_name, {id = config.space_id, temporary = true})
space:create_index('primary', {type = 'tree', parts = {1, 'unsigned'}, sequence = true})
space:format({{name = 'id', type = 'unsigned'}, {name = 'name', type = 'string', is_nullable = false}})

საჭიროების შემთხვევაში, საორიენტაციო ნიშნის გაშვებამდე, სივრცე ივსება ფორმის 10,000 ტირით.

{id, "tuplе_<id>"}

ტოპებზე წვდომა ხდება შემთხვევითი გასაღების მნიშვნელობის გამოყენებით.

ბენჩმარკი თავისთავად არის სერვერისადმი ერთჯერადი მოთხოვნა, რომელიც შესრულებულია 10,000-ჯერ (რევოლუციები), რომლებიც, თავის მხრივ, სრულდება გამეორებით. გამეორებები მეორდება მანამ, სანამ ყველა დროის გადახრები 5 გამეორებას შორის არ იქნება მისაღები ცდომილების ფარგლებში 3%*. ამის შემდეგ მიიღება საშუალო შედეგი. გამეორებებს შორის არის 1 წამის პაუზა, რათა თავიდან იქნას აცილებული პროცესორის დაძაბვა. ლუას ნაგვის შემგროვებელი გამორთულია ყოველი გამეორების წინ და იძულებულია დაიწყოს მისი დასრულების შემდეგ. PHP პროცესი გაშვებულია მხოლოდ საორიენტაციოდ საჭირო გაფართოებებით, გამომავალი ბუფერის ჩართვის და ნაგვის შემგროვებლის გამორთვით.

* რევოლუციების რაოდენობა, გამეორება და შეცდომის ბარიერი შეიძლება შეიცვალოს საორიენტაციო პარამეტრებში.

სატესტო გარემო

ქვემოთ გამოქვეყნებული შედეგები გაკეთდა MacBookPro-ზე (2015), ოპერაციული სისტემა - Fedora 30 (კერნელი ვერსია 5.3.8-200.fc30.x86_64). Tarantool ამოქმედდა დოკერში პარამეტრით "--network host".

პაკეტის ვერსიები:

Tarantool: 2.3.0-115-g5ba5ed37e
Docker: 19.03.3, build a872fc2f86
PHP: 7.3.11 (cli) (აშენებულია: 22 ოქტომბერი 2019 08:11:04)
ტარანტული/კლიენტი: 0.6.0
rybakit/msgpack: 0.6.1
ext-tarantool: 0.3.2 (+ patch for 7.3)*
ext-msgpack: 2.0.3
ext-async: 0.3.0-8c1da46
ext-swoole: 4.4.12
გარე პარალელი: 1.1.3

* სამწუხაროდ, ოფიციალური კონექტორი არ მუშაობს PHP ვერსიით > 7.2. PHP 7.3-ზე გაფართოების შედგენისა და გასაშვებად, მომიწია გამომეყენებინა პატჩი.

დასკვნები

სინქრონული რეჟიმი

Tarantool პროტოკოლი იყენებს ორობით ფორმატს MessagePack შეტყობინებების სერიალიზაციისთვის. PECL კონექტორში სერიალიზაცია იმალება ბიბლიოთეკის სიღრმეში და გავლენას ახდენს კოდირების პროცესზე მომხმარებლის ქვეყნის კოდიდან. არ ჩანს შესაძლებელი. პირიქით, სუფთა PHP კონექტორი იძლევა კოდირების პროცესის პერსონალურად მორგების შესაძლებლობას სტანდარტული ენკოდერის გაფართოებით ან საკუთარი იმპლემენტაციის გამოყენებით. ყუთში ორი შიფრატორია ხელმისაწვდომი, ერთი ეფუძნება msgpack/msgpack-php (ოფიციალური MessagePack PECL გაფართოება), მეორე ჩართულია rybakit/msgpack (სუფთა PHP-ში).

კონექტორების შედარებამდე ჩვენ გავზომავთ MessagePack ენკოდერების მუშაობას PHP კონექტორისთვის და შემდგომ ტესტებში გამოვიყენებთ მას, რომელიც აჩვენებს საუკეთესო შედეგს:

მიუხედავად იმისა, რომ PHP ვერსია (Pure) სიჩქარით ჩამორჩება PECL გაფართოებას, რეალურ პროექტებში მაინც გირჩევთ მის გამოყენებას rybakit/msgpack, რადგან ოფიციალურ MessagePack გაფართოებაში ფორმატის სპეციფიკაცია მხოლოდ ნაწილობრივ არის დანერგილი (მაგალითად, არ არის მხარდაჭერილი მორგებული მონაცემთა ტიპებისთვის, რომლის გარეშეც თქვენ ვერ შეძლებთ გამოიყენოთ Decimal - მონაცემთა ახალი ტიპი, რომელიც დანერგილია Tarantool 2.3-ში) და აქვს სხვათა რაოდენობა პრობლემები (PHP 7.4-თან თავსებადობის საკითხების ჩათვლით). ზოგადად, პროექტი მიტოვებულად გამოიყურება.

მოდით გავზომოთ კონექტორების მუშაობა სინქრონულ რეჟიმში:

როგორც გრაფიკიდან ჩანს, PECL კონექტორი (Tarantool) აჩვენებს უკეთეს შესრულებას PHP კონექტორთან (კლიენტთან) შედარებით. მაგრამ ეს გასაკვირი არ არის, თუ გავითვალისწინებთ, რომ ეს უკანასკნელი, გარდა იმისა, რომ განხორციელდება უფრო ნელ ენაზე, რეალურად უფრო მეტ სამუშაოს ასრულებს: ყოველი გამოძახებით იქმნება ახალი ობიექტი. მოითხოვეთ и რეაგირების (არჩევის შემთხვევაში - ასევე კრიტერიუმებიდა განახლების/განახლების შემთხვევაში - ოპერაციების), ცალკეული ერთეულები კავშირი, Packer и Handler ისინი ასევე ამატებენ ზედნადებს. ცხადია, მოქნილობას ფასი აქვს. თუმცა, ზოგადად, PHP თარჯიმანი აჩვენებს კარგ შესრულებას, თუმცა არის განსხვავება, ის უმნიშვნელოა და, შესაძლოა, კიდევ უფრო ნაკლები იყოს PHP 7.4-ში წინასწარ ჩატვირთვისას, რომ აღარაფერი ვთქვათ JIT PHP 8-ში.

მოდით გადავიდეთ. Tarantool 2.0-მა შემოიღო SQL მხარდაჭერა. შევეცადოთ შევასრულოთ Select, Insert, Update და Delete ოპერაციები SQL პროტოკოლის გამოყენებით და შევადაროთ შედეგები noSQL (ორობითი) ეკვივალენტებს:

SQL შედეგები არც თუ ისე შთამბეჭდავია (შეგახსენებთ, რომ ჩვენ ჯერ კიდევ სინქრონულ რეჟიმს ვამოწმებთ). თუმცა, ამაზე წინასწარ არ ვნერვიულობ; SQL მხარდაჭერა ჯერ კიდევ აქტიური განვითარების პროცესშია (შედარებით ცოტა ხნის წინ, მაგალითად, მხარდაჭერა დაემატა მომზადებული განცხადებები) და სიით თუ ვიმსჯელებთ საკითხებიSQL ძრავა მომავალში გაივლის რიგ ოპტიმიზაციას.

ასინკი

კარგად, ახლა ვნახოთ, როგორ დაგვეხმარება Async გაფართოება ზემოთ მოყვანილი შედეგების გაუმჯობესებაში. ასინქრონული პროგრამების დასაწერად, გაფართოება უზრუნველყოფს API-ს, რომელიც დაფუძნებულია კორუტინებზე, რომელსაც ჩვენ გამოვიყენებთ. ჩვენ ემპირიულად ვხვდებით, რომ ჩვენი გარემოსთვის კორუტინის ოპტიმალური რაოდენობაა 25:

„გაავრცელეთ“ 10,000 ოპერაცია 25 კორუტინაში და ნახეთ, რა მოხდება:

ოპერაციების რაოდენობა წამში 3-ჯერ გაიზარდა tarantool-php/კლიენტი!

სამწუხაროდ, PECL კონექტორი არ დაიწყო ext-async-ით.

რაც შეეხება SQL-ს?

როგორც ხედავთ, ასინქრონულ რეჟიმში განსხვავება ბინარულ პროტოკოლსა და SQL-ს შორის შეცდომის ზღვარზე იყო.

სვული

კვლავ ვიგებთ კორუტინების ოპტიმალურ რაოდენობას, ამჯერად სვულისთვის:

მოდით გავჩერდეთ 25-ზე. გავიმეოროთ იგივე ხრიკი, როგორც Async გაფართოებით - გაანაწილეთ 10,000 ოპერაცია 25 კორუტინს შორის. გარდა ამისა, დავამატებთ კიდევ ერთ ტესტს, რომელშიც ყველა სამუშაოს დავყოფთ 2 ორ პროცესად (ანუ თითოეული პროცესი 5,000 კორუტინაში 25 ოპერაციას შეასრულებს). პროცესები შეიქმნება გამოყენებით SwooleProcess.

შედეგები:

Swole აჩვენებს ოდნავ დაბალ შედეგს Async-თან შედარებით, როდესაც გაშვებულია ერთ პროცესში, მაგრამ 2 პროცესით სურათი მკვეთრად იცვლება (ნომერი 2 შემთხვევით არ აირჩია; ჩემს აპარატზე ეს იყო 2 პროცესი, რომელმაც აჩვენა საუკეთესო შედეგი).

სხვათა შორის, Async გაფართოებას ასევე აქვს API პროცესებთან მუშაობისთვის, მაგრამ იქ მე ვერ შევამჩნიე განსხვავება ბენჩმარკების გაშვებისგან ერთ ან მეტ პროცესებში (შესაძლებელია სადმე გავშალოდი).

SQL ორობითი პროტოკოლის წინააღმდეგ:

როგორც Async-ის შემთხვევაში, განსხვავება ბინარულ და SQL ოპერაციებს შორის აღმოიფხვრება ასინქრონულ რეჟიმში.

პარალელურად

ვინაიდან პარალელური გაფართოება ეხება არა კორუტინებს, არამედ ძაფებს, მოდით გავზომოთ პარალელური ძაფების ოპტიმალური რაოდენობა:

ჩემს აპარატზე უდრის 16-ს. მოდით გავუშვათ კონექტორის ეტალონები 16 პარალელურ ძაფზე:

როგორც ხედავთ, შედეგი კიდევ უკეთესია, ვიდრე ასინქრონული გაფართოებებით (არ ჩავთვლით Swoole-ს, რომელიც მუშაობს 2 პროცესზე). გაითვალისწინეთ, რომ PECL კონექტორისთვის, Update და Upsert ოპერაციები ცარიელია. ეს გამოწვეულია იმით, რომ ეს ოპერაციები შეცდომით ჩაიშალა - არ ვიცი, ეს იყო ext-parallel-ის, ext-tarantool-ის თუ ორივეს ბრალი.

ახლა შევადაროთ SQL შესრულება:

შეამჩნიეთ მსგავსება გრაფიკთან სინქრონულად გაშვებული კონექტორებისთვის?

ერთად

და ბოლოს, მოდით შევაჯამოთ ყველა შედეგი ერთ გრაფიკში, რომ ნახოთ ტესტირებადი გაფართოებების საერთო სურათი. მოდით დავამატოთ ჩარტში მხოლოდ ერთი ახალი ტესტი, რომელიც ჯერ არ გაგვიკეთებია - პარალელურად გავუშვათ Async კორუტინები Parallel*-ის გამოყენებით. ზემოაღნიშნული გაფართოებების ინტეგრირების იდეა უკვე არსებობს განიხილეს ავტორები, მაგრამ კონსენსუსი არ იქნა მიღწეული, თქვენ თვითონ მოგიწევთ ამის გაკეთება.

* შეუძლებელი იყო Swoole coroutine-ების გაშვება Parallel-ით; როგორც ჩანს, ეს გაფართოებები შეუთავსებელია.

ასე რომ, საბოლოო შედეგები:

იმის ნაცვლად, რომ დასკვნა

ჩემი აზრით, შედეგები საკმაოდ ღირსეული აღმოჩნდა და რატომღაც დარწმუნებული ვარ, რომ ეს არ არის ზღვარი! გჭირდებათ თუ არა ამის გადაწყვეტა რეალურ პროექტში მხოლოდ საკუთარი თავისთვის, მე მხოლოდ ვიტყვი, რომ ჩემთვის ეს იყო საინტერესო ექსპერიმენტი, რომელიც საშუალებას გაძლევთ შეაფასოთ, თუ რამდენად შეგიძლიათ "გამოწუროთ" სინქრონული TCP კონექტორიდან მინიმალური ძალისხმევით. თუ თქვენ გაქვთ იდეები საორიენტაციო ნიშნების გასაუმჯობესებლად, სიამოვნებით განვიხილავ თქვენს მოთხოვნას. ყველა კოდი გაშვების ინსტრუქციებითა და შედეგებით გამოქვეყნებულია ცალკე საცავები.

წყარო: www.habr.com