https://github.com/sonata-project/SonataAdminBundle/blob/3.x/UPGRADE-3.0.md

Это-то понятно.

Ну я понял, что мне на 3.0 надо обновлять.

В общем, боль и унижение начинаются.

зато после обновления будет радостно и хорошо)

мне благо не пришлось сонату обновлять

Это да. Хоть до PHP 7 наконец-то проект апну.

Дальше будет ещё больше боли, когда надо будет до Symfony 3.2 обновиться. Сейчас 2.7 + куууууууууууча кастомных формотипов с адовыми костылями.

в мире пхп щас чудесное время. можно быстро фильтровать проекты при поиске работы

юзают 7ку и 3 симфони - значит все гут

Когда ищешь - да.

если 5 и 2.. то стоит задуматься)

Я сейчас работаю на не самом плохом (несмотря на выше написанное) проекте, который как раз привожу к более адекватному виду, чем он был. Поэтому офферы со всяким легаси и не принимаю. Тут интереснее, хоть и некоторое сношение мозга с не самым хорошим наследием. Но когда можно это рефакторить - это приятно.

по некоторым причинам могут не давать обновиться(есть более важные задачи и прочий бред)

Угу. А здесь вот в прошлом году запланировали и начали обновляться после НГ.

ну ладно на симфони 3 обновляться надо, а на 7 версию пхп то что обновляться

у нас были недочеты в 2 местах, поправили за час, и все

ну ладно на симфони 3 обновляться надо, а на 7 версию пхп то что обновляться

Хе-хе.

учитывая что пхп 7.0 вышел аж в 2015, а сейчас 2017...

Если бы все проекты писались со взглядом в будущее - это бы имело значение :)

мы долго не обновлялись из-за монги

а потом забили и заюзали адаптер

Мы тоже. Но монгоадаптер, вроде, норм работает. Так что вот тоже уползём.

вот, монга кстати единственная причина что действительно могло задержать переход

точней даже не сама монга, а то что не все переключились на новую версию драйвера

там уже активно работают над новой версией одм, без адаптера

Пользуясь случаем порекомендую тулзу от бывшего коллеги: https://github.com/sstalle/php7cc

там уже активно работают над новой версией одм, без адаптера

Ага, помню. В том тикете, где адаптер советовали писали, что в новой версии будет нативно работать.

ну новую версию только недавно начали пилить

https://twitter.com/alcaeus/status/816591589933981696 4го января

Хе-хе.

О хорошая новость

кстати о 7ке. в ней хдебаг до сих пор странно работает

во многие места не пускает, часто падает на элементарщине

к примеру если пытаешься обратиться к приватным полям родительского класса - он говорит хрен, а раньше работало

Тут из восстановления гитлаба шоу устроили :) https://www.youtube.com/watch?v=nc0hPGerSd4

рельсы и го

что может быть хуже?

пхп и го?

о кстати. кто чем ловит мемори лики?

на пхп

ну вот скажем есть у тебя консьюмер очереди кролика

который висит неделями, и на каждую итерацию потребление памяти растет на 10кб скажем

как вычисляете места где течет память?

вопрос актуальный

пока выходит только через blackfire sdk делать снепшоты каждые 10 итераций скажем и потом их сравнивать и брутфорсом пошагово до и после каждой операции memory_get_usage(true)

может кто знает как можно сделать хипдамп?

ну вот скажем есть у тебя консьюмер очереди кролика

Иногда дешевле просто сделать перезапуск воркеров каждый день или по достижению какого-то порога в памяти.

дешевле чем что?

Это PHP, тут утечки в порядке вещей, потому искать их достаточно сложно.

дешевле чем что?

Дешевле чем искать утечку и угрохать туда кучу времени

ПОтому что время == деньги

В нашем проекте искать утечки было вообще бессмысленно, потому что в долгоживущем воркере приложение текло как... не важно...

Сказать воркеру останавливаться после 10000 циклов, например. И поддерживать пул через какой-нибудь supervisord?

Алексей, да

Ну есть ещё один способ, чуть более сложный

И чуть менее очевидный и вообще

Так вот, у нас Zend1, Doctrine1.. А асинхронно обрабатывать задачи надо. Пришлось писать на pcntl_fork()

омг, привет из прошлого

вспоминаю 2010й

рестарт воркера не решение проблемы

Ну в 2010-м то было нормально.. Именно тогда проект и начался

ERROR: S client not available

Это зависит от твоей проблемы

ну если там не совсем жесткая течь

у нас пхп тёк как-то давно, всё никак не могли понять, я грешил на пхп вообще, потому что ну это же пхп. Ну и было это на пхп 5.2, тогда fpm поднимался ещё только через костыли. В итоге нашли какой-то там профайлер и выяснили что тёк вообще экстеншен к пхп, а тот корявый код на пхп на самом деле не тёк. Да и вообще после 5.3 текучесть пхп - миф, имхо

текучесть не миф, а результат кривых рук

сам пхп не течет

ну если хоть маленько понимать что делаешь, то уже можно этого избежать

Это PHP, тут утечки в порядке вещей, потому искать их достаточно сложно.

не в порядке

кстати последнюю течь нашел в symfony forms. видимо никто кроме меня их не юзал в воркерах, бгг

в целом у меня пока были только очень тупые проблемы с ликами

так что сильно дебажить пока не приходилось

пока для меня самая большая проблема с памятью это доктрина

не

с доктриной все просто и очевидно

-e prod —no-debug

и em->clear() после итерации

не в порядке

Ну я согласен, если код только твой. Но победить течь в Doctrine1 у меня не получилось

логгеры могут по-дефолту подтекать, типа buffered

да этот clear чистит либо слишком много, либо мало

если указывать $em->clear($post), то он недоочищает, если $em->clear(), то вообще всё

логгеры могут по-дефолту подтекать, типа buffered

у монолога надо тоже flush делать

именно с доктриной у нас все в порядке

если указывать $em->clear($post), то он недоочищает, если $em->clear(), то вообще всё

так надо полностью чистить

это ж не кэш какой-то

это unit-of-work

у монолога надо тоже flush делать

всякие cross-finger которые срабатывают только во время ошибок

одна итерация = один unit of work

еще если юзать адаптер для кеша array

так надо полностью чистить

давай я расскажу подробнее

давай я расскажу подробнее

да мне не особо интересно) один агрегат сущностей = одна бизнес транзакция = один unit of work

а это значит надо чистить ВСЕ