Я видел что написали, спасибо.
Я не думаю, что nginx + memcached будет быстрее чем Varnish. Здесь скорее уже надо полноценно замерять.
В большинстве случаев думают что Варниш будет хуже работать, так как пишет кеши на диск. Но не следует забывать, что раздел можно подцепить на оперативную память, и тогда он точно также будет писать как и Memcached.
Также, в Варнише есть очень прикольная штука ESI — что может в разы увеличить производительность некоторых разделов сайта/портала.
На самом деле кеширование — очень даже интересный аспект и не только в Друпале. При использовании кеширования самих сущностей (Entity), нужно быть очень акуратным, именно в том плане, что после подключения кеширования необходимо записывать/читать данные только используя Ваш код с кеширующим слоем, и ни в коем случае нельзя уже тогда менять прямо в БД, или через другие скрипты.
Хотел бы еще добавить, относительно выбора «Cache Storage»: в частности, большинство стают перед выбором Redis vs Memcache(d).
Здесь необходимо понимать, что такое Memcache(d) и что такое Redis
Memcached — это key & value хранилище. Имеет ряд недостатков, главным из которых есть выброс старых ключей, если есть нехватка памяти. То есть, к примеру у Вас там только 16 Мб. Вы загрузили туда кешей на все 16 Мб. После этого, если Вы будут вставлять в него новые данные, старые будут удалены. Во время перезагрузки Вы тоже потеряете данные.
Redis — это не только key & value хранилище, но и полноценное хранилище для других типов данные, таких как HASH, LIST. При этом, есть очень хорошая поддержка Lua-скриптов и другого нативного функционала, что иногда очень упрощает жизнь. Большой плюс — это «сливание данные» на винт (если указано в конфиге), в результате, данные при перезагрузке потеряны не будут. Также в нем очень хорошо распределяется память (я бы сказал лучше чем у memcached). Выбор на этот «монстр» нельзя делать только для использования key & value!
Моя практика показывает, что кеширования сущностей, дает слабоватый прирост производительности ПО СРАВНЕНИЮ с HTTP кешированием. Было бы очень интересно посмотреть на возможности кеширования Varnish, Nginx + Memcached (или другие связки) в самом Друпале.
RFC: arrayof — Предлагается реализовать небольшое улучшение type hinting для массивов: function foo(Bar[] $bars) {} — каждый элемент массива $bars должен быть типа Bar.
А это уже наверное по лучше будет, чем писать вечно типо:
public function sets(array $data)
{
foreach($data as $key => $value) {
if (!$value instanceof \Foo\Bar) { /**… InvalidArgumentException **/ }
}
}
Ну тогда объясните, как IDE (PHPStorm) может дописать куку в запросе, который генерит браузер, не имея на это прав?
Почему тогда ж при нажатии на кнопку «жучка» добавляется GET параметр XDEBUG_SESSION_START…
Есть одна трудность, которую Вы все же упустили наверное:
Кнопка Дебаг (в виде жучка), запустит только ту страницу, которая была указана в конфиге да еще и в браузере по умолчанию. В результате, нету возможность перехода по ссылкам со включенным дебагом (не я имею ввиду без бубна), а также сабмитить формы.
Лучшим же решением будет установка плагинов, которые автоматом добавляют куку при запросе.
Для хрома chrome.google.com/webstore/detail/xdebug-helper/eadndfjplgieldjbigjakmdgkmoaaaoc В результате, только включаем слушателя в шторме, жучка в хроме, и вауля, и все формы, и все страницы уже будут проходить через XDebug (Правда заметил фичу, не работает, если в браузер будет идти application/xml)
Относительно других не знаю, но точно есть, так как вещь не заменимая.
В 2.4 уже не мало добавлено, что упрощает разработку. Но на данный момент, наверное лучше будет писать под 2.3, так как это стабильная версия, поддержка которой будет точно еще полтора года, в результате, большинство ее и используют.
2. Здесь наверное нужно четко распределить, что же такое «схема БД» и «миграция»!
3. Ну главное, чтобы разработчику было уютно в своем коде! :)
4. Верно, кому как. Но этот подход намного тяжелее поддерживать, тестировать. Вот к примеру мы захотим протестить сервис, который вызывает другой сервис через статику…
Лично мне кажется, что здесь уж много велосипедов наново создавались…
Я не могу критиковать данный фраемворк, так как с ним не работал, но по посту было замечено:
1. Создания сущностей немного сложноватое. Если посмотреть в сторону Doctrine 2 (Symfony2/DoctrineBundle), то там все намного проще и лаконичней. Все связи определяются в одном классе, при этом будут созданы все необходимые ключи.
2. Миграции. А зачем они были вообще созданы? Чтобы во время разработки приложения создавать связи? habrahabr.ru/post/121265/
Если я не ошибаюсь, то «миграции» создаются в целях «без болезненного» перехода на новую архитектуру (Изменился тип поля в БД, либо добавлено новое)
3. Темизатор. Не один раз уже вижу в инете куча новых возможно и классных темизаторов. Но зачем наново создают велосипеды? Чтобы потом сказать: «ЭТО Я СДЕЛАЛ, но у меня времени не было, чтобы его сделать так как Twig, или Smarty»
4. Все на статике. Лично я не поклонник статики в таком объеме, по той причине, что нету возможности хорошо указать зависимости среди сервисов, сделать override того или инного сервиса, не наступая на грабли и не создавая своих костылей.
P.S. Круто, супер, новая система, новый фремворк, новые знания, достижения!!! Но задайте себя вопросом, бедет ли он уместен на ОЧЕНЬ больших проектах, где архитектурное решение — самое главное в разработке?
P.S.S. Автору большое спасибо за статью, познавательно!
В общем, как для меня, идея прикольная, но вряд ли она будет иметь место в жизни, по многим факторам, да и не выгодно совсем это будет финансово. Если уж надоело уже место работы, Вы не получаете от нее «кайфа/увлечения/игры», то здесь лучше подумать насчет смены обстановки. К примеру переехать в другой город, изменить рабочий кабинет/комнату.
Я с пушами рабоатаю уже не один год (Под проектом AppRus). в результате, могу добавить:
1. 50к+ — Отправлять используя AMQP
2. Разрыв соединения — Да, есть, здесь уж ничего не поделаешь, но кто мешает наново заново открыть соединение?
3. Относительно длины 255 байт. Да, с этим они загнали, но вполне это можно решить передачей какого-то «ключа», а уже приложение при обработке пуша сделает то, что нужно.
4. Feedback — здесь очень сильно нужно переделить внимание. Согласно правилам Аппле, Вы обязательно должны опрашивать сервер на наличие «invalid devices», чтобы потом не слать пуши на эти токены. Если этот пункт будет проигнорирован, то аппле имеет полное право заблокировать приложение.
В общем, проблем и сильных подводных камней здесь вообще нету.
P.S. (Пиарюсь :) ):
Можете воспользоваться пакетом github.com/ZhukV/AppleApnPush для отправки пушей (Этот пакет уже проверен веременем + поддерживает отправку со списков: AMQP, Redis)
Я лично на своем опыте писал на много чем.
Лично мне, понравились Друпал и Симфони
Drupal — хорошо подходит как CMF (Content Manager Framework)
Symfony 2 — очень сильный монстр, на котором можно написать приложения любой сложности.
Да, я с Вами вполне согласен! Я тоже иногда в проектах использую трейты, чтобы сократить время, но вот была на днях засада: Создал компонент, используя трейты, а в заказчика на хостинге PHP 5.3. Ну и на хостингах не везде можно попросить установить ПХП 5.4 (К примеру Mirohost). Вот и облажался.
Да и вот какие есть реальные задачи, где нужно использовать трейты (если говорить о проектировании системы)?
Почти все проблемы решаються выбором той или инной схемы патерна.
1. Зачем использовать трейты для таких элементарных задач, я все же не понял.
2. Вы объявляете функции с жестко заданым параметром \Closure. Это работает, но в контексте проектирования это не верно.
public function each($callback)
{
if (!is_callable($callback)) { throw new \InvalidArgumentException(); }
// ....
}
Так Вы сможете тыкать туда не только анонимные, но и типа: usort, array($object, 'methodName')
Ну и автору на заметку:
1. Использования в коде PHP 5.4 на данный момент не рекомендуеться, так как множество проектов просто не смогут заработать на ПХП 5.3 (К примеру: объявление массива [], использования трейтов).
2. Для получения массива с объекта, Вы используете toArray. Лучше унаследуйтесь от интерфейса IteratorAggregate
P.S.
В плане реализации этой задачи можно сразу использовать \Doctrine\Common\Collections\Collection :D
www.kyivstar.ua/ru/cr/sms
Я не думаю, что nginx + memcached будет быстрее чем Varnish. Здесь скорее уже надо полноценно замерять.
В большинстве случаев думают что Варниш будет хуже работать, так как пишет кеши на диск. Но не следует забывать, что раздел можно подцепить на оперативную память, и тогда он точно также будет писать как и Memcached.
Также, в Варнише есть очень прикольная штука ESI — что может в разы увеличить производительность некоторых разделов сайта/портала.
Хотел бы еще добавить, относительно выбора «Cache Storage»: в частности, большинство стают перед выбором Redis vs Memcache(d).
Здесь необходимо понимать, что такое Memcache(d) и что такое Redis
Memcached — это key & value хранилище. Имеет ряд недостатков, главным из которых есть выброс старых ключей, если есть нехватка памяти. То есть, к примеру у Вас там только 16 Мб. Вы загрузили туда кешей на все 16 Мб. После этого, если Вы будут вставлять в него новые данные, старые будут удалены. Во время перезагрузки Вы тоже потеряете данные.
Redis — это не только key & value хранилище, но и полноценное хранилище для других типов данные, таких как HASH, LIST. При этом, есть очень хорошая поддержка Lua-скриптов и другого нативного функционала, что иногда очень упрощает жизнь. Большой плюс — это «сливание данные» на винт (если указано в конфиге), в результате, данные при перезагрузке потеряны не будут. Также в нем очень хорошо распределяется память (я бы сказал лучше чем у memcached). Выбор на этот «монстр» нельзя делать только для использования key & value!
Моя практика показывает, что кеширования сущностей, дает слабоватый прирост производительности ПО СРАВНЕНИЮ с HTTP кешированием. Было бы очень интересно посмотреть на возможности кеширования Varnish, Nginx + Memcached (или другие связки) в самом Друпале.
А это уже наверное по лучше будет, чем писать вечно типо:
public function sets(array $data)
{
foreach($data as $key => $value) {
if (!$value instanceof \Foo\Bar) { /**… InvalidArgumentException **/ }
}
}
Почему тогда ж при нажатии на кнопку «жучка» добавляется GET параметр XDEBUG_SESSION_START…
Кнопка Дебаг (в виде жучка), запустит только ту страницу, которая была указана в конфиге да еще и в браузере по умолчанию. В результате, нету возможность перехода по ссылкам со включенным дебагом (не я имею ввиду без бубна), а также сабмитить формы.
Лучшим же решением будет установка плагинов, которые автоматом добавляют куку при запросе.
Для хрома chrome.google.com/webstore/detail/xdebug-helper/eadndfjplgieldjbigjakmdgkmoaaaoc В результате, только включаем слушателя в шторме, жучка в хроме, и вауля, и все формы, и все страницы уже будут проходить через XDebug (Правда заметил фичу, не работает, если в браузер будет идти application/xml)
Относительно других не знаю, но точно есть, так как вещь не заменимая.
2. Это спорный вопрос, но в большинстве ответят: Зачем это делать, если это умеет делать ORM. Если фраемворк так устроен, то значит так нужно :)
4. Ну а Вы как считаете, что лучше тестировать? Статику или объекты созданные с конструктора?
2. Здесь наверное нужно четко распределить, что же такое «схема БД» и «миграция»!
3. Ну главное, чтобы разработчику было уютно в своем коде! :)
4. Верно, кому как. Но этот подход намного тяжелее поддерживать, тестировать. Вот к примеру мы захотим протестить сервис, который вызывает другой сервис через статику…
Я не могу критиковать данный фраемворк, так как с ним не работал, но по посту было замечено:
1. Создания сущностей немного сложноватое. Если посмотреть в сторону Doctrine 2 (Symfony2/DoctrineBundle), то там все намного проще и лаконичней. Все связи определяются в одном классе, при этом будут созданы все необходимые ключи.
2. Миграции. А зачем они были вообще созданы? Чтобы во время разработки приложения создавать связи? habrahabr.ru/post/121265/
Если я не ошибаюсь, то «миграции» создаются в целях «без болезненного» перехода на новую архитектуру (Изменился тип поля в БД, либо добавлено новое)
3. Темизатор. Не один раз уже вижу в инете куча новых
возможно и классныхтемизаторов. Но зачем наново создают велосипеды? Чтобы потом сказать: «ЭТО Я СДЕЛАЛ, но у меня времени не было, чтобы его сделать так как Twig, или Smarty»4. Все на статике. Лично я не поклонник статики в таком объеме, по той причине, что нету возможности хорошо указать зависимости среди сервисов, сделать override того или инного сервиса, не наступая на грабли и не создавая своих костылей.
P.S. Круто, супер, новая система, новый фремворк, новые знания, достижения!!! Но задайте себя вопросом, бедет ли он уместен на ОЧЕНЬ больших проектах, где архитектурное решение — самое главное в разработке?
P.S.S. Автору большое спасибо за статью, познавательно!
1. 50к+ — Отправлять используя AMQP
2. Разрыв соединения — Да, есть, здесь уж ничего не поделаешь, но кто мешает наново заново открыть соединение?
3. Относительно длины 255 байт. Да, с этим они загнали, но вполне это можно решить передачей какого-то «ключа», а уже приложение при обработке пуша сделает то, что нужно.
4. Feedback — здесь очень сильно нужно переделить внимание. Согласно правилам Аппле, Вы обязательно должны опрашивать сервер на наличие «invalid devices», чтобы потом не слать пуши на эти токены. Если этот пункт будет проигнорирован, то аппле имеет полное право заблокировать приложение.
В общем, проблем и сильных подводных камней здесь вообще нету.
P.S. (Пиарюсь :) ):
Можете воспользоваться пакетом github.com/ZhukV/AppleApnPush для отправки пушей (Этот пакет уже проверен веременем + поддерживает отправку со списков: AMQP, Redis)
Лично мне, понравились Друпал и Симфони
Drupal — хорошо подходит как CMF (Content Manager Framework)
Symfony 2 — очень сильный монстр, на котором можно написать приложения любой сложности.
Да и вот какие есть реальные задачи, где нужно использовать трейты (если говорить о проектировании системы)?
Почти все проблемы решаються выбором той или инной схемы патерна.
1. Зачем использовать трейты для таких элементарных задач, я все же не понял.
2. Вы объявляете функции с жестко заданым параметром \Closure. Это работает, но в контексте проектирования это не верно.
Так Вы сможете тыкать туда не только анонимные, но и типа: usort, array($object, 'methodName')
Ну и автору на заметку:
1. Использования в коде PHP 5.4 на данный момент не рекомендуеться, так как множество проектов просто не смогут заработать на ПХП 5.3 (К примеру: объявление массива [], использования трейтов).
2. Для получения массива с объекта, Вы используете toArray. Лучше унаследуйтесь от интерфейса IteratorAggregate
P.S.
В плане реализации этой задачи можно сразу использовать \Doctrine\Common\Collections\Collection :D