Знаете меня реально достала эта странная вырожденная идея с 3ей нормальной формой которую суют везде. В результате чего получаются монстры кеда чтоб вывести авторов статей нужно сделать N запросов или «хитро»-стандартный JOIN 2х таблиц по ключу. Вся эта сраная магия которая согласуется с реальностью от слова никак.
НЕ нужно хранить связанные данные отдельно. Храните себе данные домена — ВМЕСТЕ.
Данные об авторе рядом со статьей, теги тоже как часть статьи. А для сбора авторов — отдельно заботясь при сохранении в Repository. Или вообще отдельным процессом раз в день по крону. Ну не появится ваш супер пупер автор в туже секунду и что? Мир схлопнется — нет же. Никто его и не заметит. Тоже самое +1 тег для статьи влияет на общую картину тегов — от слова НИКАК. Потому что 1 тег << 100500 других тегов в 1000+ статей
Скажу просто. ТО что написано просто дичь какая-то.
1. Если деплой делать хорошо — тогда лучше blue-green выкатывая тупо новую версию сразу на виртуальные на НОВЫЕ виртуальные машины, так можно и релизить кусками (ака 1% пользователей — 10%… 100%) и так нет проблем с откатом тк все 100% независимое и рабочее
2. Если все плохо судя из того что пишете. То имхо стоит использовать то что люди дааааавно придумали с releases -> symlink to -> current dir дешево сердито и не нужен рут. Да орд кульно но работает стабильно и если вдруг что пошло не так тупо меняем симлинк онбартно на предидущий релиз. Есть 100500 готовых решений для того деплоя просто бери и юзайте.
3. Если все плохо но хочется докер. НА*** маунтить директорию ??? Зачем что за дичь? Почему просто не собрать готовый образ со всем вместе со всеми папками, правами, php-fpm and nginx просто вот такой веб-бокс который можно запустить где угодно хоть локально хоть на проде. Релиз-откат тогда это просто переключение между тегами для образа — дешево -сердито-стабильно.
Релиз это не магия с какими-то танцами с бубном это просто тупой однообразный процесс, причем абсолютно бездумный и он таким и должен быть.
Добро пожаловать в в самую свободную страну в мире — СССР! Кажется такой лозунг когда-то приветствовал людей приезжающих в СССР из вне железного занавеса. Как-то этот лозунг немного напоминает фашистов с их концентрационными лагерями и «веселой» надписью: «Arbeit macht frei».
Мне итак нравилось я работал удаленно, но мог и ходить в офис, обычно по средам встречались поговорить и поиграть во что-то, платили дофига. Но по собеседованиям я все равно ходил, летал на выходные в другой город потусить и на собес за деньги компании причем там сразу перелагали +2к от текущей зп. И это все мое :)
Ех, прямо себя узнал. Да я такой, ходил по собесам просто чтоб узнать кто больше предложит хотя мне нафиг не нужны были их деньги, это было скорее как спорт. Причем не понятно зачем: чтоб потешить свое самомнение пройти собеседование на скорость за 5 мин и срубить предложение на 5к или выступить на конфе называя всех идиотами со сцены наблюдая за тем как люди слушают тебя и верят во всю эту чушь. Я такой же засранец!
Страница с ценами должна быть даже если там будет написано бесплатно. Это реально первое что ищу кастомеры.
Еще крайне желательно чтоб была цена хоть какая-то $5/month хотя бы. Потому что бесплатный сервис нет смысла использовать — тут он есть а завтра его уже нет. Для бизнеса интеграции это долго и дорого и ты должен быть уверен в платформе на которую мигрируешь, иначе в этом нет смысла. Именно по этому прайсинг и цена важны, так как это гарантирует что вот мы берем за это вот столько денег, мы зарабатывает, вот наш источник дохода и мы никуда не денемся.
Даже если брать в расчет идею и возможную полезность проекта. Вот так с порога сразу же требовать авторизацию — регистрацию через Google :) это уже слишком. Картинка
Ни тебе ни здрати, ни кто такие и что делаем, privacy policy missed, terms of use missed, pricing missed, product description missed. То есть давайте вы нам все данные отдадите, а мы покажем вам какую-то неведомую зверушку.
Проблема в том что generics, висят в Under Discussion с Created 2015/04/28 и как бы стол и ныне там.
Так увидеть их в 8 тоже маловероятно. Для того чтоб куда-то что-то двигалось нужно чтоб прошло голосование (In voting phase). А пока это one-person-opinion-feature.
Проблема с конекшенами, это не только открыть — но и закрыть. Что иногда даже важнее. Любой зависший, упавший но не закрывший осенние варке будет держать соединение вечно — пока его не перезапустишь. И в какой-то момент можно наблюдать по 10-20к соединений к memcached / mongodb cluster, после которого для начала сразишься тюнить систему разрешая больше соединений, больше открытых файлов. Но в конце концов это работает плохо.
Касательно отлова ошибок: shutdown_function не вызовется когда варвар сожрал всю оперативку и упал к примеру или unrecoverable fatal. И это крайне неприятно, потому что и поместить задачу ты не можешь. Она просто не доходит до конца.
После долгой борьбы мы пришли к более простому понимаю что такое воркер: воркер это независимая команда. А если она независимая то нет разницы запускать через fork or php -f. Но с другой стороны запуская через php -f, ты получаешь все бонусы 100% независимой команды, все соединия открываются и закрываются самим php, нет зависимости от предидущих глобальных переменных и значений, этот подход позволяет утилизировать память по максимуму.
Benefits:
— ловля всех ошибок!
— потребление памяти воркерами сократилось в 10 раз
— срочность процессинга выросла в 3.5 раза (из-за того что меньше оперативки можно отключить GC)
— простота разработки
— простота connection management
— не течетет блин вообще никак (сам manager жрет 8Mb оперативки и живет месяцами)
— и как приятный бонус не нужно ставить pcntl ;)
Drawbacks:
— дополнительные 20 мс на запуск внешнего интерпретатора
pcntl хорошо работает только для самых простых приложений. Но в реальности крайне неприятно следить за конекшенами, перезапускать демоны, следить вообще за ними и распределять нагрузку. Еще из возможных неприятных проблем это то что syntax error or fatal error никак не хендлится. Ну поесть если пришила такая задача на которой приложение упало (причем желательно сразу), то через какое время будет лежать все. Медленно текущая память тоже не сильно принято, когда утекает сначала по 10-20 мб а потом это выливается в 2Гб демон который еле работает из постоянной попытки собрать мусор и выделить новую память.
На порядок проще и стабильно работает связка: демон очередей (rabbit/gearman/redis pub/sub etc.) + supervizor.
Я просто оставлю это здесь: https://aws.amazon.com/efs/ — elastic file system (aka NSF от амазона) https://www.gluster.org — распределения файловая система с недавнего времени принадлежит redhat
Делается следующим образом:
создаем свой образ со всем установленным софтом который только и умеет что брать заданный файл и считать
в тот момент когда обновить модель,
а. пишем данные в локальный файл в распределенной файловой системе
b. запускаем инстанс из сохраненного образа и считаем все что нужно
c. тушим инстанс который занимался расчетом
Это не совсем так голова отличный кеш-но он слишком умный. реальный кеш это лист бумаги на который ты записываешь имя человека и сбоку рисуешь его портрет для распознавания. И дальше когда добавляется новый коллега ты его добавляешь туда, а если удаляется пытается соотнести изображение с тем что у тебя нарисовано и вычеркнуть. А еще веселее если 2 брата близнеца работают в разных отделах. И кеш у тебя не просил листик а еще отображает иерархию отделов (вед охота знать что вот это Админ идет). И тогда ситуация перевода человека из одного отдела в другой это вообще ужас-ужас.
Кеш прячет проблемы производительности, а не решает их. Все те бутылочные горлышка которые есть в приложении продолжают быть ими без изменений, что приводит к еще более печальной ситуации когда кеш перестанет справляться с нагрузкой тоже.
Но как бывает со всем другим. лучшие практики не всегда применимы ко всем, множество приложений не дорастает до нагрузки когда кеш не справляется или когда логика инвалидации становится слишком сложной для поддержки. Поэтому кеширование так и популярно как быстрое решение проблем с узким местом в приложении. А понимание проблем которые это влечет приходит наааамного позже.
Самый большой вопрос в данном случае что происходит когда демон умирает или связь затыкается. Такая простая реализация на коленке конечно будет работать, но в реальности нужно делать heartbeat, продумывать и реализовывать свой протокол с обработкой ошибок, обработкой дубликатов, ресабмит данных в очередь, шардинг тасков через воркеры динамически и т.д. Реальность достаточно сложная штука, еще следить за тем как закрываются и обрабатываются соединения в самом php и избегать блокировки ресурсов или снова наворачивать еще микро-очереди-сервисы для блокирующих операций.
Крайне рекомендую посмотреть доклад Алексея Качаева про ZeroMQ для того чтоб понять что все это далеко не так просто как написать 3 строчки кода и что люди используют готовые сервера очередей не просто так: www.youtube.com/watch?v=d26LufnoQ4I
НЕ нужно хранить связанные данные отдельно. Храните себе данные домена — ВМЕСТЕ.
Данные об авторе рядом со статьей, теги тоже как часть статьи. А для сбора авторов — отдельно заботясь при сохранении в Repository. Или вообще отдельным процессом раз в день по крону. Ну не появится ваш супер пупер автор в туже секунду и что? Мир схлопнется — нет же. Никто его и не заметит. Тоже самое +1 тег для статьи влияет на общую картину тегов — от слова НИКАК. Потому что 1 тег << 100500 других тегов в 1000+ статей
1. Если деплой делать хорошо — тогда лучше blue-green выкатывая тупо новую версию сразу на виртуальные на НОВЫЕ виртуальные машины, так можно и релизить кусками (ака 1% пользователей — 10%… 100%) и так нет проблем с откатом тк все 100% независимое и рабочее
2. Если все плохо судя из того что пишете. То имхо стоит использовать то что люди дааааавно придумали с releases -> symlink to -> current dir дешево сердито и не нужен рут. Да орд кульно но работает стабильно и если вдруг что пошло не так тупо меняем симлинк онбартно на предидущий релиз. Есть 100500 готовых решений для того деплоя просто бери и юзайте.
3. Если все плохо но хочется докер. НА*** маунтить директорию ??? Зачем что за дичь? Почему просто не собрать готовый образ со всем вместе со всеми папками, правами, php-fpm and nginx просто вот такой веб-бокс который можно запустить где угодно хоть локально хоть на проде. Релиз-откат тогда это просто переключение между тегами для образа — дешево -сердито-стабильно.
Релиз это не магия с какими-то танцами с бубном это просто тупой однообразный процесс, причем абсолютно бездумный и он таким и должен быть.
Еще крайне желательно чтоб была цена хоть какая-то $5/month хотя бы. Потому что бесплатный сервис нет смысла использовать — тут он есть а завтра его уже нет. Для бизнеса интеграции это долго и дорого и ты должен быть уверен в платформе на которую мигрируешь, иначе в этом нет смысла. Именно по этому прайсинг и цена важны, так как это гарантирует что вот мы берем за это вот столько денег, мы зарабатывает, вот наш источник дохода и мы никуда не денемся.
Даже если брать в расчет идею и возможную полезность проекта. Вот так с порога сразу же требовать авторизацию — регистрацию через Google :) это уже слишком.
Картинка
Ни тебе ни здрати, ни кто такие и что делаем, privacy policy missed, terms of use missed, pricing missed, product description missed. То есть давайте вы нам все данные отдадите, а мы покажем вам какую-то неведомую зверушку.
Проблема в том что generics, висят в Under Discussion с Created 2015/04/28 и как бы стол и ныне там.
Так увидеть их в 8 тоже маловероятно. Для того чтоб куда-то что-то двигалось нужно чтоб прошло голосование (In voting phase). А пока это one-person-opinion-feature.
php 7.1 как бы вышел уже, generics там нет http://php.net/manual/en/migration71.new-features.php
и в 7.2 их тоже (барабанная дробь) не будет https://wiki.php.net/rfc#php_next_72
Касательно отлова ошибок: shutdown_function не вызовется когда варвар сожрал всю оперативку и упал к примеру или unrecoverable fatal. И это крайне неприятно, потому что и поместить задачу ты не можешь. Она просто не доходит до конца.
После долгой борьбы мы пришли к более простому понимаю что такое воркер: воркер это независимая команда. А если она независимая то нет разницы запускать через fork or php -f. Но с другой стороны запуская через php -f, ты получаешь все бонусы 100% независимой команды, все соединия открываются и закрываются самим php, нет зависимости от предидущих глобальных переменных и значений, этот подход позволяет утилизировать память по максимуму.
Benefits:
— ловля всех ошибок!
— потребление памяти воркерами сократилось в 10 раз
— срочность процессинга выросла в 3.5 раза (из-за того что меньше оперативки можно отключить GC)
— простота разработки
— простота connection management
— не течетет блин вообще никак (сам manager жрет 8Mb оперативки и живет месяцами)
— и как приятный бонус не нужно ставить pcntl ;)
Drawbacks:
— дополнительные 20 мс на запуск внешнего интерпретатора
На порядок проще и стабильно работает связка: демон очередей (rabbit/gearman/redis pub/sub etc.) + supervizor.
https://aws.amazon.com/efs/ — elastic file system (aka NSF от амазона)
https://www.gluster.org — распределения файловая система с недавнего времени принадлежит redhat
Делается следующим образом:
а. пишем данные в локальный файл в распределенной файловой системе
b. запускаем инстанс из сохраненного образа и считаем все что нужно
c. тушим инстанс который занимался расчетом
Но как бывает со всем другим. лучшие практики не всегда применимы ко всем, множество приложений не дорастает до нагрузки когда кеш не справляется или когда логика инвалидации становится слишком сложной для поддержки. Поэтому кеширование так и популярно как быстрое решение проблем с узким местом в приложении. А понимание проблем которые это влечет приходит наааамного позже.
Крайне рекомендую посмотреть доклад Алексея Качаева про ZeroMQ для того чтоб понять что все это далеко не так просто как написать 3 строчки кода и что люди используют готовые сервера очередей не просто так: www.youtube.com/watch?v=d26LufnoQ4I