хабраиндекс
72,64
22 июля 2013 в 13:56

О kPHP: как котята ускоряют ВКонтакте

Привет, хабровчане. Про kPHP от ВКонтакте уже многие успели прочитать и в прошлом топике, и где-то ещё, но деталей, конечно, пока было мало. Для удовлетворения собственного любопытства и интереса со стороны сообщества, мы обратились за комментариями к первоисточнику, то есть Павлу Дурову, который порекомендовал мне поговорить о kPHP с ребятами из команды — Олегом Илларионовым и Василием Бабичем, которые отвечали за перенос ВК на рельсы свежей разработки.

Первым делом я задал те вопросы, которые звучали в комментариях к анонсу: что с ООП, кто быстрее — слон или кит Java C# Go или kPHP, в каких проектах kPHP будет наиболее полезен и так далее. Кроме того, мы поговорили о планах развития и, немного, о других разработках и «кодовой» кухне ВК.

Олег, Василий, привет. Итак, что же такое kPHP? В чём его суть?

Олег Илларионов:

Привет! kPHP — транслятор PHP в С++, который, в том числе, анализирует код, выводит типы переменных, а там, где однозначно вывести не удалось — использует универсальные переменные, в которых могут храниться данные любого типа.
Конечно, kPHP это не штука которая скомпилирует любой PHP-код и он будет работать — на деле kphp очень хороший статический анализатор кода, который находит ошибки, как потенциальные так и фактические. Кстати, при переводе сайта (речь идёт о ВКонтакте) даже было запущено несколько небольших нововведений, которые были сделаны давно, но из-за багов в коде не стали доступны широкой публике.

Много вопросов связано как с поддержкой основных методов PHP, так и с ООП. Кроме уже озвученного — как о стандарте, так и об ограниченной поддержке ООП, можете что-то добавить?

ОИ:
В kPHP Есть огромная масса всего, даже вещи которые мы (ВКонтакте) не используем, но пока что нет некоторых очень серьезных штук — например, DOMDocument.
Что касается ООП, то на данный момент оно в kPHP не поддерживается, за исключением нескольких стандартных объектов PHP. Одной из задач при переводе сайта на kPHP было полное избавление от ООП. Но это отсутствие было сделано скорее как фича, основным вектором при разработке kPHP была скорость, Это играет не в пользу поддержки ООП и, кроме того, ООП хорош в первую очередь тогда, когда у вас на проекте есть сотня разработчиков либо в нём обилие интерфейсов.

В комментариях прозвучал классический вопрос: «быстрее ли kPHP чем Java C# Go»?

ОИ:
Зависит от того, что именно тестировать и от того, как написать код. С kPHP очень интересно: например, скорость зависит от того, как именно он выведет тип отдельных переменных. Вообще, kPHP планировался как несовместимый с PHP язык, там есть ряд конструкций, которые, например, позволяют явно задавать типы переменных, чтобы ускорить выполнение. Но из-за того, что у нас много кода (скомпилированный бинарник весит около 300 мегабайт), компиляция занимает не считанные секунды, как планировалось, а минуты — несмотря на то, что kPHP перекомпилирует только изменившуюся часть кода — приходится разрабатывать фичи на обычном PHP, и это пока что не позволяет нам использовать все преимущества.

Василий Бабич:
Сравнение с Java C# Go сложное — скорость kPHP, как уже отметил Олег, очень зависит от кода, который им компилируют — если он хороший, то скорость работы сильно выше, чем у Java / C# — фактически, это чистый С++. А вот если код не очень хороший, то работает помедленнее. Наверное, если очень постараться, то можно придумать синтетический пример, где код аналогичный, но kPHP работает медленнее — но мы такой целью не задавались :)

Мы уже видели красивые графики ускорения загрузки основных страниц ВКонтакте благодаря переходу на kPHP. А какие ещё выгоды может принести использование kPHP?

ОИ:
Существенное преимущество в использовании памяти.

ВБ:
Да, с kPHP значительно меньше использование процессора и оперативной памяти. Насколько я знаю, мы стали использовать почти в два раза меньше серверов для обработки запросов, при том, что они занимаются не только этим — на них еще какие-то системы иногда работают, вроде memcache. Конечно, kPHP в первую очередь предназначен для highload-проектов, что не удивительно, учитывая те задачи, для решения которых мы ведём его разработку.

