ການເລັ່ງຕົວເຊື່ອມຕໍ່ PHP ສໍາລັບ Tarantool ໂດຍໃຊ້ Async, Swoole ແລະຂະຫນານ

ໃນລະບົບນິເວດ PHP ໃນປັດຈຸບັນມີສອງຕົວເຊື່ອມຕໍ່ສໍາລັບການເຮັດວຽກກັບເຄື່ອງແມ່ຂ່າຍຂອງ Tarantool - ນີ້ແມ່ນການຂະຫຍາຍ PECL ຢ່າງເປັນທາງການ tarantool/tarantool-php, ຂຽນໃນ C, ແລະ tarantool-php/ລູກຄ້າ, ຂຽນໃນ PHP. ຂ້ອຍເປັນຜູ້ຂຽນຂອງຍຸກສຸດທ້າຍ.

ໃນບົດຄວາມນີ້, ຂ້າພະເຈົ້າຢາກແບ່ງປັນຜົນໄດ້ຮັບຂອງການທົດສອບການປະຕິບັດຂອງຫ້ອງສະຫມຸດທັງສອງແລະສະແດງໃຫ້ເຫັນວິທີການ, ມີການປ່ຽນແປງຫນ້ອຍສຸດຂອງລະຫັດ, ທ່ານສາມາດບັນລຸ 3-5 ປະສິດທິພາບເພີ່ມຂຶ້ນ (ໃນ​ການ​ທົດ​ສອບ​ສັງ​ເຄາະ​!).

ພວກເຮົາຈະທົດສອບຫຍັງ?

ພວກເຮົາຈະທົດສອບສິ່ງທີ່ກ່າວມາຂ້າງເທິງ synchronous ຕົວເຊື່ອມຕໍ່ທີ່ເຮັດວຽກແບບບໍ່ຊິ້ງໂຄນ, ຂະໜານ, ແລະຂະໜານແບບບໍ່ກົງກັນ. 🙂 ພວກເຮົາຍັງບໍ່ຕ້ອງການແຕະລະຫັດຂອງຕົວເຊື່ອມຕໍ່ເອງ. ໃນປັດຈຸບັນມີຫຼາຍສ່ວນຂະຫຍາຍທີ່ມີຢູ່ເພື່ອບັນລຸສິ່ງທີ່ທ່ານຕ້ອງການ:

• ບວມ - ກອບ asynchronous ປະສິດທິພາບສູງສໍາລັບ PHP. ໃຊ້ໂດຍຍັກໃຫຍ່ອິນເຕີເນັດເຊັ່ນ Alibaba ແລະ Baidu. ຕັ້ງ​ແຕ່​ສະ​ບັບ 4.1.0 ວິ​ທີ​ການ magic ໄດ້​ປາ​ກົດ​ຂຶ້ນ​ SwooleRuntime::enableCoroutine(), ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດ "ປ່ຽນຫ້ອງສະຫມຸດເຄືອຂ່າຍ PHP synchronous ກັບ asynchronous ທີ່ມີລະຫັດຫນຶ່ງແຖວ."
• Async ແມ່ນຈົນກ່ວາບໍ່ດົນມານີ້ເປັນການຂະຫຍາຍທີ່ດີຫຼາຍສໍາລັບການເຮັດວຽກ asynchronous ໃນ PHP. ເປັນຫຍັງຈົນກ່ວາບໍ່ດົນມານີ້? ແຕ່ຫນ້າເສຍດາຍ, ສໍາລັບເຫດຜົນທີ່ຂ້ອຍບໍ່ຮູ້, ຜູ້ຂຽນໄດ້ລຶບ repository ແລະຊະຕາກໍາໃນອະນາຄົດຂອງໂຄງການແມ່ນບໍ່ຈະແຈ້ງ. ຂ້ອຍຈະຕ້ອງໃຊ້ມັນ ໂດຍຫນຶ່ງ ຈາກສ້ອມ. ເຊັ່ນດຽວກັນກັບ Swoole, ການຂະຫຍາຍນີ້ຊ່ວຍໃຫ້ທ່ານສາມາດເປີດກາງເກງຂອງທ່ານໄດ້ຢ່າງງ່າຍດາຍດ້ວຍການ flick ຂອງ wrist ເພື່ອເຮັດໃຫ້ asynchrony ໂດຍການທົດແທນການປະຕິບັດມາດຕະຖານຂອງ TCP ແລະ TLS streams ກັບສະບັບ asynchronous ຂອງເຂົາເຈົ້າ. ນີ້ແມ່ນເຮັດໄດ້ໂດຍຜ່ານທາງເລືອກ "async.tcp = 1"
• ຂະຫນານ - ເປັນສ່ວນຂະຫຍາຍທີ່ຂ້ອນຂ້າງໃຫມ່ຈາກ Joe Watkins ທີ່ມີຊື່ສຽງ, ຜູ້ຂຽນຂອງຫ້ອງສະຫມຸດເຊັ່ນ phpdbg, apcu, pthreads, pcov, uopz. ການຂະຫຍາຍສະຫນອງ API ສໍາລັບການ multithreading ໃນ PHP ແລະຖືກຈັດຕໍາແຫນ່ງເປັນການທົດແທນສໍາລັບ pthreads. ຂໍ້ຈໍາກັດທີ່ສໍາຄັນຂອງຫ້ອງສະຫມຸດແມ່ນວ່າມັນພຽງແຕ່ເຮັດວຽກກັບ ZTS (Zend Thread Safe) ສະບັບຂອງ PHP.

