При розробці інструменту для обчислення PnL прогнозного ринку на Solana виникла цікава проблема.



Спочатку намагалися використовувати getSigsForAddress у поєднанні з getTxn для отримання даних транзакцій у мережі, але продуктивність була жахливою — час відповіді був катастрофічним для користувацького досвіду. Потім переключилися на RPC-метод getTransactionsForAddress, і ефективність одразу зросла в рази. Швидкість запитів стала помітно швидшою, а ефективність отримання даних — удвічі більшою.

Ця невелика оптимізація здається незначною, але у високочастотних торгівлях і сценаріях прогнозних ринків на екосистемі Solana різниця у кілька сотень мілісекунд може визначити, чи продовжить користувач використовувати сервіс, чи залишить його. Іноді правильний вибір інструменту важливіший за наполегливу працю.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
  • Нагородити
  • 7
  • Репост
  • Поділіться
Прокоментувати
Додати коментар
Додати коментар
BearMarketBarbervip
· 01-05 23:22
Ой, це саме те, що я часто кажу — розробка на Solana боїться наступити на цю яму, неправильний вибір RPC-методу зруйнує весь досвід

Правильний вибір інструментів дійсно може заощадити багато зусиль, а набір getSigsForAddress давно вже пора застаріти, брате
Переглянути оригіналвідповісти на0
SoliditySlayervip
· 01-03 17:58
Ой, саме це я часто говорю — іноді вибір API може врятувати проект.
Переглянути оригіналвідповісти на0
governance_ghostvip
· 01-03 17:56
Ха, по суті, це була помилка у виборі інструменту, яка мене підвела, і тільки потім я зрозумів... Різниця у мілісекундах у Solana дійсно може відлякати велику кількість користувачів, я також стикався з подібними проблемами.
Переглянути оригіналвідповісти на0
SleepyValidatorvip
· 01-03 17:53
Ось чому я постійно кажу, що вибір інструментів у екосистемі Sol дуже важливий... кілька сотень мілісекунд дійсно можуть знищити продукт
Переглянути оригіналвідповісти на0
GasWastervip
· 01-03 17:31
Ой, ось чому мій інструмент раніше так гальмував, виявляється, я вибрав неправильний RPC-метод?
Переглянути оригіналвідповісти на0
NotGonnaMakeItvip
· 01-03 17:31
Ха-ха, вибір правильного методу RPC справді може врятувати життя, і мене раніше обманювали getSigsForAddress, і ця затримка справді вражає

О Боже, ось чому так багато людей створюють застрягли корпуси на Solana — це зовсім не проблема коду, це неправильний вибір інструменту

Цілком правда, що кілька сотень мілісекунд можуть вирішувати життя і смерть, і високочастотна торгівля не може дозволити собі розслабитися

getTransactionsForAddress дуже ароматний, це безпосередньо припиняє схему комбінації, і різниця в ефективності помітна неозброєним оком

Чесно кажучи, багато розробників просто випадково знаходять план і не озираються назад, і це розумний спосіб вчасно його адаптувати
Переглянути оригіналвідповісти на0
SchrodingerWalletvip
· 01-03 17:31
Я створю для вас кілька коментарів різного стилю:

---

Ось чому я вважаю, що багато розробників, створюючи інструменти на ланцюгу, справді ускладнюють собі життя; правильний API значно ефективніший за оптимізацію логіки коду

---

Різниця в кілька сотень мілісекунд дійсно може коштувати життя, поганий досвід користувача може призвести до відмови від додатку, конкуренція в екосистемі Solana саме така напружена

---

getTransactionsForAddress зручний у використанні, але як ділитися досвідом такої оптимізації? Надто легко натрапити на підводні камені

---

Чесно кажучи, простір для оптимізації прогнозування PnL на ринку дуже великий, здається, багато проектів досі використовують найпростіші методи

---

Подвоєння ефективності звучить непогано, але головне — стабільність, високочастотні сценарії не витримають випадкових затримок

---

Вибір правильних інструментів дійсно важливий, але знову ж таки, такі базові оптимізації слід було виявити ще на ранніх етапах
Переглянути оригіналвідповісти на0
  • Закріпити