Некоторые хабровчане критически отнеслись к двойному приросту скорости ВКонтакте, указывая на то, что ускорение в 10 раз было бы, конечно, намного более впечатляющим результатом. Так что, в 2 раза всего?

ОИ:
Нужно понимать, что факт ускорения сайта в 2 раза не значит, что kPHP быстрее PHP в два раза, это не так. Дело в том, что помимо выполнения кода очень существенная часть времени тратится на обращения к базам, движкам и так далее. Думаю, само выполнение кода ускорилось более чем в 10 раз.
И ещё по поводу скорости: в kPHP встроен веб-сервер, то есть, в комбинации с ним не нужен Apache.

ВБ:
Да, большую часть времени генерации страницы сейчас занимает не исполнение PHP-кода, а ожидание ответа на запросы за данными (к другим серверам). Конечно, мы стараемся это время ожидания как-то использовать, но реально получается, что ожидания всё равно очень много, его kPHP не ускоряет. Как и сказал Олег, фактический рост скорости значительно выше.

Олег, ты упомянул базы и в этой связи вопрос про них: используете собственные наработки или что-то стандартно-допиленное?

ОИ:
Сейчас мы практически не используем MySQL, разве что только там, где небольшие нагрузки и пока не дошли руки перенести на собственные движки. Там, где данных хранится много они используются уже давно. Их написано гигантское множество, теперь уже сложно представить задачу с которой нельзя справиться без MySQL.
Вообще, целый ряд наших стандартных функций, которые мы предсмотрительно вынесли в отдельную библиотеку, реализованы на C++.
Правда, это решение мы использовали и до kPHP — как известно, в PHP тоже можно добавлять новые функции, написанные на C.

А есть ли в планах ускорение или (вдруг!) раскрытие движков для общественности?

ВБ:
Те, которые написаны нашими ребятами (вместо MySQL) и работают по memcache-протоколу уже достаточно сильно ускорены. Однако, этот протокол не позволяет ускорить всё настолько, насколько мы могли бы. Поэтому мы постепенно уходим от memcache-протокола к своему собственному, который похож на mtproto, описанный в конкурсе для Android — но для серверной стороны (для общения между серверами, отвечающими на запрос и серверами с данными).
Про открытие общественности — да, мы планировали движки на memcache-протоколе открывать, но пока не дошли руки.

Возвращаясь к kPHP, какие у вас планы по его развитию и поддержке? Будете пилить или отдадите на откуп сообществу?

ОИ:
Из ближайшего — ребята планируют добавить ООП, так как если мы захотим встроить mtproto, разработчикам оно понадобится.

Спасибо! И, напоследок, самый главный вопрос: что же такое k?

ВБ:
K — это префикс от слова kitten, которое уже стало традицией в разработках наших ребят :)




Вот такое kPHP-интервью у нас получилось, Хабр, спасибо за то, что прочитали эту стену текста без единой картинки. Чтобы сгладить эту неловкость, добавлю в топик немного префикса:

image

Ну и, конечно же, если будут вопросы по теме, Roem.ru с удовольствием расспросит ребят о других интересующих сообщество деталях.
+89
64034
85
Teodorix 20,9

Комментарии (88)

+24
abiruba, #
О, как.
>Одной из задач при переводе сайта на kPHP было полное избавление от ООП.
+36
nazarpc, #
А потом:
Из ближайшего — ребята планируют добавить ООП
–7
Dialog, #
А не проще ли было ребятам на пхп 4.0 откатиться?
+4
mannaro, #
Скорость же?
+4
Teodorix, #
А вот и ответ подоспел:
В ВК ООП-подход почти не использовался — так что избавление от него было нужно, чтобы весь код был в едином стиле и уже работал на kPHP. Поддержка ООП понадобится уже позже, на нужном нам этапе — для удобной работы с TL, например).
То есть, в данный момент ее нет. А сайт есть :)

TL — это схема типов из обсуждаемого будущего протокола.
+1
gefix, #
скомпилированный бинарник весит около 300 мегабайт

