не скажу ничего насчет Буркина-Фасо, но германия член NATO, а Австралия — союзник (Major Non-NATO Ally), так что хоть какого-то смысла запрещать им фейсбук в этом контексте нет, потому что они завязаны с США в одном военном блоке.
Выбранная архитектура не завязана на конкретную бд
по-хорошему должен сделать был danog, предоставив интерфейс работы с хранилищем сессий, и дефолтный драйвер а-ля SessionStorageInterface, который бы работал как сейчас, но была бы возможность писать свои драйверы по-человечески.
в конкретно данном случае это должно быть что-то в духе (опять же, если совсем на пальцах)
interface SessionStorageInterface {
public function set($key, $value) : \Amp\Promise;
public function get($key) : \Amp\Promise;
public function has($key) : \Amp\Promise;
}
с дефолтной заглушкой, а-ля
class ArraySessionStorage implements SessionStorageInterface {
private $storage = [];
public function set($key, $value) : \Amp\Promise {
$this->storage[$key] = $value;
return new \Amp\Success();
}
public function get($key) : \Amp\Promise {
if (isset($this->storage[$key])) {
return new \Amp\Success($this->storage[$key]);
}
return new \Amp\Failure();
}
public function has($key) : \Amp\Promise {
return isset($this->storage[$key])
? new \Amp\Success(true);
: new \Amp\Success(false);
}
}
да и вообще сама структура madeline это ужас и боль.
я представляю себе объем работы, который выполнил автор, честь ему и хвала за усидчивость и вложенные силы, но качество проекта очень печальное.
и если стоит вопрос как-то серьезно кастомизировать её под свои нужды, то порой проще будет написать своё.
всё зря было, удаляйте о сколько нам открытий чудных...
Добавить yield перед вызовом методов и функций не очень сложно.
но не все yield одинаково полезны. yield сам по себе никакую магию асинхронности не делает, магию асинхронности делает amp, в котором вызывается функция-генератор.
когда вы пишете
Amp\Loop::run(function () {
yield $promise;
});
внутри функции run происходит примерно следующее (ну если прям совсем на пальцах):
public static function run(callable $callable)
{
$generator = $callable();
if ($generator->valid()) {
$promise = $generator->current();
$promise->onResolve(function ($error, $result) use ($generator) {
if ($error !== null) {
return $generator->throw($error);
}
return $generator->send($result);
});
}
}
то есть за асинхронной функцией на yield должен стоят бекенд, который при yield промиса из этой функции будет дожидаться его и делать send при резолве этого промиса.
это происходит в случае, если вы выбрасываете из генератора промис в
1) контексте генератора, переданного в Loop::run()
2) в контексте генератора, вызванного через call/callAsync
3) в контексте корутины, созданной с помощью coroutine/asyncCoroutine
4) в контексте генератора, переданного в Promise\wait (который под капотом просто вызовет Loop::run())
мало того, вы не можете выбросить с помощью yield что угодно, вы должны выбрасывать инстанс amp или reactphp промиса.
пытаясь, например, сделать
yield unset($storage['index']);
вы выбросите результат выполнения функции unset (а именно null);
и этот код с точки зрения amphp будет эквивалентен
yield null;
на самом деле, учитывая что у вас далеко не самая высокая нагрузка, а доступ к бд осуществляется практически всегда по PK, очень вряд ли вы существенно потеряли бы в производительности, если бы написали просто перегрузку массива на не асинхронном доступе к бд, просто через pdo. а еще лучше — взяли бы что-то более ориентированное на key-value, тот же редис.
вообще madeline, наверное, самое ужасное, что я видел из написанного на php в последние годы, и очень хороший пример, как проект выглядеть не должен. а попытки использования его не as is преврящаются в вот такие костыли, что на самом деле скорее грустно.
Правила дорожного движения говорят где и у кого должен быть приоритет.
И на нерегулируемых пешеходных переходах, согласно ПДД, приоритет у пешеходов.
Но, видимо, водители считают, что не разгонять энтропию гораздо важнее, чем соблюдать никому не нужные правила, от которых не зависят жизни людей.
Не хочу вас расстраивать..., но до этого тоже было так себе.
если в качестве аргумента указан eval строковое обращение к protected методу этого же класса через self.
Потому что не нужно так делать.
<?php
class A {
public static function b() {
echo "Hello World!" . PHP_EOL;
}
public static function callSelf()
{
[self::class, 'b']();
[static::class, 'b']();
}
}
A::callSelf();
[A::class, 'b']();
хороший сайт, быстрый.
а что на нем скорость мерять — он же полупустой :)
ну не в смысле что на нем чего-то не хватает, но это тот объем когда даже фуллскан таблиц практически не играет роли в производительности.
но добавьте пару десятков тысяч статей, тегов и посмотрите как оно будет жить, когда битрикс начнет активно бегать в бд.
я согласен, что у cms и битрикса есть своя ниша и они могут работать хорошо при тонкой настройке, но взгляните на большинство интернета — это грустно и «микрооптимизациями» занимаются крайне мало людей, можно же поставить волшебный плагин для кеша чтоб всё это хотябы не умирало.
ну и плюс php это все-таки не только cms, у меня yii2 под нагрузкой отдает страницу за 10-15мс без вообще какого-либо кеша бд, прикрутить пусь редис и это будет 3-5мс, на фоне которых еще и апач добавит своих.
и это будет уже заметно.
Ну если там cms с ttfb далеко за 300, то, конечно, значительной разницы не будет.
Они имеют право на существование, но кроме возможности править .htaccess на лету apache не несет дополнительной пользы.
А все сравнения apache с nginx, в которых они идут наравне это с отключенным AllowOverride, с ним же apache бегает на каждый запрос по диску в поисках этого самого .htaccess и это уже и есть та самая кардинальная разница.
То есть либо apache не нужен вообще, потому что он просто труба, в которую в одну сторону влили, из другой вылилось и он просто кушает ресурсы чтоб ничего не делать.
Либо у нас AllowOverride включен, но apache уже не очень сопоставим по производительности с nginx. И вот тут появляется та самая значительная разница.
В том, что апач не бесплатный, как и proxy_pass до него, а 1 + 1 + N всегда будет больше чем просто 1 + 1? Или это не очевидно из школьного курса математики?
во многих cms так лучше будет в работе.
Это приоткрывает завесу тайны над фанатичной любовью к апачу.
Не, я понимаю, что в случае с вордпресс/друпал/битрикс и всяким прочим, че уж там те накладные расходы — три с половиной rps они и есть, зато плагины могут гадить прямо в .htaccess. Удобно же.
Но мир php состоит далеко не из одних cms, да и те как-то обходятся и уживаются с nginx.
И в связи с этим здравый смысл задаёт нам два вопроса:
Зачем в принципе нужно лишнее звено в виде apache между nginx и php, если все отлично работает и так?
Зачем выбирать apache вместо nginx, если nginx + php-fpm имеют примерно одинаковую скорость работы с c apache + mod_php, но nginx быстрее обрабатывает статику и ssl, а в большинстве случаев (раз уж вы начали за cms, то в подавляющем) работа сервера будет заключаться и в обработке статики в том числе.
а nginx + apache (prefok + mod_fcgid) — во многих cms так лучше будет в работе
Так чем же nginx + apache будет лучше, чем просто nginx?
Давным-давно, когда деревья были выше, трава зеленее, а PHP выглядел далеко не так, php-fpm еще не существовал, а поэтому подружить быстрый nginx и php было очень не тривиальной задачей. Скорей всего именно поэтому и появился компромисс — статику отдавать быстрым nginx, а php дёргать из apache. Скорей всего именно из-за этого и появился эдакий бутерброд из двух слоёв хлеба.
Но недавно, к счастью, свершилось чудо!
Вышел в мир php-fpm и в новейшей версии php5.4 он был стабилизирован. Однако не все еще успели распробовать новинку… Ой, подождите, это же было в 2011 и с тех пор прошло уже 9 лет.
Возможно, нет никакой большой разницы между nginx + php-fpm и apache + mod_php, но есть значительная разница между nginx + php-fpm и nginx + apache + mod_php.
просто обычно "интересно" не даёт достаточно мотивации. видео с котиками на ютубе оно тоже интересное, а усилий прилагать не надо. поэтому проще потратить время на него, чем на новый язык.
не обязательно эта цель должна быть вот прям возможной, пусть она будет бредовой, но в нее нужно верить. если человек ставит перед собой цель сто миллионов, само собой, что она должна быть ему интересной.
не обязательно это должно быть что-то для себя, может что-то для других. "результат моей работы кому-то поможет и меня будут тепло вспоминать" — вполне себе аргумент против "в могилу не заберешь". может, никому и не поможет, но если достаточно сильно верить, то будет мотивацией и отправной точкой при выборе между ютубом и изучением нового языка.
А если почитать еще чуть более внимательно, то станет понятно что забрать можно всё.
но деньги на счету пайонир (те, что были свыше лимита по карте, обычно это $10к, на момент заморозки карты, либо те, что пришли после заморозки карты) можно вывести только банковским переводом, а через карту их снять нельзя.
а деньги, что на карте (обычно это до $10к на счету с картой на момент заморозки) можно снять только с карты (ATM или POS-терминал), а для перевода на банковский счет они станут доступны только после 6го. и пайонир до 6го убрал комиссию на снятие с карты. правда, работает с переменным успехом и больше условного лимита, который находится в районе $500 снять в банкомате не получится.
однако через банковскую кассу можно обналичить в пределах стандартных лимитов на снятие в кассе, действующего законодательства и здравого смысла.
не скажу ничего насчет Буркина-Фасо, но германия член NATO, а Австралия — союзник (Major Non-NATO Ally), так что хоть какого-то смысла запрещать им фейсбук в этом контексте нет, потому что они завязаны с США в одном военном блоке.
я имею ввиду, что вот это вот:
по-хорошему должен сделать был danog, предоставив интерфейс работы с хранилищем сессий, и дефолтный драйвер а-ля SessionStorageInterface, который бы работал как сейчас, но была бы возможность писать свои драйверы по-человечески.
в конкретно данном случае это должно быть что-то в духе (опять же, если совсем на пальцах)
с дефолтной заглушкой, а-ля
да и вообще сама структура madeline это ужас и боль.
я представляю себе объем работы, который выполнил автор, честь ему и хвала за усидчивость и вложенные силы, но качество проекта очень печальное.
и если стоит вопрос как-то серьезно кастомизировать её под свои нужды, то порой проще будет написать своё.
всё зря было, удаляйтео сколько нам открытий чудных...но не все yield одинаково полезны. yield сам по себе никакую магию асинхронности не делает, магию асинхронности делает amp, в котором вызывается функция-генератор.
когда вы пишете
внутри функции run происходит примерно следующее (ну если прям совсем на пальцах):
то есть за асинхронной функцией на yield должен стоят бекенд, который при yield промиса из этой функции будет дожидаться его и делать send при резолве этого промиса.
это происходит в случае, если вы выбрасываете из генератора промис в
1) контексте генератора, переданного в Loop::run()
2) в контексте генератора, вызванного через call/callAsync
3) в контексте корутины, созданной с помощью coroutine/asyncCoroutine
4) в контексте генератора, переданного в Promise\wait (который под капотом просто вызовет Loop::run())
мало того, вы не можете выбросить с помощью yield что угодно, вы должны выбрасывать инстанс amp или reactphp промиса.
пытаясь, например, сделать
вы выбросите результат выполнения функции unset (а именно null);
и этот код с точки зрения amphp будет эквивалентен
на самом деле, учитывая что у вас далеко не самая высокая нагрузка, а доступ к бд осуществляется практически всегда по PK, очень вряд ли вы существенно потеряли бы в производительности, если бы написали просто перегрузку массива на не асинхронном доступе к бд, просто через pdo. а еще лучше — взяли бы что-то более ориентированное на key-value, тот же редис.
вообще madeline, наверное, самое ужасное, что я видел из написанного на php в последние годы, и очень хороший пример, как проект выглядеть не должен. а попытки использования его не as is преврящаются в вот такие костыли, что на самом деле скорее грустно.
И на нерегулируемых пешеходных переходах, согласно ПДД, приоритет у пешеходов.
Но, видимо, водители считают, что не разгонять энтропию гораздо важнее, чем соблюдать никому не нужные правила, от которых не зависят жизни людей.
а тех, кто не тормозит перед пешеходными переходами, чтоб било током.
насмерть.
но уже при остановке авто.
в колбек для preg_replace_callback всегда передается массив матчей, даже если матч будет только один.
Вы сами же потом берете у массива $ord второй элемент, но почему-то в сигнатуре функции обозначили $ord как string.
Не хочу вас расстраивать..., но до этого тоже было так себе.
Потому что не нужно так делать.
а что на нем скорость мерять — он же полупустой :)
ну не в смысле что на нем чего-то не хватает, но это тот объем когда даже фуллскан таблиц практически не играет роли в производительности.
но добавьте пару десятков тысяч статей, тегов и посмотрите как оно будет жить, когда битрикс начнет активно бегать в бд.
я согласен, что у cms и битрикса есть своя ниша и они могут работать хорошо при тонкой настройке, но взгляните на большинство интернета — это грустно и «микрооптимизациями» занимаются крайне мало людей, можно же поставить волшебный плагин для кеша чтоб всё это хотябы не умирало.
ну и плюс php это все-таки не только cms, у меня yii2 под нагрузкой отдает страницу за 10-15мс без вообще какого-либо кеша бд, прикрутить пусь редис и это будет 3-5мс, на фоне которых еще и апач добавит своих.
и это будет уже заметно.
Они имеют право на существование, но кроме возможности править .htaccess на лету apache не несет дополнительной пользы.
А все сравнения apache с nginx, в которых они идут наравне это с отключенным AllowOverride, с ним же apache бегает на каждый запрос по диску в поисках этого самого .htaccess и это уже и есть та самая кардинальная разница.
То есть либо apache не нужен вообще, потому что он просто труба, в которую в одну сторону влили, из другой вылилось и он просто кушает ресурсы чтоб ничего не делать.
Либо у нас AllowOverride включен, но apache уже не очень сопоставим по производительности с nginx. И вот тут появляется та самая значительная разница.
Если сайт чуть сложнее, чем одностраничная визитка или простой интернет-магазин на десяток товаров, удобнее всего его держать не на битриксе.
В том, что апач не бесплатный, как и proxy_pass до него, а 1 + 1 + N всегда будет больше чем просто 1 + 1? Или это не очевидно из школьного курса математики?
Это приоткрывает завесу тайны над фанатичной любовью к апачу.
Не, я понимаю, что в случае с вордпресс/друпал/битрикс и всяким прочим, че уж там те накладные расходы — три с половиной rps они и есть, зато плагины могут гадить прямо в .htaccess. Удобно же.
Но мир php состоит далеко не из одних cms, да и те как-то обходятся и уживаются с nginx.
И в связи с этим здравый смысл задаёт нам два вопроса:
Так чем же nginx + apache будет лучше, чем просто nginx?
Давным-давно, когда деревья были выше, трава зеленее, а PHP выглядел далеко не так, php-fpm еще не существовал, а поэтому подружить быстрый nginx и php было очень не тривиальной задачей. Скорей всего именно поэтому и появился компромисс — статику отдавать быстрым nginx, а php дёргать из apache. Скорей всего именно из-за этого и появился эдакий бутерброд из двух слоёв хлеба.
Но недавно, к счастью, свершилось чудо!
Вышел в мир php-fpm и в новейшей версии php5.4 он был стабилизирован. Однако не все еще успели распробовать новинку… Ой, подождите, это же было в 2011 и с тех пор прошло уже 9 лет.
Возможно, нет никакой большой разницы между nginx + php-fpm и apache + mod_php, но есть значительная разница между nginx + php-fpm и nginx + apache + mod_php.
Нигерию то еще ладно, тут прям оплот расизма — https://en.m.wikipedia.org/wiki/Niger
есть же устоявшееся "жадная" загрузка, откуда этот гуглтранслейт?
просто обычно "интересно" не даёт достаточно мотивации. видео с котиками на ютубе оно тоже интересное, а усилий прилагать не надо. поэтому проще потратить время на него, чем на новый язык.
не обязательно эта цель должна быть вот прям возможной, пусть она будет бредовой, но в нее нужно верить. если человек ставит перед собой цель сто миллионов, само собой, что она должна быть ему интересной.
не обязательно это должно быть что-то для себя, может что-то для других. "результат моей работы кому-то поможет и меня будут тепло вспоминать" — вполне себе аргумент против "в могилу не заберешь". может, никому и не поможет, но если достаточно сильно верить, то будет мотивацией и отправной точкой при выборе между ютубом и изучением нового языка.
А если почитать еще чуть более внимательно, то станет понятно что забрать можно всё.
но деньги на счету пайонир (те, что были свыше лимита по карте, обычно это $10к, на момент заморозки карты, либо те, что пришли после заморозки карты) можно вывести только банковским переводом, а через карту их снять нельзя.
а деньги, что на карте (обычно это до $10к на счету с картой на момент заморозки) можно снять только с карты (ATM или POS-терминал), а для перевода на банковский счет они станут доступны только после 6го. и пайонир до 6го убрал комиссию на снятие с карты. правда, работает с переменным успехом и больше условного лимита, который находится в районе $500 снять в банкомате не получится.
однако через банковскую кассу можно обналичить в пределах стандартных лимитов на снятие в кассе, действующего законодательства и здравого смысла.
отличный план, надёжный, как швейцарские часы. а потом ребёнок будет всю оставшуюся жизнь проклинать родителей.
после чего тс поймёт, что его состояние сейчас это еще далеко не выгорание было.