Да Swoole крутая штука, с корутинами и асинхронным io, было бы интересно впихнуть сравнение в этот бенчмарк.
Вот только мой бенчмарк FPM vs Swoole (zend-expressive hello world) показал скорость выше всего на 20% (1000RPS). Возможно это было связано с мощным i7 процом (4/8).
Самая классная фича PHPStorm (и экономически себя оправдывающая) — встроенные WebStorm + Datagrip.
Неплохие фичи (хотелось бы дальнейшего развития) для DevOps'a (шелл, ссх, докер, кубер). Есть плагины на почти все случаи жизни (Markdown? Пожалуйста!).
Если речь про ранчер 1.6 — то да, тоже замечал что ipsec & dns помирают время от времени. Но в 2.0 уже ничего этого нет, пока не замечал таких странностей.
Он же в каталоге вроде есть. Но там есть нюансы в зависимости от ингресс контроллера…
З.Ы. Для меня неожиданность, что ранчер довольно популярное и/или узнаваемое решение в русскоязычном сегменте (да и вообще на этой стороне света)) Наверное стоит организовать какое-то комьюнити...
А не сложно для обычных разработчиков? Тут конфиги уже готовые, а как же понимание?
Как мне было бы проще взять Rancher 2.0 (установка в 1 клик докер команда) и зная AWS ключи можно поднять кластер в один клик без всяких kops и terraform...
Вот теперь понял.
Да действительно, для примитивного типа array и ArrayAccess придется создавать свой псевдотип (например «hashable»?) и оно никак не будет пересекается с «iterable».
Пойти что-ли предложить им «hashable» RFC? ))
Ответ почему типы решили объявлять в конце функции, а не в начале есть тут.
В целом думаю ориентир был на Hack, где это уже было реализовано именно так (типа зачем плодить другие варианты).
Верно! Тогда почему от хранилища с доступом по ключу ждут возможность итерации (iterable)? )
foreach для ArrayAccess никогда работал — https://3v4l.org/8H8vR
А что в PHP есть встроенные классы, которые реализуют только интерфейс ArrayAccess?
Насколько я помню (но могу и ошибаться), все кто реализует ArrayAccess так или иначе используют и Traversable интерфейс в конечном итоге. Например, тот же ArrayObject — он будет принят через «iterable» тип.
Другой вопрос самописные классы — но в них нет проблем добавить еще один дополнительный интерфейс Iterator или IteratorAggregate и все так же будет работать…
Ну проколы бывают у всех. Это хотели сломать еще в 7.0.0 — что было бы естественным.
Обьяснение
It is unfortunate that this change had to happen in a patch release, rather than in PHP 7.0.0. It's my fault that I did not notice during the pre-release cycle that this previously relatively harmless bug completely breaks the null-coalesce operator in PHP 7. However, that's how things went, and at this point a fix was critical.
For reference, the way to fix any issues with this change is to make sure your __isset() or offsetExists() functions behave correctly. If this change causes issues with your code, it indicates that you already have a broken __isset/offsetExists implementation, but it's brokenness did not previously surface (one bug canceling another...)
А вообще согласен, даже patch версии нельзя бездумно или автоматически обновлять, хотя бы не почитав changelog. )
Если говорить о нагрузке, то на данный момент в течение дня приходит от 600 до 2000 строчек с логами в секунду, с периодическими всплесками до 10 тысяч строчек. Данную нагрузку система переваривает без каких-либо проблем.
А можно поинтересоваться мощностью ваших машин выделенных под ELK стек?
Безусловно Rancher со swarm'ом не идет ни в какое сравнение. У ранчера отличное API и есть CLI утилиты. И идея иметь параллельный docker-compose и rancher-compose — тоже отличная идея (в отличии от того же Kubernetes).
Это — docs.rancher.com/rancher/rancher-services/storage-service?
Да, но там всего лишь 2 провайдера, glusterfs (который боязно применять в продакшене) и nfs который тормознутый даже для dev (плюс избыточно). А вот если настроить на хосте convoy с каким-то бекендом, то ранчер по сути не видет это все хозяйство и управлять volumes можно только в консоли хостов. Но подвижки в этом направлении в ранчере идут. Надеюсь вызреет что-то )
более гибкий service discovery
А чего именно Вам не хватает?
Встроенных провайдеров много — это однозначно плюс, но хардкод
<service>.<stack>.<env>.<domain>
иногда избыточен. Нахватает возможностей CNAME из самого ранчера (чтобы не лазить в сам провайдер).
К примеру lb.project1.dev.domain.com -> LB разбрасывает запросы на другие стеки (один проект но разные ветки/девелоперы) -> nginx.prj1_user1.dev.domain.com, nginx.prj1_user2.dev.domain.com и тд. Сейчас, чтобы сделать это нужно у каждого nginx сервиса открыть порт на хосте (иначе DNS запись не создать), потом пойти в LB сервис и загнать каждый стек девелопера под правило по хостнейму. Можно использовать alias'ы, чтобы прописывать более удобные DNS, но опять же это возможность отредактировать только первый уровень хостнейма.
Это да… А кто предоставляет более гибкий acl?
Ну безусловный лидер в этой области Amazon ECS с их амазоновскими полиси. Для ранчера конечно такого монстра не нужно, но GitHub провайдер и разграничений на уровне environments явно маловато (например, разные клиенты, но один прод env).
Он еще определённо сырой, НО ужасно перспективный судя по их репозиторий и активности. Мы начали его использовать для дев окружения, работает стабильно, интересная идея с каталогом готовых стеков (в том числе есть и Kubernetes), но многих вещей не хватает — тома, бекапы (интеграция с convoy), более гибкий service discovery, более гибкий acl, больше авторизаций).
Но да, хотелось бы еще реальные мнения послушать...
Это callable? Вроде да. В чем подвох? а может это все же array? ))
Так вроде никто и не мешает:
Вот только мой бенчмарк FPM vs Swoole (zend-expressive hello world) показал скорость выше всего на 20% (1000RPS). Возможно это было связано с мощным i7 процом (4/8).
Неплохие фичи (хотелось бы дальнейшего развития) для DevOps'a (шелл, ссх, докер, кубер). Есть плагины на почти все случаи жизни (Markdown? Пожалуйста!).
Ну и правильно, а то вдруг все побегут с AWS на Гугл, а он не резиновый :)
Если речь про ранчер 1.6 — то да, тоже замечал что ipsec & dns помирают время от времени. Но в 2.0 уже ничего этого нет, пока не замечал таких странностей.
Он же в каталоге вроде есть. Но там есть нюансы в зависимости от ингресс контроллера…
З.Ы. Для меня неожиданность, что ранчер довольно популярное и/или узнаваемое решение в русскоязычном сегменте (да и вообще на этой стороне света)) Наверное стоит организовать какое-то комьюнити...
А не сложно для обычных разработчиков? Тут конфиги уже готовые, а как же понимание?
Как мне было бы проще взять Rancher 2.0 (установка в 1 клик докер команда) и зная AWS ключи можно поднять кластер в один клик без всяких kops и terraform...
P.S. № заказа: 6227979088
Да действительно, для примитивного типа array и ArrayAccess придется создавать свой псевдотип (например «hashable»?) и оно никак не будет пересекается с «iterable».
Пойти что-ли предложить им «hashable» RFC? ))
В целом думаю ориентир был на Hack, где это уже было реализовано именно так (типа зачем плодить другие варианты).
foreach для ArrayAccess никогда работал — https://3v4l.org/8H8vR
Насколько я помню (но могу и ошибаться), все кто реализует ArrayAccess так или иначе используют и Traversable интерфейс в конечном итоге. Например, тот же ArrayObject — он будет принят через «iterable» тип.
Другой вопрос самописные классы — но в них нет проблем добавить еще один дополнительный интерфейс Iterator или IteratorAggregate и все так же будет работать…
For reference, the way to fix any issues with this change is to make sure your __isset() or offsetExists() functions behave correctly. If this change causes issues with your code, it indicates that you already have a broken __isset/offsetExists implementation, but it's brokenness did not previously surface (one bug canceling another...)
А вообще согласен, даже patch версии нельзя бездумно или автоматически обновлять, хотя бы не почитав changelog. )
А можно поинтересоваться мощностью ваших машин выделенных под ELK стек?
Да, но там всего лишь 2 провайдера, glusterfs (который боязно применять в продакшене) и nfs который тормознутый даже для dev (плюс избыточно). А вот если настроить на хосте convoy с каким-то бекендом, то ранчер по сути не видет это все хозяйство и управлять volumes можно только в консоли хостов. Но подвижки в этом направлении в ранчере идут. Надеюсь вызреет что-то )
Встроенных провайдеров много — это однозначно плюс, но хардкод иногда избыточен. Нахватает возможностей CNAME из самого ранчера (чтобы не лазить в сам провайдер).
К примеру lb.project1.dev.domain.com -> LB разбрасывает запросы на другие стеки (один проект но разные ветки/девелоперы) -> nginx.prj1_user1.dev.domain.com, nginx.prj1_user2.dev.domain.com и тд. Сейчас, чтобы сделать это нужно у каждого nginx сервиса открыть порт на хосте (иначе DNS запись не создать), потом пойти в LB сервис и загнать каждый стек девелопера под правило по хостнейму. Можно использовать alias'ы, чтобы прописывать более удобные DNS, но опять же это возможность отредактировать только первый уровень хостнейма.
Ну безусловный лидер в этой области Amazon ECS с их амазоновскими полиси. Для ранчера конечно такого монстра не нужно, но GitHub провайдер и разграничений на уровне environments явно маловато (например, разные клиенты, но один прод env).
Но да, хотелось бы еще реальные мнения послушать...