ພວກເຮົາຈະທົດສອບແນວໃດ?

ໃຫ້ເປີດຕົວຢ່າງ Tarantool ດ້ວຍການປິດບັນທຶກການຂຽນລ່ວງໜ້າ (wal_mode = ບໍ່ມີ) ແລະ​ການ​ເພີ່ມ​ຂຶ້ນ​ຂອງ​ເຄືອ​ຂ່າຍ buffer (readahead = 1 * 1024 * 1024). ທາງເລືອກທໍາອິດຈະລົບລ້າງການເຮັດວຽກກັບແຜ່ນ, ທີສອງຈະເຮັດໃຫ້ສາມາດອ່ານຄໍາຮ້ອງຂໍເພີ່ມເຕີມຈາກ buffer ລະບົບປະຕິບັດການແລະດັ່ງນັ້ນຈຶ່ງຫຼຸດຜ່ອນຈໍານວນການໂທຂອງລະບົບ.

ສໍາລັບ benchmarks ທີ່ເຮັດວຽກກັບຂໍ້ມູນ (ການແຊກ, ການລຶບ, ການອ່ານ, ແລະອື່ນໆ), ກ່ອນທີ່ຈະເລີ່ມຕົ້ນ benchmark, ຊ່ອງ 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}})

ຖ້າຈໍາເປັນ, ກ່ອນທີ່ຈະດໍາເນີນການ benchmark, ຊ່ອງແມ່ນເຕັມໄປດ້ວຍ 10,000 tuples ຂອງແບບຟອມ.

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

Tuples ແມ່ນເຂົ້າເຖິງໂດຍໃຊ້ຄ່າລະຫັດສຸ່ມ.

benchmark ຕົວຂອງມັນເອງແມ່ນຄໍາຮ້ອງຂໍດຽວກັບເຄື່ອງແມ່ຂ່າຍ, ເຊິ່ງຖືກປະຕິບັດ 10,000 ເທື່ອ (ການປະຕິວັດ), ເຊິ່ງ, ໃນທາງກັບກັນ, ຖືກປະຕິບັດໃນ iterations. ການຊໍ້າຄືນຈະຖືກເຮັດຊ້ຳຈົນກ່ວາການບ່ຽງເບນຂອງເວລາທັງໝົດລະຫວ່າງ 5 ການຊໍ້າຄືນແມ່ນຢູ່ໃນຄວາມຜິດພາດທີ່ຍອມຮັບໄດ້ຂອງ 3%*. ຫຼັງຈາກນີ້, ຜົນໄດ້ຮັບສະເລ່ຍແມ່ນປະຕິບັດ. ມີການຢຸດຊົ່ວຄາວ 1 ວິນາທີລະຫວ່າງການຊໍ້າຄືນເພື່ອປ້ອງກັນບໍ່ໃຫ້ໂປຣເຊດເຊີຈາກການປິດລ້ອມ. ຜູ້ເກັບຂີ້ເຫຍື້ອຂອງ Lua ແມ່ນພິການກ່ອນທີ່ຈະເຮັດຊ້ໍາອີກຄັ້ງແລະຖືກບັງຄັບໃຫ້ເລີ່ມຕົ້ນຫຼັງຈາກມັນສໍາເລັດ. ຂະບວນການ PHP ຖືກເປີດຕົວພຽງແຕ່ມີສ່ວນຂະຫຍາຍທີ່ຈໍາເປັນສໍາລັບ benchmark, ດ້ວຍການປິດການໂຫຼດຜົນຜະລິດແລະເຄື່ອງເກັບຂີ້ເຫຍື້ອຖືກປິດ.