А сколько, интересно, тогда исходных кодов? Или это вместе со сторонними библиотеками?
+2
mannaro, #
Хм… Вы думаете, они используют сторонние библиотеки?
0
JustLuckyGuy, #
Вы думаете, они писали веб-сервер (который входит в kPHP) с 0 сами?
+1
WaveCut, #
А почему бы и нет, если то позволяют ресурсы?
0
akalend, #
зачем? есть куча готовых либ, реализующих HTTP сервер, libevent например
+4
DarkByte, #
Комментарий от самого Павла:
К сожалению, никто из «знатоков» технологии HipHop не пробовал скомпилировать в нем хотя бы Hello world. Иначе вопрос «а зачем, уже есть» у них не возник бы.
+5
AndrewStephanoff, #
Не Hello World, но всё же Getting WordPress running on HHVM
+13
DLag, #
Ну я собирал, и статей достаточно в интернет об этом.
Или у Дурова все за пределами VK под запретом?
+11
abiruba, #
Во vk лочат другие сайты. Так vk мстит за то, что в других компаниях лочат доступ к vk.
+1
DoctorChaos, #
у меня в субботу Yii завелся на Hip Hop VM
0
xRay, #
Опишите порядок действий. Было бы интересно Drupal на Hip Hop VM завести.
+4
DoctorChaos, #
я пошел самым простым путем, был интересен сам факт: заведется или нет.
взял сервер в облаке на ubuntu 12.04 x64 (перед этим попробовал centos и debian, на них возникли проблемы, которые мне было лень решать))
поставил pre-built package по инструкции с github.com/facebook/hiphop-php/wiki/Prebuilt-Packages-on-Ubuntu-12.04
достал из гита yii, положил в /home/yii
создал webapp в /home/yii/test
составил конфиг для hiphop, файл config.hdf:
Скрытый текст
Server {
Host = domain.com
IP = 0.0.0.0
Port = 80
ThreadCount = 50

SourceRoot = /home/yii/test
}

Eval {
Jit = true
}


запустил hiphop:
[root@server] ~# hhvm -m daemon -c config.hdf

перешел по адресу domain.com/index.php — работает)
вроде бы ничего не забыл.
0
DoctorChaos, #
плюс, потом потестил eval, магию, пару особенностей php 5.4 — всё работало.
+1
kapitansky, #
Молодца =)

Я под debian 6 зимой HHVM настраивал) Главное было MySQL 5.5 завести на нём. Было стрёмно (ибо прод и я не гуру админ), но всё получилось)
+1
kapitansky, #
Самое интересное, что для HHVM ничего компилить не надо) «Hello world» заводится с «полпинка»)
+10
alesto, #
То неловкое чувство когда твой комментарий задали как вопрос разработчикам )))
+1
Dreammaker, #
В моем случае — то неловкое чувство, когда твоя ирония оказалась реальностью :)
–4
shagguboy, #
а еще через пару лет они напишут свой JIT компилятор. и назовут его kHIPHOP
+2
alhimik45, #
… и назовут его kIPkOP
+18
shagguboy, #
у меня такое чувство что они просто обнаружили в хипхоп фатальный недостаток — его написали не они.
+17
Teodorix, #
у меня такое чувство, что вас мучает фатальный недостаток — вы не с ними.
+3
EugeneOZ, #
«основным вектором при разработке kPHP была скорость»
всего в 2 раза?..

«но реально получается, что ожидания всё равно очень много, его kPHP не ускоряет»
фанаты print vs echo раскупорили текилу с горя.

«то скорость работы сильно выше, чем у Java / C# — фактически, это чистый С++»
долгий холивар «C++ VS Java» для них уже давно решён )

«перенести на собственные движки. [...] Их написано гигантское множество»
«уходим от memcache-протокола к своему собственному»
«в kPHP встроен веб-сервер»
«kPHP это не штука которая скомпилирует любой PHP-код и он будет работать»

— всё это несомненно поможет тому, чтобы в кодовой базе было «проще» разобраться и (не)использовать решения кого-то ещё на этой планете.

+38
shagguboy, #
уходим от memcache-протокола к своему собственному

