Медленная обработка запросов к демону bitcoin. П

[vadim24816]

Есть 2 сервера.
1ый с веб-приложением на php 5.3, apache 2.2.23, linux 2.6.32, MySQL 5.1, для работы с bitcoin используется библиотека https://github.com/mikegogulski/bitcoin-php, она работает с помощью cURL.
2ой с демоном bitcoin.
1ый посылает запросы ко 2му, если нужно
а) проверить соединение с bitcoind (проверяется раз в 15 секунд)
б) проверить был ли совершен входящий платеж для указанного биткоин-аккаунта. (так же кажды 15 секунд)
Проблемы начинаются, когда подключается несколько пользователей. Демон bitcoin сначала долго возвращает ответ, а потом просто перестает отвечать на запросы.
Проверки а) и б) инициируются на стороне клиента, и сейчас при 10-15 пользователях получается, что если они просто открывают сайт, то количесвто Entry Processes достигает 5-6, а если начинаются какие-то еще действия, то происходит превышение лимита  Entry Processes (лимит 25), т.е. как я понимаю, одновременно запущено 25 скриптов на обработку. Причем если закомментить запросы к биткоину, превышения лимита не происходит.
Насколько я выяснил (при помощи xdebug и WinCacheGrind), проблема в медленной обработке php-скриптов, выполняющих запросы к bitcoind, причем именно в php::exec_curl, она занимает по 500ms времени на запрос.

Вопросы:
1. Нормально ли, что запросы к bitcoind занимают столько времени, можно ли это время уменьшить?
2. Как можно снизить число Entry Processes?
3. Есть ли варианты проверки поступления входящих платежей без периодических запросов к демону? Желательно без сторонних сервисов.
Буду рад любой помощи. Идеально было бы найти наименее трудозатратное решение, короче вариант "Все переделать!" не принимается  

[1715587581]

1715587581

[rPman]

Скорее всего bitcoin тут не причем, проблема в библиотеке curl и хостерах openvz (я такое словил на firstvds), объяснить не могу, это какая то комбинация условий на хост системе, решение - обновить curl (или даунгрейд, я тогда так и не смог полностью выявить закономерности), еще решение - сменить curl на что-нибудь иное (вроде есть немало библиотек попроще на сокетах php). У меня тогда проблема решилась заменой вызовов библиотеки php_curl на запуск бинарника exec ('curl...'), решение было хоть кривое, но нужно было быстро решать.

p.s. обращаешься к bitcoin на любой вызов со страницы сайта? глупо, по возможности лучше кешировать запросы, хотя бы на диск.

[vadim24816]

Скорее всего bitcoin тут не причем, проблема в библиотеке curl и хостерах openvz (я такое словил на firstvds), объяснить не могу, это какая то комбинация условий на хост системе, решение - обновить curl (или даунгрейд, я тогда так и не смог полностью выявить закономерности), еще решение - сменить curl на что-нибудь иное (вроде есть немало библиотек попроще на сокетах php). У меня тогда проблема решилась заменой вызовов библиотеки php_curl на запуск бинарника exec ('curl...'), решение было хоть кривое, но нужно было быстро решать.

p.s. обращаешься к bitcoin на любой вызов со страницы сайта? глупо, по возможности лучше кешировать запросы, хотя бы на диск.

Спасибо. Я как-раз на curl и думал
С кешированием не понятно, например проверку соединения с биткоин я в бд кеширую(уже выяснил, что в файл быстрее), т.к. один результат можно отдавать всем пользователям. Но для проверки платежей кеширование не подойдет, нужен запрос к биткоину.

[rPman]

Кеширование запросов bitcoin, если речь идет о получении информации, оправдана, так как любая такая информация в сети bitcoin может запаздывать, так что нет смысла чаще чем раз в несколько секунд проверять, например, наличие новых входящих транзакций (все равно кстати их принимать нужно после получения подтверждений, а их получить можно в реальном времени по другому).

Кешировать так - при получении запроса сравниваем время данных в кеше и текущее, если больше интервала между кешированием - делаем запрос к bitcoin и сохраняем в кеше (внимание, код нужно делать потокобезопасным, и в случае гонок, когда в момент, когда данные из кеша устарели, если будет одновременно несколько запросов, они все будут посланы к bitcoin, это нужно как то отследить, либо ограничить блокировками).

p.s. транзакция получает подтрвеждение после нахождения сетью очередного блока, у клиента bitcoind есть замечательная опция:

Code:

  -blocknotify=<cmd>     Execute command when the best block changes (%s in cmd is replaced by block hash)

[vadim24816]

Нашел на форуме:

Code:

 -blocknotify=/path/to/your/script.sh 

Т.е. можно запускать шелл-скрипт, который будет запускать cURL, отправлять запрос на нужный урл, где уже можно запускать какую-то проверку на входящий платеж? Получается что-то вроде события на входящий блок.

Можно ли так получать платежи с неподтвержденных транзакций? Или есть более простые решения?
В моем случае: Входящие - без подтверждения, исходящие - 2 подтверждения, вроде достаточно надежно.

[rPman]

Не понимаю проблемы и вопроса. Да, достаточно прописать в приложении в этом ключе запрос к транзакциям и возможно их обработчик, с сохранением обработанной информации в базе/кеше. А запросы веб сайта лезут не к bitcoind, а к этой закешированной информации.

p.s. Получить список неподтвержденных транзакций, штатным клиентом, только периодическими запросами или сторонними скриптами. Но доверять таким транзакциям не рекомендуется (тот же metabank.ru на заре своего старта попадал на мошенников, обрабатывая обмен без подтверждений сетью), хотя конечно показывать что присланная транзакция принята сервисом и ожидает подтверждения - хороший тон.

[vadim24816]

Спасибо, теперь вроде понятнее.
Проблема по сути в том, как узнать о неподтвержденной входящей транзакции. Я сейчас это делаю через опрос биткоина, но т.к. выяснилось, что curl отрабатывает медленно, пара десятком пользователей просто повесят сайт постоянными проверками.

[invader]

Самое простое решение чтобы оставить все как есть и чтобы клиенты не повесили сайт (да и зачем им позволять вообще как-то взаимодействовать с койноклиентом напрямую?) нужно просто кэшировать данные и обновлять их с некоторой периодичностью (раз в 10..30 сек.). А страница уже должна брать нужные данные из кэша и пусть обновляют сколько им влезет.