* ຈໍາ​ນວນ​ຂອງ​ການ​ປະ​ຕິ​ວັດ​, iterations ແລະ​ລະ​ດັບ​ຄວາມ​ຜິດ​ພາດ​ສາ​ມາດ​ໄດ້​ຮັບ​ການ​ປ່ຽນ​ແປງ​ໃນ​ການ​ຕັ້ງ​ຄ່າ​ມາດ​ຕະ​ຖານ​.

ສະພາບແວດລ້ອມການທົດສອບ

ຜົນໄດ້ຮັບທີ່ຈັດພີມມາຂ້າງລຸ່ມນີ້ແມ່ນເຮັດຢູ່ໃນ MacBookPro (2015), ລະບົບປະຕິບັດການ - Fedora 30 (kernel version 5.3.8-200.fc30.x86_64). Tarantool ຖືກເປີດຕົວໃນ docker ກັບພາລາມິເຕີ "--network host".

ລຸ້ນແພັກເກດ:

Tarantool: 2.3.0-115-g5ba5ed37e
Docker: 19.03.3, build a872fc2f86
PHP: 7.3.11 (cli) (ສ້າງ: ຕຸລາ 22 2019 08:11:04)
tarantool/ລູກຄ້າ: 0.6.0
rybakit/msgpack: 0.6.1
ext-tarantool: 0.3.2 (+ patch ສໍາລັບ 7.3)*
ext-msgpack: 2.0.3
ext-async: 0.3.0-8c1da46
ext-swoole: 4.4.12
ext-parallel: 1.1.3

* ແຕ່ຫນ້າເສຍດາຍ, ຕົວເຊື່ອມຕໍ່ຢ່າງເປັນທາງການບໍ່ເຮັດວຽກກັບ PHP ຮຸ່ນ> 7.2. ເພື່ອລວບລວມແລະດໍາເນີນການຂະຫຍາຍຢູ່ໃນ PHP 7.3, ຂ້ອຍຕ້ອງໃຊ້ ເພີ້ມ.

Результаты

ໂໝດ synchronous

ໂປໂຕຄອນ Tarantool ໃຊ້ຮູບແບບຖານສອງ MessagePack ເພື່ອ serialize ຂໍ້ຄວາມ. ໃນຕົວເຊື່ອມຕໍ່ PECL, serialization ຖືກເຊື່ອງໄວ້ໃນຄວາມເລິກຂອງຫ້ອງສະຫມຸດແລະຜົນກະທົບຕໍ່ຂະບວນການເຂົ້າລະຫັດຈາກລະຫັດ userland. ເບິ່ງຄືວ່າເປັນໄປບໍ່ໄດ້. ຕົວເຊື່ອມຕໍ່ PHP ບໍລິສຸດ, ໃນທາງກົງກັນຂ້າມ, ສະຫນອງຄວາມສາມາດໃນການປັບແຕ່ງຂະບວນການເຂົ້າລະຫັດໂດຍການຂະຫຍາຍຕົວເຂົ້າລະຫັດມາດຕະຖານຫຼືໂດຍການນໍາໃຊ້ການປະຕິບັດຂອງທ່ານເອງ. ມີສອງຕົວເຂົ້າລະຫັດທີ່ມີຢູ່ອອກຈາກກ່ອງ, ຫນຶ່ງແມ່ນອີງໃສ່ msgpack/msgpack-php (ສ່ວນຂະຫຍາຍ MessagePack PECL ທີ່ເປັນທາງການ), ອັນອື່ນແມ່ນເປີດຢູ່ rybakit/msgpack (ໃນ PHP ບໍລິສຸດ).