обнаружили в мемкеше фатальный недостаток — его написали не они
+1
tangro, #
Они транслируют PHP в С++, у них есть куча базовых функций, написанных на С++. Я понимаю ответ на вопрос «а почему бы сразу всё не писать на С++» — потому что долго. Но почему бы не писать всё на PHP, держа параллельно команду в пару десятков С++ программистов, которая бы переписывала постепенно каждую имеющуюся страничку на С++. Это ведь не сложно — имея код на PHP, зная требуемый вход и выход — переписать то же самое на С++. Переписали одну страничку — подменили, переписали вторую — подменили. Обновился код на PHP? Ок, используем PHP, пока не дойдут руки обновить С++ версию. Это всё легко может подменяться\деплоиться автоматом, так что ни PHP ни С++ программеры не будут думать «а что там за версия сейчас будет работать?». Код ведь будет явно быстрее и лучше, чем этот KPHP сделает.
+27
nifus, #
И ещё одну команду которая будет с с++ на ассемблер переписывать.
+15
ivlis, #
Транслятор c++ в машинные коды, так как у gcc, clang и msvc есть общий фатальный недостаток… :)
+6
pa3ot, #
У машинных кодов есть один серьезный фатальный недостаток… ;)
0
XimikS, #
Осталось поспорить с законами физики!
0
Chamie, #
Вы пропустили этап собственной процессорной архитектуры, т.к. x86 тоже обладает фатальным недостатком.
+7
Goodkat, #
Но почему бы не писать всё на PHP, держа параллельно команду в пару десятков С++ программистов, которая бы переписывала постепенно каждую имеющуюся страничку на С++.
Дык может они и наняли команду в пару десятков С++-программистов, которые постепенно переписывали каждую имеющуюся страничку, а потом заколебались и процесс автоматизировали, а результат назвали kPHP? :)
0
leventov, #
Проблема в том, что практически весь сайт — это единое целое, из-за уведомлений, инлайн-чатов и синхронизации проигрывателей. Так по одной не перепишешь.
+2
tangro, #
Да ладно, ну какое «единое целое». Каждый запрос (браузера или аякса) — входит в какую-то одну точку, эта точка выполняет какой-то свой код, для всех точек разный. Ничего там сбитого в цельный кусок нет, я уверен.
0
leventov, #
Вы правы, аудио через куки, похоже, синхронизируется.
0
Utter_step, #
Через localstorage, насколько я помню.
0
Utter_step, #
habrahabr.ru/post/153937/

Хотя тут нету никаких ссылок на источники.
0
Shadez, #
Ибо датамайнилось вручную
+4
sphinks, #
какой то трешак получается, подо все свой велосипед.
+1
Teodorix, #
Мое личное мнение: одно универсальное решение не будет лучше общей базы, которая допиливается под себя и, в свою очередь, становится базой кому-то другому.
Я бы себе велосипед, например, напечатал, если бы умел и были технологии .)
+5
sinodov, #
Тут история скорее про то, что люди, которые катаются на тротуарчиках в городе, дают совет «не изобретай велосипед» тем, кто на нём штурмует Эверест.
А им-то как раз изобретать велосипед надо.
+2
gleb_kudr, #
Если религия не позволяет залететь на вертолете — то однозначно.
+1
restyler, #
Вертолет не может залететь на Эверест. Только на один из лагерей снизу, а на сам пик — только ножками. Недаром там столько трупов лежат — их не могут снять
0
gleb_kudr, #
Хоть это и не имеет отношения к посту, но я немножко в теме ;) Рекордные подскоки на Эверест у вертолетов были. Прям как в обсуждаемой статье :)
+11
DarkestMaster, #
Кстати, про котят. Во времена фидо (12-13 лет назад) Андрей Лопатин ( 2:5030/744@fidonet ) написал альтернативный и достаточно популярный мейлер KittenMail, а на всяких чемпионатах по программированию его команда называлась Kitten Computing. Сейчас Лопатин, насколько я знаю, имеет непосредственное отношение к девелоперам контакта, поэтому с очень большой вероятностью именно он — источник котят в PHP :)
+1
terrance, #
даже адрес его страницы в vk говорит об этом)
0
unStaiL, #
Взглянуть бы на релизную версию и документацию.
–1
AHrEJI, #
Интересно, почему все сравнивают только с HipHop… а как же phalcon?
+1
lol2Fast4U, #
Потому что HipHop — новый компилятор/VM, как и kPHP, а phalcon — фреймворк.

Сравнивать kPHP с phalcon – это как сравнивать Rubinius с Sinatra или PyPy с Flask.
–1
kapitansky, #
Прирост в 10 раз?

Я уже говорил, что по приведённым графикам судить о приросте производительности очень сложно. Видно, что он есть, но какой конкретно — неизвестно, тк мы не знаем что и в каком соотношении лопало время.

Бегло прикинул прирост отталкиваясь от предположения, что php у них кушал 70-75% времени:
0,25 — 100%
0,1875 — 75% // PHP

