rtyug, ты замучал. ubr_upload это такой скрипт. там не может быть ошибок. ошибки могут быть в конфигурации сервера или этого скрипта.
alalat, если по-вебмастерски наугад не получается, значит пришло время профилировать, как это делают программисты.
вообще, обычно на VPS проблемы заключаются в нагрузке на диск от соседей.
webor1on, ну а куда еще подробнее?
домен ты не показал. вот я и предположил одну из причин.
здесь подробнее http://www.zytrax.com/books/dns/
netwind добавил 25.02.2011 в 22:49
webor1on, посмотрел. все серверы живы
firebug действительно показывает dns-запросы, но запросы не делает.
Мне кажется, firebug врет. Я не ощущаю проблем при загрузке странички.
На всякий случай попробуй увеличивать TTL до 3600, а то там время жизни записи 360 секунд.
если некоторые ( один из двух) серверов не работает, то такое возможно
а че тогда у фронтенда имя внутри совпадает с бекендом напичканым всеми обычными модулями ?
Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8e-fips-rhel5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 PHP/4.4.9 Server at usdns1.topwn.com Port 80
берешь какой-нибудь древний дырявый скрипт, ставишь на сайт, регистрируешь в поисковиках и ждешь.
через некоторое время тебе бесплатно закачают самую лучшую последнюю версию web-ssh в виде phpshell-а.
если не хочешь ждать, погугли "php shell" и закачай сам.
А как посмотреть какую-нибудь "карту" на одной странице?
иногда возникают досадные ошибки из-за того что не отключил где-нибудь старый баннер. Протыкивать все зоны всех сайтов слишком муторно.
Была бы карта по всем сайтам, всем зонам и вероятностями, было бы проще контролировать.
alex_lego, с помощью волшебной силы программирования.
Ну если прокси не нравится, можно можно создать таблицы типа federated и писать аккаунтинг на удаленный сервер не меняя ничего в софте. Пожалуй, это самое простое решение.
С прокси можно соорудить еще и надежный аккаунтинг с резервными серверами.
График - в смысле расписания. Я имел ввиду, что при анлиме заранее известно время когда пользователя нужно выключить. А значит не нужны оперативные расчеты.
Вообще интересно, каким образом логика этого биллинга работает? Считаются ли оставшиеся лимиты на байты и время ?
А что бывает, когда пользователь в последние минуты расчетного периода докладывает деньги, доступ прекращается ?
pipelined functions в mysql нет. Сложную логику не закодировать.
Репликация в случае с NDB вообще не нужна. Все нормально там с синхронизацией и устойчивостью. Оно специально проектировалось для отказоустойчивости. Корни NDB как раз растут из какого-то продукта для телекома.
Часто при переносе приложений на NDB возникает куча проблем, но для этой задачи NDB должно подойти. Поэтому статистику лучше выгружать в обычный mysql и там анализировать.
Ну и помимо прочего, остается вариант с mysql-proxy, который запросы на авторизацию обрабатывал бы на локальном, а аккаунтинг исполнял бы на другом сервере.