ກ່ອນທີ່ຈະປຽບທຽບຕົວເຊື່ອມຕໍ່, ພວກເຮົາຈະວັດແທກປະສິດທິພາບຂອງຕົວເຂົ້າລະຫັດ MessagePack ສໍາລັບຕົວເຊື່ອມຕໍ່ PHP ແລະໃນການທົດສອບຕໍ່ໄປພວກເຮົາຈະນໍາໃຊ້ຫນຶ່ງທີ່ສະແດງໃຫ້ເຫັນຜົນໄດ້ຮັບທີ່ດີທີ່ສຸດ:

ເຖິງແມ່ນວ່າສະບັບ PHP (Pure) ຕ່ໍາກວ່າການຂະຫຍາຍ PECL ໃນຄວາມໄວ, ໃນໂຄງການຕົວຈິງຂ້າພະເຈົ້າຍັງແນະນໍາໃຫ້ໃຊ້ມັນ. rybakit/msgpack, ເນື່ອງຈາກວ່າໃນນາມສະກຸນ MessagePack ຢ່າງເປັນທາງການ, ການກໍານົດຮູບແບບແມ່ນປະຕິບັດບາງສ່ວນເທົ່ານັ້ນ (ຕົວຢ່າງ, ບໍ່ມີການຮອງຮັບປະເພດຂໍ້ມູນແບບກໍານົດເອງ, ໂດຍບໍ່ມີການທີ່ທ່ານຈະບໍ່ສາມາດໃຊ້ Decimal - ປະເພດຂໍ້ມູນໃຫມ່ທີ່ນໍາສະເຫນີໃນ Tarantool 2.3) ແລະມີ. ຈໍາ​ນວນ​ຂອງ​ຄົນ​ອື່ນ​ ບັນຫາ (ລວມທັງບັນຫາຄວາມເຂົ້າກັນໄດ້ກັບ PHP 7.4). ດີ, ໂດຍທົ່ວໄປ, ໂຄງການເບິ່ງຄືວ່າຖືກປະຖິ້ມໄວ້.

ດັ່ງນັ້ນ, ໃຫ້ວັດແທກປະສິດທິພາບຂອງຕົວເຊື່ອມຕໍ່ໃນຮູບແບບ synchronous:

ດັ່ງທີ່ເຫັນໄດ້ຈາກກາຟ, ຕົວເຊື່ອມຕໍ່ PECL (Tarantool) ສະແດງໃຫ້ເຫັນການປະຕິບັດທີ່ດີກວ່າເມື່ອທຽບກັບຕົວເຊື່ອມຕໍ່ PHP (ລູກຄ້າ). ແຕ່ນີ້ບໍ່ແປກໃຈ, ເພາະວ່າອັນສຸດທ້າຍ, ນອກເຫນືອຈາກການຈັດຕັ້ງປະຕິບັດໃນພາສາທີ່ຊ້າລົງ, ຕົວຈິງແລ້ວຍັງເຮັດວຽກຫຼາຍຂຶ້ນ: ວັດຖຸໃຫມ່ຖືກສ້າງຂື້ນກັບແຕ່ລະການໂທ. ການຮ້ອງຂໍ и ການຕອບສະຫນອງ (ໃນກໍລະນີຂອງ Select - ຍັງ Criteria, ແລະໃນກໍລະນີຂອງການປັບປຸງ / Upsert - ການດໍາເນີນງານ), ຫນ່ວຍງານແຍກຕ່າງຫາກ ການເຊື່ອມຕໍ່, Packer и Handler ພວກເຂົາເຈົ້າຍັງເພີ່ມ overhead. ແນ່ນອນ, ຄວາມຍືດຫຍຸ່ນມາໃນລາຄາ. ຢ່າງໃດກໍ່ຕາມ, ໂດຍທົ່ວໄປແລ້ວ, ນາຍພາສາ PHP ສະແດງໃຫ້ເຫັນເຖິງການປະຕິບັດທີ່ດີ, ເຖິງແມ່ນວ່າມີຄວາມແຕກຕ່າງກັນ, ມັນບໍ່ສໍາຄັນແລະບາງທີອາດມີຫນ້ອຍລົງເມື່ອໃຊ້ preloading ໃນ PHP 7.4, ບໍ່ໄດ້ກ່າວເຖິງ JIT ໃນ PHP 8.

