ну или есть у вас в системе Observer, вам скармливают объект-слушающий, а у вас стандартизирован вызов:
Observer::add = public function(ObserverClient $obj);
Да, в такой системе без использования интерфейсов все размывается и разваливается. Особенно если классов ObserverClient очень много.
Ну здесь справедливости ради хочется отметить, что есть еще такие «гуру» перла, которые в одной строчке пишут мегаконструкцию, а-ля «смотрите ламеры и учитесь, слабо такое завернуть», что сразу хочется отведать пионерской PHP-шной лапши.
Спасибо, суть я кажется уловил. Проблема в том что воркер «поперхнется» запросом на обработку встроенного перла и вся очередь встает, то есть нужно вешать больше воркеров, чтобы очереди были короче.
Отличие от запроса на бекенд здесь в том, что воркер умеет «распараллеливать» такие вещи, а обработку встроенного перла — нет.
В любом случае стандарт де-факто — только латиница в именах файлов.
Как вариант попробуйте скопировать файл с русским названием в родную ФС и поиграть его, будете хотя бы знать, куда рыть…
Тогда вообще мистика.
Но выход все равно один: жать хостера.
Напишите простой скрипт в одном файле который будет просто коннектиться к базе и писать удалось / не удалось. (Возможно кстати после этого придет просветление). Если этот скрипт не работает — смело начинайте жестко наезжать на хостера с требованием разобраться.
Я уже думал, что окончательно просветлился, но сейчас понимаю, что я реально в танке.
Выходит, то что я написал выше про фронтенд-бекенд — это несущественная фигня по сравнению с этим?
Что значит «масштабируемость от числа воркеров», можно чуть подробнее?
И чем отличается выполнение «в самом себе» перла от отдачи картинки или запроса на бекенд?
На виртуальном хостинге есть такая веселуха, называется оверселлинг. Это еще покруче, чем фаза луны.
В общем думаю надо хостера жать, пусть их админы разберутся.
«Исходя из анализа текущей архитектуры и реализации приложения и перспектив дальнейшего его развития и масштабирования, было принято решение тыц тыц тыц...»
>> Access denied for user 'dbuser'@'localhost' (using password: YES)
Это не похоже на сообщение майскуэльного апи, это сообщение сервера mysql. Когда наступает затык — пробуйте подключиться клиентом mysql, если там точно также — щемите хостера до упора, это 100% их проблемы
пидорасамизаконов и «золотой эрой Linux`а»И Linux сюда впутывать уж точно не стоит.
Думаю, сегодня виртуальный хостинг — это уж совсем если в никсах не рубишь…
Да, в такой системе без использования интерфейсов все размывается и разваливается. Особенно если классов ObserverClient очень много.
Но есть нюансы, например A implements B — при использовании xcache B все равно будет подгружен через __autoload()
Хотя на самом деле на этапе выполнения опкода виртуальной машиной интерфейсы уже не нужны.
Отличие от запроса на бекенд здесь в том, что воркер умеет «распараллеливать» такие вещи, а обработку встроенного перла — нет.
Я правильно понимаю?
Как вариант попробуйте скопировать файл с русским названием в родную ФС и поиграть его, будете хотя бы знать, куда рыть…
Но выход все равно один: жать хостера.
Напишите простой скрипт в одном файле который будет просто коннектиться к базе и писать удалось / не удалось. (Возможно кстати после этого придет просветление). Если этот скрипт не работает — смело начинайте жестко наезжать на хостера с требованием разобраться.
Я уже думал, что окончательно просветлился, но сейчас понимаю, что я реально в танке.
Выходит, то что я написал выше про фронтенд-бекенд — это несущественная фигня по сравнению с этим?
Что значит «масштабируемость от числа воркеров», можно чуть подробнее?
И чем отличается выполнение «в самом себе» перла от отдачи картинки или запроса на бекенд?
В общем думаю надо хостера жать, пусть их админы разберутся.
«Исходя из анализа текущей архитектуры и реализации приложения и перспектив дальнейшего его развития и масштабирования, было принято решение тыц тыц тыц...»
Суть одна, но жопа прикрыта :-D
Это не похоже на сообщение майскуэльного апи, это сообщение сервера mysql. Когда наступает затык — пробуйте подключиться клиентом mysql, если там точно также — щемите хостера до упора, это 100% их проблемы