Комментарии 11
А вы с какой версии PHP перешли на KPHP?
Прочитал статью, но не нашёл ни ссылки на проект, ни названия. :)
Можете ссылкой поделиться?
P.S. - рад, что FFI вам оказался полезен.
Система BIPULSE https://bipulse.ru/
Без FFI фокус бы не получился, мы прорабатывали схему с прокси для БД. Но FFI вовремя подоспел
Я человек простой: вижу статью про KPHP - скидываю ссылку на чатик сообщества.
Автора статьи там уже вижу. ;)
Выглядит так, что минусов очень много - в статье описано много костылей, подводных камней и человекозатрат. Также система вошла, получается, в зависимость от проекта ВК, судьба которого чуть более туманна, чем mainline Zend engine (если ВК забросят проект, как в своё время Facebook забросил аналогичный HPHPc). Подойдёт разве что для проектов с числомолотилкой, т.к. бенчмарки показывают, что на стандартных фреймворках HHVM с JIT работает не производительнее PHP7/8 т.к. большая часть времени выполнения висит в ожидании I/O от БД. Но и тут вкрадываются сомнения - на всё про всё ушло полгода, очень большие затраты. В статье есть раздел "почему не Go", где парируется, что переписывать всё на новый язык - не вариант. Но ведь почему обязательно переписывать всё? Можно было найти hot paths и выделить в отдельный сервис на Go. Неужели проект на 99% состоит из hot paths? Скорей всего только небольшая часть кода нуждается в оптимизации. Возможно, это заняло бы меньше полугода с тем же результатом ("расчёт расписания"). Вы ведь, получается, как раз-таки целых полгода занимались переписыванием проекта на другой язык - он похож на PHP, но по факту это другой язык (PHP-подобный язык KPHP - подмножество со своими правилами и ограничениями). Выглядит так, что основной плюс - хорошая обфускация, но стоит ли она полгода разработки - неясно.
Тут не только ускорение было целью. Но еще и бизнесовая составляющая: закрыть исходники.
На VC вторая часть статьи про бизнесовый контекст.
https://vc.ru/services/526585-kak-my-oblachnyy-php-servis-zavernuli-v-korobku-s-zashchitoy-licenziey-i-pri-etom-uskorilis
по поднятым вопросам:
1. система вошла, получается, в зависимость от проекта ВК,
а) ВК на нем очень устойчиво развивается и работает.
б) Мы конечно сделали клон себе на гитхаб и затянули локально, так как залезли внутрь.
Поэтому даже если ВК по каким-то причинам остановит работу, код уже ушел. Текущего синтаксиса PHP 7.4 хватает для наших задач.
2. большая часть времени выполнения висит в ожидании I/O от БД.
Это верно, но в движке KPHP есть возможности кеширования в памяти (даже между воркерами), поэтому часть операций мы не выполняем если можно что-то не выполнять.
Если говорить о числодробилке, то её мы ускорили, но не достаточно как хотелось бы, и будем делать следующую версию чтобы вычисления при корректировке расписания проектов не ходили в БДс совсем.
3 Выглядит так, что основной плюс - хорошая обфускация, но стоит ли она полгода разработки - неясно.
а) Ну если назвать обфускацией перевод в машинные коды, то да. Но тут выгода в том, что можно накрыть защитой типа Guardant (правда при первом пуске он сломался) и сделать нормальную лицензию.
б) Развертывание теперь делается проще и без ошибок
в) Проверка типов выполняется при сборке, а значит тоже меньше ошибок.
Итог по всем пунктам: за это стоило биться полгода.
Вы ведь, получается, как раз-таки целых полгода занимались переписыванием проекта на другой язык - он похож на PHP, но по факту это другой язык
Даже если что-то и случиться с KPHP, то код будет спокойно запускаться на PHP.
Я бы сказал, что эти полгода были рефакторингом проекта, а KPHP был линтером, который помогал в этом :)
Спасибо. Чтение одновременно захватывающее и обескураживающее. Мне кажется, на КПДВ прекрасно подошел бы шеврон "Слабоумие и отвага" :)
С одной стороны, подвиг уровня геракловых. Плюс, как положительный сайд-эффект, удалось значительно подтянуть качество кода, а в других условиях выбить из бизнеса ресурсы на рефакторинг было бы куда сложнее. Но количество встретившихся проблем поражает воображение. А целеустремлённость в их решении — так и просто благоговение!
У нашей команды есть девиз: Когда нельзя, но очень хочется, то можно. Потому что бизнес диктует одно, а технологии определяют другое. приходится вертеться.
Но такой большой рефакторинг у нас не первый, предыдущей была миграция с XSLT на JS/React - там пришлось реализовать свою версию XSL для JS-объектов чтобы сохранить гибкость интерфейса.
Как мы наш большой проект на KPHP мигрировали