ໃຫ້ກ້າວຕໍ່ໄປ. Tarantool 2.0 ເພີ່ມການສະຫນັບສະຫນູນສໍາລັບ SQL. ໃຫ້ພະຍາຍາມປະຕິບັດ Select, Insert, Update ແລະDelete ໂດຍໃຊ້ໂປຣໂຕຄໍ SQL ແລະປຽບທຽບຜົນໄດ້ຮັບກັບ noSQL (binary) ທຽບເທົ່າ:

ຜົນໄດ້ຮັບ SQL ແມ່ນບໍ່ປະທັບໃຈຫຼາຍ (ໃຫ້ຂ້ອຍເຕືອນເຈົ້າວ່າພວກເຮົາຍັງທົດສອບໂຫມດ synchronous). ຢ່າງໃດກໍຕາມ, ຂ້າພະເຈົ້າຈະບໍ່ຮູ້ສຶກເສຍໃຈກັບເລື່ອງນີ້ກ່ອນເວລາ; ການສະຫນັບສະຫນູນ SQL ຍັງຢູ່ພາຍໃຕ້ການພັດທະນາຢ່າງຫ້າວຫັນ (ຂ້ອນຂ້າງບໍ່ດົນມານີ້, ຕົວຢ່າງ, ການສະຫນັບສະຫນູນໄດ້ຖືກເພີ່ມ. ຖະແຫຼງການທີ່ກະກຽມ) ແລະ, ຕັດສິນໂດຍບັນຊີລາຍຊື່ ບັນຫາ, ເຄື່ອງຈັກ SQL ຈະຜ່ານການເພີ່ມປະສິດທິພາບຈໍານວນຫນຶ່ງໃນອະນາຄົດ.

ບໍ່ກົງກັນ

ແລ້ວ, ຕອນນີ້ໃຫ້ເບິ່ງວິທີການຂະຫຍາຍ Async ສາມາດຊ່ວຍພວກເຮົາປັບປຸງຜົນໄດ້ຮັບຂ້າງເທິງ. ເພື່ອຂຽນໂປຼແກຼມ asynchronous, ສ່ວນຂະຫຍາຍໃຫ້ API ໂດຍອີງໃສ່ coroutines, ເຊິ່ງພວກເຮົາຈະໃຊ້. ພວກເຮົາຄົ້ນພົບວ່າຈໍານວນ coroutines ທີ່ດີທີ່ສຸດສໍາລັບສະພາບແວດລ້ອມຂອງພວກເຮົາແມ່ນ 25:

"ແຜ່" 10,000 ການດໍາເນີນງານໃນທົ່ວ 25 coroutines ແລະເບິ່ງສິ່ງທີ່ເກີດຂຶ້ນ:

ຈໍານວນຂອງການດໍາເນີນງານຕໍ່ວິນາທີເພີ່ມຂຶ້ນຫຼາຍກ່ວາ 3 ເທື່ອສໍາລັບ tarantool-php/ລູກຄ້າ!

ແຕ່ຫນ້າເສຍດາຍ, ຕົວເຊື່ອມຕໍ່ PECL ບໍ່ໄດ້ເລີ່ມຕົ້ນດ້ວຍ ext-async.

SQL ແມ່ນຫຍັງ?

ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໄດ້, ໃນຮູບແບບ asynchronous ຄວາມແຕກຕ່າງລະຫວ່າງ binary protocol ແລະ SQL ໄດ້ກາຍເປັນຢູ່ໃນຂອບຂອງຄວາມຜິດພາດ.

ບວມ