другие расходы: 0,0625

С KPHP:
0,12 — 100%
0,12 — 0,0625 = 0,0575
0,0575 — 30% // KPHP

Исходя из этих примитивных расчётов можно сделать предположение о приблизительно 70% приросте производительности со стороны php (то, что раньше делал php сейчас делается на 70% быстрее).
–3
guessss_who, #
kPHP, HipHop — ну как, как тут не вспомнить про мышей и кактусы? :)
+11
bolk, #
Никак не вспомнить, у нас тут не Аншлаг, а айтишный ресурс. Люди пытаются найти оптимум между скоростью и дешевизной разработки (ПХП) и скоростью работы (Cи++). Такие попытки двигают прогресс. А очередной коммент про мышей и кактусы просто увеличивает энтропию.
+19
guessss_who, #
— Шеф, наша лошадь уже не тянет телегу, та стала слишком тяжелой. Давайте избавимся от лошади, приделаем к телеге дизельный двигатель, алюминиевую раму и поставим резиновые колеса, это позволит без напрягов двигаться с увеличенным грузом и при этом со скоростью, недостижимой для лошади!
— Что за глупости! На нас равняются любители лошадей всего мира и всегда ставят в пример! Давайте лучше напишем свой PHP без ООП включим в рацон лошади вкусные стероиды, к морде приделаем систему наддува чистого кислорода в легкие, а по венам пустим MDMA. Ведь ямщики обходятся гораздо дешевле тех чуваков, которые умеют управляться с дизелем.


Сейчас мне хорошо присунут в карму, но я почему-то вижу упомянутые вами «оптимум» и «прогресс» именно так.
–5
bolk, #
Опять вы петросяните… сколько можно.
+9
guessss_who, #
Не нравится мое чувство юмора? OK, шутки в сторону. Давайте поговорим серьезно.

Мое мнение — для ВКонтакте и Facebook PHP был неудачным выбором. Ошибкой, которая с каждым днем обходится всё дороже. Мне сложно оценить в деньгах, сколько стоит разработка вещей типа HipHop/kPHP, но я не верю, что слово «дешевизна» является уместным, когда дело обретает такой оборот. Также непонятно, о какой дешевизне разработки идет речь, когда на непойми чем (урезанный PHP без возможностей ООП, остаются только процедуры?..) надо писать современную социальную сеть.

Кстати, а есть в индустрии еще примеры подобного подхода? Когда кто-то так привязывался к любимому ЯП, что писал его компилятор в С++, чтобы решить проблемы с быстродействием.
+2
bolk, #
Я уверен, что ни Фейсбук, ни ВК не знали будут ли они популярны. Монументальность хорошо для проектов, которые гарантировано дадут доход, а когда нужен быстрый и дешёвый старт, стали бы вы выбирать Cи++?
Кстати, а есть в индустрии еще примеры подобного подхода? Когда кто-то так привязывался к любимому ЯП, что писал его компилятор в С++, чтобы решить проблемы с быстродействием.

Конечно да.

Например:
ru.wikipedia.org/wiki/Cython
search.cpan.org/~nwclark/perl-5.8.9/utils/perlcc.PL

Наверное что-то ещё есть, про эти два я просто знаю. Можно поискать что-то у Руби, у других языков.
+2
guessss_who, #
Насколько я в курсе, Cython используется в основном для разработки быстрых модулей для Python, ну и оба приведенных примера вроде не являются плодом отчаянной попытки вытянуть быстродействие какого-то конкретного проекта на «оригинальном» языке.
0
guessss_who, #
…честно говоря, где-то в глубине души я понимаю, что эти решения — результат труда умных людей. Которые умеют писать хороший код, рулить огромными проектами и считать деньги. Но все равно не покидает ощущение, что что-то не так.

Искренне интересно, насколько далеко это всё зайдет. Лет через 5, насколько большой будет разница между PHP «от фейсбука» и PHP «от вконтакта». И не станем ли мы свидетелями перехода одного или обоих этих проектов на ЯП, не имеющие с PHP вообще ничего общего. :)
+7
kapitansky, #
Скажу пару слов в поддержку ВК, хотя я как и Вы достаточно сильно убеждён в том, что для каждой задачи есть наиболее оптимальный набор инструментов, которые позволяют её решать.

