А сами Авалоны кто-нибудь вживую видел, они вообще существуют? Оплату то принять им ничего не мешает

Поддерживаю вопрос.
Какие гарантии?

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

 

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

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

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

There are 2 servers.
The first one has web-app on php 5.3, apache 2.2.23, linux 2.6.32, MySQL 5.1, it use for work with bitcoind the php library https://github.com/mikegogulski/bitcoin-php, it works with cURL.
The second one has bitcoind.
First makes requests to second when
a) need check connection to bitcoin (1 time per 15 second)
b) need check for incoming payments for given bitcoin account. (1 time per 15 second)
The problems start when many users open the site. The first server start make responses (on requests to bitcoind) slower and then it takes about 5-10 second, so it's not good.
a) and b) checkings are initiated by clients browser, now when 10-15 users open the site, amount of Entry Processes becomes 5-6, and when they start to do something, it is Entry Processes overlimit. Now the limit is 25.
So I suppose, there are 25 simultaneously php sripts is processing. There is no Entry Processes overlimit if I commented requests to bitcoin on client side.
I had found out from debug it with xdebug and WinCacheGrind, that the problem in slow php script processing which make requests to bitcoind, exactly in php::exec_curl, it takes about 500ms per request.

My questions:
1. Is it good that request to bitcoin take so much time and how could I make it faster?
2. How can I decrease the Entry Processes amount?
3. How can I check incoming payments without repeating requests to bitcoind? Preferably without 3rd party services.
Appreciate any help.

Есть 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. Есть ли варианты проверки поступления входящих платежей без периодических запросов к демону? Желательно без сторонних сервисов.
Буду рад любой помощи. Идеально было бы найти наименее трудозатратное решение, короче вариант "Все переделать!" не принимается