ອີກເທື່ອຫນຶ່ງພວກເຮົາຊອກຫາຈໍານວນທີ່ດີທີ່ສຸດຂອງ coroutines, ເວລານີ້ສໍາລັບ Swoole:

ໃຫ້ຢຸດເຊົາຢູ່ທີ່ 25. ໃຫ້ເຮັດຊ້ໍາອີກ trick ດຽວກັນກັບສ່ວນຂະຫຍາຍ Async - ແຈກຢາຍ 10,000 ການດໍາເນີນງານລະຫວ່າງ 25 coroutines. ນອກຈາກນັ້ນ, ພວກເຮົາຈະເພີ່ມການທົດສອບອີກອັນຫນຶ່ງທີ່ພວກເຮົາຈະແບ່ງວຽກທັງຫມົດອອກເປັນ 2 ສອງຂະບວນການ (ນັ້ນແມ່ນ, ແຕ່ລະຂະບວນການຈະປະຕິບັດ 5,000 ໃນ 25 coroutines). ຂະບວນການຈະຖືກສ້າງຂື້ນໂດຍໃຊ້ ຂະບວນການ Swoole.

ຜົນໄດ້ຮັບ:

Swole ສະແດງໃຫ້ເຫັນຜົນໄດ້ຮັບຕ່ໍາເລັກນ້ອຍເມື່ອທຽບກັບ Async ເມື່ອດໍາເນີນການໃນຫນຶ່ງຂະບວນການ, ແຕ່ມີ 2 ຂະບວນການຮູບພາບມີການປ່ຽນແປງຢ່າງຫຼວງຫຼາຍ (ຈໍານວນ 2 ບໍ່ໄດ້ຖືກເລືອກໂດຍບັງເອີນ; ໃນເຄື່ອງຂອງຂ້ອຍ, ມັນແມ່ນ 2 ຂະບວນການທີ່ສະແດງໃຫ້ເຫັນຜົນໄດ້ຮັບທີ່ດີທີ່ສຸດ).

ໂດຍວິທີທາງການ, ການຂະຫຍາຍ Async ຍັງມີ API ສໍາລັບການເຮັດວຽກກັບຂະບວນການ, ແຕ່ຢູ່ທີ່ນັ້ນຂ້ອຍບໍ່ໄດ້ສັງເກດເຫັນຄວາມແຕກຕ່າງໃດໆຈາກການແລ່ນມາດຕະຖານໃນຂະບວນການຫນຶ່ງຫຼືຫຼາຍ (ມັນເປັນໄປໄດ້ວ່າຂ້ອຍສັບສົນຢູ່ບ່ອນໃດບ່ອນຫນຶ່ງ).

SQL vs binary protocol:

ເຊັ່ນດຽວກັນກັບ Async, ຄວາມແຕກຕ່າງລະຫວ່າງການດໍາເນີນງານ binary ແລະ SQL ຖືກລົບລ້າງໃນຮູບແບບ asynchronous.

ຂະຫນານ

ເນື່ອງຈາກການຂະຫຍາຍຂະຫນານບໍ່ແມ່ນກ່ຽວກັບ coroutines, ແຕ່ກ່ຽວກັບກະທູ້, ໃຫ້ພວກເຮົາວັດແທກຈໍານວນທີ່ດີທີ່ສຸດຂອງກະທູ້ຂະຫນານ:

ມັນເທົ່າກັບ 16 ໃນເຄື່ອງຂອງຂ້ອຍ. ມາໃຊ້ມາດຕະຖານຕົວເຊື່ອມຕໍ່ໃນ 16 ກະທູ້ຂະໜານກັນ:

ດັ່ງທີ່ທ່ານສາມາດເບິ່ງເຫັນໄດ້, ຜົນໄດ້ຮັບແມ່ນດີກ່ວາກັບການຂະຫຍາຍ asynchronous (ບໍ່ນັບ Swoole ແລ່ນຢູ່ໃນ 2 ຂະບວນການ). ໃຫ້ສັງເກດວ່າສໍາລັບຕົວເຊື່ອມຕໍ່ PECL, ການດໍາເນີນງານການປັບປຸງແລະ Upsert ແມ່ນຫວ່າງເປົ່າ. ນີ້ແມ່ນເນື່ອງມາຈາກຄວາມຈິງທີ່ວ່າການປະຕິບັດງານເຫຼົ່ານີ້ລົ້ມເຫລວກັບຄວາມຜິດພາດ - ຂ້ອຍບໍ່ຮູ້ວ່າມັນເປັນຄວາມຜິດຂອງ ext-parallel, ext-tarantool, ຫຼືທັງສອງ.