Вы все наверняка неоднократно слышали фразы вроде этой:

«Пишите на том, на чём умеете. Когда упрётесь в производительность у вас будут в распоряжении уже совсем другие ресурсы. А если не упрётесь или ресурсов не будет, то это признак того, что вы что-то делаете не так.»

или этой:

«Решайте проблемы по мере их поступления».

И вы знаете, я НЕ рискну спорить ни с одним из этих убеждений (если выбранный инструментарий не на грани абсурда или возможная проблема крайне очевидна и близка).

Более того, сам по себе PHP со многих сторон весьма не плох, если вы умеете его правильно готовить, а тех, кто умеет не так много (впрочем, как и везде). А вот тех, кто возомнил о себе (из-за низкого порога входа), что он умеет, в разы больше. Но сейчас не об этом.

ВК всегда придерживался позиции того, что если им что-то нужно — они это делают сами. Это их право, тем более, что теперь у них на это есть необходимые силы и ресурсы. Кроме того мы не видели ни одного тотального фейла из-за того, что они придерживаются этой позиции.

Почему не Java, C# или Go? Ответ на поверхности — в ВК, пожалуй, одни из лучших и опытнейших С/C++ и PHP разработчиков в Рунете (если не лучшие, ИМХО). Есть ли ВК специалисты по Java и C#? Да, по крайней мере разработчики мобильных аппов (например, Григорий Клюшников). Но сколько их? Человека 2-3 (могу ошибаться =) ). И навряд ли они обладают такими глубокими знаниями как ДОСТОПОЧТЕНЫЕ TheShade, Walrus, Филипп Дельгядо и другие гуру Java. Думаю, тут всё очевидно.

Лично для меня остался неразрешённым один вопрос — почему компилятор, а не VM? Ведь у неё, как мне кажется, гораздо более широкий набор возможностей для дальнейших оптимизаций. С другой стороны разработка VM, наверняка гораздо более трудоёмкая задача. Возможно сейчас, когда они уже экономят благодаря KPHP, ребята позволят себе разработку kotVM =)

З.Ы. ИМХО: Павел, воистину сумел создать сильнейшую команду, как по техническим знаниям, так и по сплочённости и целеустремлённости. Это заслуживает уважения.

0
guessss_who, #
См. выше.
+1
remal, #
Занимаюсь коммерческой разработкой и на PHP, и на Java. Также, экспериментирую дома с разными технологиями/языками, из недавнего — Erlang. Что такого сложного может быть в мире PHP, чтобы говорить о «одни из лучших и опытнейших разработчиков в Рунете»? PHP — простой и крайне ограниченный в возможностях язык. В глубину там обучаться просто некуда. Нет, я понимаю, что рынок PHP девелоперов перенасыщен бестолочами, которым вообще к реальному коду нельзя давать прикасаться, но как-то брать их в расчет некорректно, имхо.
+2
kapitansky, #
remal, вы, верно, хотели выпендриться?

Всегда, когда читаю комменты в таком стиле, мне хочется спросить: «а вы то, сами кто?»

Не хочу никого обидеть, но уж давайте на чистоту.

Я уже 4-ый год занимаюсь созданием крупных (DAU > 1 млн.) highload проектов на php. И уж сколько за это время я повидал таких коммерсантов, которые пишут и на PHP, и на Java, и на C, и на Erlang, и с Node.js работают, и на дуде с балалайками играют… А уж сколько знатоков различных баз данных встретил уууу… Знаете в чём прикол? 99% из них — «ни о чём. три раза.». Причём, как ни странно, «ни о чём» во всех перечисленных областях знаний…

Вы, наверное, думаете: «Я не такой. Я не такой. Я не такой. Они все такие. Они все такие. Они все такие, а Я не такой.».
Ну-ну, подумаем мы все…

Ну а теперь по делу:

На мой взгляд Highload, сам по себе, прост как и всё гениальное =)

Всё искусство заключается в знании как эффективно работать с огромными наборами данных, как быстро обрабатывать сотни тысяч и миллионы хитов в минуту, понимании того, что может привести к задержкам в обработке и падению. Надо уметь принимать правильные, эффективные решения, быстро распознавать и признавать ошибки и просчёты, учиться на своих и чужих ошибках, принимать меры по их сокращению =)

Если честно, не хочется разводить тут холиваров насчёт php и его ограниченнрости. Он хорош для быстрого решения узкого круга задач.