ຕອນນີ້ໃຫ້ປຽບທຽບການປະຕິບັດ SQL:

ສັງເກດເຫັນຄວາມຄ້າຍຄືກັນກັບກາຟສໍາລັບຕົວເຊື່ອມຕໍ່ທີ່ເຮັດວຽກ synchronously?

ຮ່ວມກັນ

ແລະສຸດທ້າຍ, ໃຫ້ສະຫຼຸບຜົນໄດ້ຮັບທັງຫມົດໃນຫນຶ່ງກາຟເພື່ອເບິ່ງພາບລວມສໍາລັບການຂະຫຍາຍທີ່ທົດສອບ. ໃຫ້ເພີ່ມພຽງແຕ່ຫນຶ່ງການທົດສອບໃຫມ່ໃນຕາຕະລາງ, ເຊິ່ງພວກເຮົາຍັງບໍ່ໄດ້ເຮັດເທື່ອ - ໃຫ້ດໍາເນີນການ Async coroutines ໃນຂະຫນານໂດຍໃຊ້ Parallel *. ແນວຄວາມຄິດຂອງການປະສົມປະສານການຂະຫຍາຍຂ້າງເທິງແມ່ນແລ້ວ ໄດ້ຖືກປຶກສາຫາລື ຜູ້ຂຽນ, ແຕ່ບໍ່ມີການຕົກລົງເຫັນດີ, ທ່ານຈະຕ້ອງເຮັດມັນເອງ.

* ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະເປີດ Swoole coroutines ກັບ Parallel; ມັນເບິ່ງຄືວ່າສ່ວນຂະຫຍາຍເຫຼົ່ານີ້ບໍ່ເຂົ້າກັນໄດ້.

ດັ່ງນັ້ນ, ຜົນໄດ້ຮັບສຸດທ້າຍ:

ແທນທີ່ຈະເປັນການສະຫລຸບໄດ້

ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ຜົນໄດ້ຮັບແມ່ນຂ້ອນຂ້າງສົມຄວນ, ແລະດ້ວຍເຫດຜົນບາງຢ່າງຂ້ອຍແນ່ໃຈວ່ານີ້ບໍ່ແມ່ນຂອບເຂດຈໍາກັດ! ບໍ່ວ່າທ່ານຕ້ອງການຕັດສິນໃຈນີ້ໃນໂຄງການທີ່ແທ້ຈິງສໍາລັບຕົວທ່ານເອງ, ຂ້າພະເຈົ້າພຽງແຕ່ຈະເວົ້າວ່າສໍາລັບຂ້ອຍມັນເປັນການທົດລອງທີ່ຫນ້າສົນໃຈທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດປະເມີນວ່າທ່ານສາມາດ "ບີບ" ອອກຈາກຕົວເຊື່ອມຕໍ່ TCP ທີ່ມີຄວາມພະຍາຍາມຫນ້ອຍທີ່ສຸດ. ຖ້າທ່ານມີແນວຄວາມຄິດສໍາລັບການປັບປຸງດັດຊະນີ, ຂ້ອຍຈະຍິນດີທີ່ຈະພິຈາລະນາຄໍາຮ້ອງຂໍການດຶງຂອງເຈົ້າ. ລະ​ຫັດ​ທັງ​ຫມົດ​ທີ່​ມີ​ຄໍາ​ແນະ​ນໍາ​ການ​ເປີດ​ຕົວ​ແລະ​ຜົນ​ໄດ້​ຮັບ​ແມ່ນ​ໄດ້​ຖືກ​ຈັດ​ພີມ​ມາ​ໃນ​ການ​ແຍກ​ຕ່າງ​ຫາກ​ ຄັງເກັບມ້ຽນ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com