По поводу простоты — да, простой. Это плохо? А вы знаете сложный ЯП? =)

+1
kapitansky, #
А спроить по поводу огромнейшего опыта и знаний у ребят, работающих в ВК, я даже смысла не вижу. Если у вас есть желание порассуждайте хотя бы отталкиваясь от опыта) если с логикой дружны, то у вас всё получится)
0
VolCh, #
Вот как раз потому что он ограничен в возможностях и нужны знания и опыт чтобы находить нормальные способы обхода этих ограничений. Причем определения нормальности единого нет, для каждого проекта или даже для каждой стадии развития проекта они свои.
+10
Gepard_vvk, #
Может разработчикам просто скучно писать только сайт? (=
0
antarx, #
> в kPHP встроен веб-сервер

Это заметно: после ввода KPHP ответы апи стали терять последние байты, и периодически виснуть во время ответа на неограниченный срок, что для apache/fpm невозможно.

С другой стороны, хороший статический анализатор php-кода — это перспективно. Интересно, планируется ли на основе него сделать поиск потенциальных ошибок?
+14
gleb_kudr, #
Все верно. Java&co — для кровавого ынтырпрайза. А статический компилятор php — это стильно, модно, молодежно!
+6
Divers, #
Там же ООП выпилить нельзя, так что джава не подходит.
–2
OnoIt, #
Я люблю программирование за то, что в нем нет места тро-ло-ло, а есть код, который работает. Из интервью мы узнали, что Вконтакте обладают технологией ускорения PHP-кода, но ничего нового или интересного в этой технологии нет или журналист не смог узнать об этом.
–1
Teodorix, #
Хватанули .) Я не журналист, просто часто общаюсь с разными хорошими людьми.
Какие вопросы бы задали?
+2
OnoIt, #
Например, какие конструкции PHP не поддерживаются, можно ли самому указывать типы переменных в комментариях определенного вида,.

Можно попросить небольшие куски кода PHP и их транслированные эквиваленты на C++ с комментариями: вот здесь kPHP смог определить тип переменных и получился быстрый код, а здесь нет. Наверняка у разработчиков есть тесты, там вряд ли есть коммерческие секреты.

В общем, больше деталей для программистов.
0
Teodorix, #
Окей .)
0
VolCh, #
Я узнал больше. VK разработали PHP-подобный язык (не подмножество, не надмножество, а пересекающиеся множества) и написали компилятор его в C++.
+1
Nail, #
Представляю, какой когнитивный диссонанс сейчас испытывают фанаты ООП и ненавистники PHP.
А если еще эти два качества складываются…
Впрочем по комментам видно.
0
BlessMaster, #
Фанаты ООП с чего должны испытывать то негативные чувства? ООП обещан и заявлен как нужный ;-)
0
VolCh, #
Сейчас-то нет. Значит не так уж он самому VK нужен.
0
BlessMaster, #
Ну, я тоже когда-то без ООП писал — жить можно, хоть и с ростом проекта, если не найти способ «разделять и властвовать» становится неудобно ))
Но ок, совсем фанатики всегда найдут повод расстроиться )))
+16
leventov, #
Из интервью сложилось впечатление, что у них там творится какой-то ад.
0
WaveCut, #
Это хорошо, или плохо?
+3
guessss_who, #
За этим интересно наблюдать со стороны.
+2
begezavr, #
Ну, если судить по результатам (продукту), то, по-крайней мере, неплохо. Сайт то вконтакта, несмотря на все свои нагрузки проворен, быстр и часто обновляется новыми фичами.
–2
Aco, #
Забавно, только недавно хотел вернуться к своему давнему проекту, который интерпретирует любую PHP либу в си, так что бы можно было собрать расширение для PHP в виде SO файла. Все распланировал, продумал и даже придумал как быть с yield в сях. Однако теперь и не знаю, стоит-ли дальше развивать проект?
–1
Grox, #
Почему бы и да?
+1
DiverUA, #
Даешь транслятор из PHP в VHDL!!!
+1
zencd, #
VM более перспективны чем статическая компиляция. И задача джит-компиляции на порядок сложнее и интереснее чем «сгенерить с++ и оставить все оптимизации за ним» (примерная цитата разработчика вк). Так что хвастать вконтакту здесь особо и нечем. А оптимизировать пхп несложно — такой вот он неэффективный с родения

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.