хабраиндекс
88,17
6 марта в 18:49

Релиз KPHP и движков

Довольно часто, выступая на различных конференциях, мы делились желанием выпустить под открытой лицензией KittenPHP, согласно традиции, заложенной крупными IT-компаниями, такими как Google и Facebook.

Это событие несколько раз откладывалось в связи с опасением, что нам не хватит сил и времени на взаимодействие с opensource-сообществом, однако в конце концов заветный день настал, и код KPHP и некоторых других инструментов, используемых внутри проекта, был выложен в открытый доступ.

В связи с этим под катом вас ждет более подробный рассказ о внутреннем устройстве ВКонтакте и тех инструментах, которые сегодня стали доступны opensource-сообществу.




Исходные коды были выложены под лицензиями GNU (GPL и LGPL). Данные лицензии близки нам идеологически, так как при создании этих библиотек мы часто использовали инструменты, лицензированные именно GNU.

KPHP

Исходный код ВКонтакте разрабатывается на PHP-подобном языке, названном KittenPHP или коротко KPHP. Этот код транслируется в C++ специальным транслятором с одноименным названием. После этого сгенерированный C++ код автоматически компилируется средствами gcc, в результате чего получается бинарник, готовый для запуска. Этот бинарник представляет собой веб-сервер, принимающий http-запросы и генерирующий страницы.
Для того чтобы ускорить процесс разработки, KPHP компилирует различные файлы проекта отдельно, после чего линкует. При последующих компиляциях обрабатываются только измененные файлы, либо, в случае больших по размеру файлов, только их части.

KPHP – минималистичный язык, созданный с целью обеспечить очень высокую скорость работы, без ущерба для удобства и скорости разработки. В связи с этим KPHP поддерживает не все возможности PHP, в частности, в нем отсутствует ООП, за исключением некоторых объектов стандартной библиотеки. Кроме этого не поддерживается eval и связанные с ним вещи, такие как регулярные выражения с модификатором 'e' (вместо этого предлагается использовать функцию preg_replace_callback). Также не поддерживаются функции для работы с определенными элементами массивов first, end, next, prev, current, reset, key; для их замены реализованы функции getValueByPos и getKeyByPos.
Отказ от поддержки большого количества функционала позволил KPHP стать невероятно быстрым по сравнению с другими средствами для веб-разработки.
В качестве примера мы сравнили его с разработанным в Facebook HipHop VM и получили следующие результаты:
Тесты KPHP HHVM PHP
simple 0.000 0.007 0.137
simplecall 0.000 0.004 0.174
simpleucall 0.007 0.008 0.178
simpleudcall 0.007 0.009 0.181
mandel 0.010 0.066 0.392
mandel2 0.011 0.074 0.355
ackermann(7) 0.001 0.011 0.189
ary(50000) 0.003 0.008 0.024
ary2(50000) 0.003 0.010 0.022
ary3(2000) 0.011 0.077 0.191
fibo(30) 0.003 0.019 0.481
hash1(50000) 0.018 0.034 0.044
hash2(500) 0.011 0.021 0.039
heapsort(20000) 0.012 0.040 0.101
matrix(20) 0.007 0.021 0.121
nestedloop(12) 0.000 0.012 0.235
sieve(30) 0.013 0.016 0.114
strcat(200000) 0.002 0.005 0.014
Результаты 0.119 0.442 2.992


Код тестов доступен по ссылке:
gist.github.com/anonymous/9391146#file-bench-php

С точки зрения разработки, KPHP достаточно совместим с PHP, чтобы для быстрого тестирования написанного кода можно было использовать обычный PHP, а компилировать код только перед финальным тестированием и выкатыванием проекта. Для поддержки функций, реализованных в KPHP, но отсутствующих в обычном PHP, была выложена специальная библиотека github.com/vk-com/kphp-kdb/tree/master/vkext, расширяющая возможности PHP.

Кроме того, KittenPHP является хорошим статическим анализатором PHP-кода, указывающим на вероятные ошибки. Например, в процессе перевода ВКонтакте на него год назад было найдено более 20 серьезных багов.

Вместе с компилятором под открытой лицензией разработчики выложили набор движков, которые отлично дополняют KPHP, но могут быть использованы и отдельно от него. Впервые мы анонсировали эти библиотеки opensource-сообществу на Highload 2010, так что просим прощения за достаточно долгий период ожидания.

PMemcached (“Persistent Memcached”)

Надежное key-value хранилище, позволяющее хранить данные без ограничения по времени. По протоколу MC движок работает идентично Memcache, за исключением того, что после перезагрузки все данные остаются.
Помимо своих основных функций, при включении соответствующей опции в конфигурации pmemcached позволяет получать сразу группы записей, у которых префикс ключа соответствует заданному в запросе.

Lists

Данный движок позволяет хранить и получать различные списки данных.
Одна копия движка может хранить набор списков. Каждый список должен иметь идентификатор (int), по которому с этим списком можно работать.
В каждом списке может быть неограниченное количество элементов. Каждый элемент также должен иметь идентификатор (int), значение (int), флаг (int) и может хранить произвольные 256 символов текста.
Кроме получения списков есть возможность получать подсписки, фильтруя по флагам и сортируя по значениям.

Документация: github.com/vk-com/kphp-kdb/blob/master/docs/ru/KittenDB_Lists.wiki

Lists-X

Модификация движка Lists, позволяющая использовать ключи и идентификаторы записей, состоящие не из одного числа (int), a из заранее заданного в конфигурации движка количества чисел (int). Например, это позволяет создавать списки, ключ которых формируется из идентификатора пользователя и идентификатора записи на его стене.

Документация: github.com/vk-com/kphp-kdb/blob/master/docs/ru/KittenDB_Lists-X.wiki

Search

Предназначен для поиска данных на сайте. Любая текстовая информация может быть проиндексирована в движке с определенным идентификатором, и впоследствии найдена по словам в тексте. В результатах поиска будут возвращены идентификаторы, указанные при индексировании.
Search поддерживает произвольные параметры для поиска по критериям, и специальные параметры для различных сортировок. Также движок позволяет осуществлять сложные группировки и пересечения.

Документация: github.com/vk-com/kphp-kdb/blob/master/docs/ru/KittenDB_Search.wiki

Storage

Движок создан для хранения пользовательских данных — фото, видео, аудио, документы. Благодаря хранению различного контента в одном файле и индексированию в памяти смещений, Storage справляется с этой задачей лучше, чем при использовании классического подхода с хранением отдельных файлов в файловой системе.

Документация: github.com/vk-com/kphp-kdb/blob/master/docs/ru/KittenDB_Storage.wiki

Texts

Движок Texts позволяет хранить различные текстовые массивы данных. Изначально он был разработан для системы личных сообщений ВКонтакте, но позднее был переиспользован для стен и для комментариев.
Помимо хранения текстов движок поддерживает различные группировки списков с текстами и поиск по текстам. Благодаря нему доступен моментальный поиск по всей личной переписке пользователя, сколь большой бы она не была.
Также в этот движок встроен HTTP сервер, реализующий long poll для получения обновлений с клиентской стороны. Однако позже для этой цели был создан отдельный движок queue, о котором написано ниже.

Документация: github.com/vk-com/kphp-kdb/blob/master/docs/ru/KittenDB_Texts.wiki

Hints

Hints решает две важные задачи:
1) Предназначен для поиска объектов пользователя по префиксам слов, используется при быстром поиске на сайте.
2) Позволяет формировать рейтинги объектов, с помощью которых можно упорядочивать списки объектов по степени интереса к ним у пользователя. Например, таким образом работает список друзей ВКонтакте.

Документация: github.com/vk-com/kphp-kdb/blob/master/docs/ru/KittenDB_Hints.wiki

Queue

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

Документация: github.com/vk-com/kphp-kdb/blob/master/docs/ru/KittenDB_Queue.wiki

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

Заключение

С помощью публикации этих разработок мы возвращаем долг open-source сообществу, которому многим обязаны. 

Мы надеемся, что теперь они помогут разрабатываемым сейчас проектам, как в своё время MySQL, Memcache, nginx и PHP помогли создать ВКонтакте.

Исходный код движков и KPHP Вы можете увидеть в репозитории на github: github.com/vk-com/kphp-kdb
Подробная документация расположена по адресу: github.com/vk-com/kphp-kdb/tree/master/docs/ru
+299
109830
643
Похожие публикации
Пиринговая сеть в видеоплеере 27 июля 2011 в 08:09
Видео от YouTube 13 октября 2010 в 15:57
Виджеты для сторонних сайтов 29 сентября 2010 в 20:04
Прецедент 22 июля 2010 в 15:53
Открытое тестирование XMPP 13 июля 2010 в 16:03
Подсказчик в поиске 28 июня 2010 в 20:39
Отказ от устаревших браузеров 22 июня 2010 в 20:37
Фотографии высокого качества 2 июня 2010 в 20:52
Видео в HTML5 14 мая 2010 в 22:01
Короткие имена 27 апреля 2010 в 12:27

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

+29
wait, #
Транслятор называется KittenPHP, а на промокартинке — собака :)
0
xdevel, #
Это был Котопёс, не зря же ему пила в руке :) Символично, кстати.
+2
detsl, #
Спасибо, «будем посмотреть».
+8
DenisOgr, #
В связи с этим KPHP поддерживает не все возможности PHP, в частности, в нем отсутствует ООП, за исключением некоторых объектов стандартной библиотеки.

ВК имеет не ООП-шную структуру?
+8
hormold, #
Да, в коде ВК (как мне известно) не используется ООП.
+28
brainfucker, #
Нет, от ООП было решено полностью отказаться еще во времена использования обычного PHP по соображениям производительности
+7
Andre_487, #
В связи с этим было бы интересно узнать об архитектуре проекта с программной точки зрения. Надеюсь, когда-нибудь и такая информация станет доступна )
+37
brainfucker, #
Поверьте, Вам не было бы интересно узнать об архитектуре проекта с программной точки зрения =))
+4
Andre_487, #
В любом случае было бы интересно узнать, что стоит за одним из самых посещаемых сайтов. Сегодняшняя новость, например, меня именно по этой причине очень обрадовала.
+30
Alexufo, #
Дык как обычно, подзатыльники и мат.
0
AxisPod, #
Выиграли 1% производительности ПО, потеряли 50% производительности разработчиков? Да и как обычно узкое место БД/др. хранилища, потратив те ресурсы, что были потеряны при отказе от ООП на развитие именно БД/хранилищ/сети и т.д., не был бы выигрыш заметно больший?
+2
Chamie, #
потеряли 50% производительности разработчиков
Цифры с потолка? Сравните численность штата программистов ФБ и ВК, например.
+2
jrip, #
Сомнительны цифры в 50% производительности разработчиков, ООП не панацея, писать понятно красиво и быстро можно и в функциональном стиле.
Как показывает практика 90%++ кода которое использует синтаксис классов на PHP не ООП ни разу, а всего лишь некоторое подобие неймспейсов и странные попытки упоротых абстракций. А там такое можно накрутить, что ой ой ой, и что лучше бы уж сборники функций. Уж времени на разбор кода тратилось бы меньше, а значит и производительность была бы выше.

Да и наверняка дело не в производительности и экономии серверов, а во времени отработки скриптов и отдачи данных пользователям.
+7
AlexP11223, #
Функциональном? Процедурном, наверно.
+3
jrip, #
Я начинал на паскаля, там было разделение процедур и функций) Поэтому подсознательно я это называю так) Хотя вы правы, не стоит отходить от общепринятых терминов, спасибо.
+13
mobilz, #
Вас удивляет, что высоконагруженные проекты стремятся не юзать ооп?
–91
orionll, #
Высоконагруженность здесь ни причём. Просто ООП — говно.
+1
Anakros, #
Почему вы так считаете?
+8
orionll, #
Потому что ООП заставляет трактовать всё как объект, создавая в большинстве случаев кучу бессмысленных абстракций, не имеющих позади себя никакой аналогии в реальном мире. В итоге рождаются всякие странные классы вроде BlaBlaManager, BlaBlaBean, BlaBlaContext и прочая хренотень. Когда нужны просто функции, которые принимают на вход A и выдают на выходе B, люди городят какие-то таинственные паттерны.
+11
aparamonov, #
По-моему из Вашего же комментария следует, что не ООП плох, а то что
люди городят какие-то таинственные паттерны
–8
orionll, #
Ага, Запорожец не говно, просто люди не умеют на нём ездить.
+2
VolCh, #
Потому что ООП заставляет трактовать всё как объект

В Java возможно, в PHP никто не заставляет: ООП, ПП и ФП существуют вместе и не просто параллельно, но интегрировано — можно в ФВП передать объект, который вызывает процедуру.
0
orionll, #
ФВП не делает язык функциональным.
+2
gro, #
Просто надо избавится от чепухи про «ООП это эмуляция объектов реального мира».
0
orionll, #
ООП вообще-то и задумывалось как эмуляция объектов реального мира. А потом сделали Джаву, где чей-то воспалённый мозг решил, что всё — объект, и тогда пришлось притягивать к ООП и всё остальное, городить дырявые абстракции над тем, что не имеет физического смысла.
0
gro, #
Про «объекты реального мира» это одно из главных заблуждений, которые приходится выбивать из новичков, начитавшихся книжек со стандартным введением. Пытаются всё свести к студентам, унаследованным от человека.
–1
orionll, #
Бедные новички, раз вы пытаетесь им вдолбить в голову то, что всё является объектом, включая даже то, что им не является. Не кажется, что заблуждаетесь вы, а не они?
0
gro, #
Не могу сказать наверняка. Программирование, это не таблица умножения и не новости на первом канале. Тут так точно не определишь где заблуждения, а где истина.

Могу только ориентироваться на результат. После того, как люди избавляются от этой бредовой установки, они начинают намного быстрее и эффективнее решать поставленные задачи. И, наконец, получать от этого удовольствие. Что даёт мне небольшу надежду на то, что я на верном пути.
+5
orionll, #
А вы случайно не путаете реальный мир и физический мир? Вот примеры объектов, у которых есть соответствия в реальном мире: ASTNode, WebBrowser, InetAddress, Cache, NetworkClient. Всё это можно себе представить в голове, и для этого даже не надо лезть в документацию. А вот примеры объектов, которым трудно что-то сопоставить: IOUtils, DocumentBuilderFactory, CommandHandler, FileSystemProvider, BeanContextProxy. Все эти классы создаются в основном лишь для того, чтобы преодолеть ограничения, которые ООП само себе понапридумывало.
+1
symbix, #
В джаве был период, когда восторженно городили фабрику на фабрике. Сейчас уже почти всем понятно, что это был перебор, «ООП головного мозга» переболели, становятся популярны более прагматичные фреймворки, такие как Play.
+1
symbix, #
А «всё — объект» придумали задолго до Java, еще в Smalltalk (где, в отличие от Java, действительно всё).
+6
gro, #
Лично меня несколько удивляет. В общем случае. С учётом того, что язык программирование в вебе самая масштабируемая часть.
В случае вконтакта ничего не знаю, может им и так хорошо.
+20
SerafimArts, #
Меня например удивляет. Ребята имеют на руках транслятор из php-кода в сишный и жалуются на то, что ООП в php медленное. Ничего не мешает превращать ООП'шное представление в любое другое, какое вздумается после парсинга кода.

Вот на этих мыслях я вспомнил свой первый сайт и его код — его переписать себе дороже. А ведь вконтакт — это первый сайт, который начал писать Павел (да ведь?) и сейчас, подозреваю, проще запилить транслятор, нежели переписать =)

Так что про ооп vs. скорость — считаю просто отмазкой или хорошим предлогом. Гитхаб или Твитч вообще на рельсах (очень тяжёлый фрейм для очень медленного языка) написаны и ничего, работают вполне себе нормально.
–1
spiff, #
Твиттер работает на Scala стеке.
+9
ShadowPrince, #
По моему имелся в виду twitch.
+3
SerafimArts, #
Всё верно, twitch. Крупнейший в мире видео-стрим ресурс и партнёр, например таких компаний как Близзард.
+6
spiff, #
О. Тогда прошу прощения :) Деревня я — не слышал про Твитч, думал вы так Твиттер искаверкали.
0
SerafimArts, #
Твиттер (так же как и Групон) тоже начинал с рельс, но это ни для кого не секрет наверное =) Потом уже перешли на что-то более быстрое.
–2
vaniaPooh, #
Не первый — есть еще durov.com.
0
SerafimArts, #
Ну он на чистом html же, а я об опыте php. Так что думаю можно не считать
0
Den4ik_k, #
Полностью согласен
0
spiff, #
По поводу «парсинга PHP кода» и генерации C++ кода. Не забывайте, что С++ язык со статической типизацией а PHP — нет. И трансляция динамического языка в статический вообще говоря проблема неразрешимая в общем смысле. Приходится применять кучу эвристик чтобы сократить количество типов void* в генерируемом коде. И Facebook и MathWorks делали нечто подобное и насколько мне известно, поле это почти не паханное — серебряной пули нет.

Так вот. Теперь представьте ОПП во всей его красе (sub-type полиморфизм как минимум) и все становится еще печальнее.
+1
arseny30, #
К тому моменту, когда KittenPHP начинали разрабатывать, классы в коде VK использовались разве что как пространства имен. От них было легко отказаться, и до сих пор они никому особенно не потребовались. Меня самого немного удивляет как они так справляются =)

На самом деле в KittenPHP классы были бы даже быстрее массивов. Добавить ООП по модулю некоторых ограничений не очень сложно. Просто в условиях VK, это никому бы не пригодилось.
+6
Bal, #
Меня удивляет. Когда переписывал свой фреймворк с древнего процедурного стиля на ООП, то получал местами очень приличное ускорение. ООП позволяет программировать быстрее, абстрагироваться от деталей и поэтому реализовывать более сложные, но эффективные в плане производительности механизмы.

Когда 9-летнему Гауссу предложили посчитать сумму всех чисел от 1 до 100, он не стал как другие очень быстро-быстро складывать всё подряд, он подумал и вывел более сложную формулу, по которой и получил результат в десятки раз быстрее одноклассников :)
+4
aktuba, #
А что мешает реализовывать эффективные алгоритмы без использования ООП? Haskel, erlang и пр. не позволяют реализовывать масштабные проекты? ООП — это парадигма, людям проще думать объектами, потому и прижилось. Процедурное и функциональное программирование, чаще всего, эффективнее как в плане скорости, так и в плане потребляемых ресурсов.
0
MYPABEU, #
1+100 = 101
2+99 = 101
И так далее, насколько я помню историю Гаусса
+1
beskov, #
то бишь одноклассники были в пролёте ещё при гауссе )
0
iNickname, #
ах-ха-ха, какой крутой коммент остался без внимания xD
+9
symbix, #
Не удивляет, но проблема тут не в ООП.

1. Парадигма не имеет никакого отношения к нагруженности-ненагруженности. Есть множество примеров эффективного масштабируемого ООП-кода и неэффективного немасштабируемого процедурного.

2. Устоявшееся мнение, что объекты в php тяжелее, чем массивы, неверно для современных версий php. А уж при написании транслятора в c++ это вообще не аргумент.

3. По публикуемому vk коду видно, что их сотрудники предпочитают олдскульный процедурный стиль, и не считают ценности объектного проектирования важными. Их право делать так, как они считают нужным — важен конечный результат. Но я бы туда работать не пошел :)
–8
neytrino, #
А для чего, на примере ВК, им требуетя ООП? Чтоб инпуты с формами за ООПэшить?
–4
unrealphp, #
Чтобы иметь более удобную, заменяемую структуру, например?
+26
Salabar, #
ООП для этого — не необходимое и не достаточное условие.
0
Delphinum, #
А есть необходимое и достаточное условие? Интересно послушать
+14
Salabar, #
Прочитал я, такой, «Совершенный код» и умничаю. Вряд ли. Необходимое — это, видимо, голова на плечах. Достаточное — всё индивидуально. Но конкретно ООП — это просто один из способов упорядочить код. Городить при этом фабрики фабрик чертежей абстрактных фабрик молотков может быть необязательно.
–3
Delphinum, #
А кто предлагал ВК городить «фабрики фабрик ...»? Вы считаете, что с ООП можно только городить «фабрики фабрик ...»?

Мой пукан готов бомбонуться от таких заявлений ))
+5
Salabar, #
Это была отсылка. Конечно, не считаю. Я к тому, что ВК уже много лет развивается без ООП. Как и Линукс, кстати. Т.е. как минимум два проекта нашли способ разработки, который не ООП, но который работает. Точно также, многие проекты ООП как бы следуют, но так, что лучше бы уж писались на Фортране и всем было бы проще. Надеюсь, свою мысль донес.
0
Delphinum, #
Эмм… если честно нет ) Ну да ладно. Всему свое место, даже ООП, с этим согласен.
+3
symbix, #
В ядре linux используется ООП. Отсутствие синтаксического сахара не является преградой для использования объектного подхода.
+28
Blumfontein, #
Если Вконтакту с его супер навороченной логикой не нужен ООП, то мы с вами на своих бложиках про кота Василия вообще должны plain-html писать.
+7
Lopar, #
HTML-блоггинг посредством гитхаба — прямое тому доказательство.
0
DsideSPb, #
Многие гитхаб-блоггеры используют Jekyll, а в нём используется Liquid для описания шаблонов страниц. Есть объект-сайт, в нём объекты-посты, объекты-теги… Довольно жирный намёк на ООП.
+1
ddem, #
Вы всерьез думаете, что ООП и другие модно/популярные возможности обязательно необходимы для успешного проекта?
0
Dinir102, #
На одной из конференций затрагивали эту тему. Там подтвердили что они не используют ООП, т.к. это ускоряет выполнение кода.
–11
Iskin, #
Наконец-то ВК что-то отдали опен сорсу. Как делать бизнес на нём, так ОКи. А как хотя бы встречу программистов провести в офисе — так фиг, мы лучше встречу дискуссионного клуба проведём и т. п.
+2
justusebrain, #
+8
Iskin, #
Спортивное программирование — очень далеко от реального. В любом случае, тут не опенсорс.
+4
justusebrain, #
Я отвечал про жалобу на отсутствие встреч программистов. И да, какая разница, где их проводить? В офисе ВК или в старбаксе?

Насчет опенсорса — ну, да, не выкладывали, это нарушало лицензии? Я не защищаю ВК, я просто не понимаю ваших претензий.
0
Iskin, #
Ну я говорю о бытовых понятиях справедливости. Например, если кто-то помог тебе в трудную минуту, то когда у тебя всё очень хорошо, а у твоего помощника проблемы — логично помочь (хотя отказ помогать и не будет нарушением каких-то законов).

Посмотрите на другие крупные компании: Яндекс выложил кучу всего, регулярно проводит конференции, делиться опытом; Mail.ru: github.com/mailru; Одноклассники: github.com/odnoklassniki; Фейсбук выложил кучу кода, регулярно что-то рассказывает; Гугл выложил кучу кода, помогает другим проектам деньгами и Summer of Code; Групон: github.com/groupon (русский Групон выложил тоже кучу проектов в рамках Злых марсиан).
0
VolCh, #
Ну вот и ВК подтянулся. В чём претензии?
–1
Iskin, #
Могли бы и раньше, учитывая сколько у них было ресурсов и денег.
0
VolCh, #
Сравните возраст ВК с возрастом Мэйла и Одноклассников.
+20
mobilz, #
Да это просто праздник какой-то ) добавьте плз к каждой технологии количество нодов и количество задач, которые обрабатываются этими технологиями, вот это будет интересно
–2
mishasamin, #
УРААА! Он вышел для МОЕГО пользования!
+15
RuslanNazarov, #
Да тут половина ВК ушло в opensource, спасибо ребят!
+18
brainfucker, #
Нет это лишь часть набора наших инструментов разработки, но уверен, что это действительно большой вклад в развитие OpenSource
+4
shoucken, #
Ну, теперь то уж точно любой сможет сделать свой ВКонтакт с блекджеком и котятами.
+8
kDas, #
Давно ждали, выложить в опенсорц наработки по базам данных обещали еще несколько лет назад. Как я понимаю, с тех пор многое изменилось, но за опенсорц — респект!
+2
ReklatsMasters, #
Facebook напрягся)
–3
MrMig, #
Facebook срочно перепиливает свои решения на новые рельсы!
+3
Chamie, #
Facebook срочно перепиливает свои решения на … рельсы
OMG. Ждём Hip-Hop on Rails?
+8
Chamie, #
Видимо, шутка не удалась.
ушёл танцевать хип-хоп на ж/д путях
+1
eosunknown, #
Фейсбук с технической точки зрения не смотря на свои бюджеты и размеры далеко отстал от ВК. По крайней мере так ощущается когда пользуешся одним и другим.
+14
orionll, #
Офигеть, есть даже документация на русском!
+11
leventov, #
Только на русском, что скорее минус, потому что затрудняет обмен опытом с большей частью сообщества.
+15
Alexufo, #
Это плюс, теперь ребята с забугра пусть поломают головы над документацией, что неминуемо сблизит два народа)
+4
cyberorg, #
Документация на Nginx тоже изначально была только на русском.
Потом перевели на английский и другие.
+4
leventov, #
Ой, вряд ли. При всем уважении к инициативе ВКонтакте, этот набор довольно специфичных для соцсетей и конкретно для самого ВКонтакте компонент несопоставим по полезности с nginx. Учитывая, какое есть на Западе предубеждение против всего русского, которое влияет и на nginx, а еще учитывая тамошний имидж самого ВКонтакте как клона Фейсбука, не думаю что найдутся энтузиасты развивать англоязычное сообщество.
+3
symbix, #
Да нет никаких предубеждений, IT-специалисты — не политики. Изначально, когда еще не было nginx inc., документация переводилась энтузиастами на вики, и уже тогда nginx вытеснил lighttpd. Сейчас nginx — самый популярный вебсервер для нагруженных сайтов в мире.
–12
dezo, #
Очень классно! Еще вчера планировали писать на PHP новый проект, а сегодня выходит kPHP. Спасибо огромнейшее! Это очень большой вклад в сообщество разработчиков.
+13
AmdY, #
Зачем, ассемблер же быстрее. Вы же понимаете что там ни разу ни php, а функциональная линейно-процедурная приблуда. Тем более уже давно есть HHVM, который даже поддерживает некоторые фреймворки, есть phalcon — как расширение. Вот только надо ли оно вам?
+2
VolCh, #
Функциональная? O_o В PHP есть зачатки функциональщины, но подозреваю, что в KPHP их ещё меньше.
0
teonoman, #
Товарищ имел ввиду процедурные приблуды.
0
VolCh, #
Процедурные он написал отдельно.
+15
nazarpc, #
И всё же ограниченность синтаксиса kPHP делает в тестах фаворитом HHVM. Скорость HHVM сопоставима, в принципе, со скоростью PHP (Zend), но при этом он почти на 100% совместим, что в большинстве не вынуждает каким-либо образом менять исходный код.
А kPHP — слишком узкоспециализированная штука получается. Вот когда будет поддержка ООП, и синтаксиса на уровне PHP 5.4 — тогда и посмотрим на скорость.
+2
SerafimArts, #
Полностью поддерживаю. Хочу посмотреть скорость проекта на Phalcon (ядро) + HHVM (бизнес-логика) с полной поддержкой языка, против kPHP с подходом, от которого отказались лет 5-6 назад.
+2
nazarpc, #
Опечатка, сопоставим, конечно же, с kPHP.
+2
TheRaven, #
Абсолютно те же мысли, зачем kPHP если HHVM имеет почти ту же скорость, но близкую к 100% совместимость с оригинальным PHP?
+1
Blumfontein, #
KPHP (как и HHVM) даром не нужны, а вот за все остальное огромное спасибо!
+3
SerafimArts, #
Что значит «как и HHVM»? Вопрос: Что лучше, сайт или очень быстрый сайт, жрущий меньше оперативы и процессорного времени? Разница между ними всего лишь в одном. Во втором случае потратили 30 секунд и написали apt-get.
+2
Blumfontein, #
Заглянуть в composer.json и удалить оттуда всякий хлам, и переписать нормально сайт — вот от чего сайт точно будет «жрать меньше оперативы и процессорного времени». От одного apt-get install hhvm у вас разве что только установленных пакетов на 1 больше станет, а больше ничего не изменится. Не вводите людей в заблуждение.
+2
SerafimArts, #
Ну, допустим, я не писал «apt-get install hhvm», там много всякого надо подставить через apt-get.

Цель комментария не в том, как поставить хип-хоп — мануалов на просторах интернета полно, а в том, что это не сложно и ничего переписывать нигде не надо в подавляющем большинстве случаев: www.hhvm.com/frameworks/ в отличие от представленного в топике. И я буду только рад (да простят меня ВК-разработчики), если не найдётся такого человека, который решится написать крупный проект в процедурно-лапшевидном стиле, напичканный глобалсами, как чаще всего и бывает у начинающих. Прошу заметить, что я не имел ввиду то, что любой процедурный код ужасен, просто он куда больше поощряет «кодоблудие», нежели прототипный, оо или иные подходы.
0
akalend, #
и в ООП тоже много говнокодеров
+51
bougakov, #
Знаете, что мне это напоминает?

Вот написал ты заявление об увольнении, осталось 2 недели отработать. И ты разгребаешь стол, уносишь домой любимую чашку, выкидываешь барахло в мусорку, раскладываешь рабочие файлы по правильным папкам, чтобы от проклятий сменщика не «икалось».

Знакомоме ощущение, да?

Вот что-то мне кажется, через недельку-другую мы прочитаем, что гендиректор ВК «тут больше не работает». А выкладка на Гитхаб — это «дембельский» привет новым акционерам.
–14
hMartin, #
Вот еще на хабре осталось начать постить новости о войнах Дурова с акционерами. Спасибо, не надо. Хватает того, что каждое СМИ не упускает возможности написать очередную новость по этому поводу.
–3
rumkin, #
Это ну очень мягкая форма прощального «F*ck off!» новым акционерам.
+40
oowl, #
Очень круто.
Но местами, видно отсутствие времени на отделение от кода ВК. (Пользователь 6492)
+12
OnYourLips, #
Ну и толку в нем, если он синтаксис PHP нормально не поддерживает?
Под него придется специально говнокодить, чтобы работало.

Код не понравился.
+3
ZonD80, #
А что, если сравнить с php+apc?
+9
youROCK, #
Почитал код бенчмарков, нашел «применимыми к реальности» только hash*, а в них kPHP не так уж и быстрее HHVM (и самого PHP), закрыл код бенчмарков. Про поддержку только 1251 и UTF-8 в mbstring я вообще молчу. Про бенчмарки с фиксированным числом итераций тоже промолчу (компилятор C++ спокойно справится с простейшей задачей выкидывания «ненужного» кода).
+4
arseny30, #
Стоит заметить, что этот бенчмарк взят (с незначительными изменениями) из исходников PHP (php-src/Zend/bench.php)
Он проверяет основные конструкции языка от производительности которых зависит производительность всего кода, но конечно не претендует на какую любо универсальность.
Любые бенчмарки кроме реально используемого кода немного условны. В том смысле, что они могут не иметь никакого отношения к реальной жизни.

Даже без фиксированного числа итераций компилятор C++ может многое упростить. Например в тесте nestedloop С++ (и соответственно KPHP) оптимизирует вложенные циклы в вычисление простой формулки.

Про mbstring справедливое замечание. Я бы удалил оттуда ещё и поддержку cp1251, потому что чаще всего те, кто используют его вместо utf-8, неправы.
+1
x7mz, #
Большое спасибо за вклад в open source.

Хотелось бы также увидеть сравнения с аналогами, хотя бы поверхностные. Например:
PMemcached, Lists, Lists-X vs Redis
Search vs Sphinx, Solr (Lucene)
Storage vs даже не знаю, не понял что это. OpenStack Swift? GlusterFS? Или это больше похоже на виртуальный HDD?

Правильно ли я понял, что Hints это штука, которая быстро делает WHERE name LIKE 'Иванов Ива%'?
0
uh_zuh, #
Hints.

Скорее WHERE name1 LIKE 'ива%' OR name2 LIKE 'ива%' OR name3 LIKE 'ива%'… с сортировкой по релевантности.

Причём Иванова Василия мы найдём по любому из следующих запросов:
ива васи
васи ива
iva vasi
bdf dfcb
шмф мфыш
и в

и т.д.
+6
xorax, #
Скажите, есть ли план не только выложить, но и поддерживать выложенные проекты, принимать пулл реквесты? Или дальнейший цикл — это форки, кто во что горазд?
+9
hell0w0rd, #
Думается мне таки будущее за zephir/hhvm. Отказываться от ООП — довольно прискорбно. Если хочется скорости — можно плюсы взять и написать парочку оптимизированных функций
+3
dim_s, #
По мне это какой-то пхп-ный си. Слишком специфичный продукт.
+4
VolCh, #
PHP3 :)
+2
mster, #
Что вы как маленькие. KPHP используется исключительно там, где нужна высокая производительность — на фронтенде.
По сути это шаблоны, компилируемые в http сервера.

Под ним — слой сервисов, которые обрабатывают данные, обеспечивают взаимодействие с хранилищами и готовят данные для фронтендов. Понятно, сервисы написаны на нормальных языках ООП. Ибо гораздо дешевле поставить еще одну ферму апликейшн серверов, чем оплачивать работу программистов по поддержке простыней. А без ООП там будут ого-го какие простыни и костыли. VK скрывает правду.
0
golodenko, #
Все определяет масштаб. Работа программистов может быть дешевле аренды N серверов.
0
Chamie, #
Я бы даже сказал «N ферм апликейшн серверов». При суммарном количестве серверов в районе 25 тысяч каждый сэкономленный процент — это, условно, 250 серверов. VK же использует универсальные серверы.
–1
Stac, #
Странно, но простыни и костыли как-то проще и дешевле в поддержке, особенно при наличии документации. По моему скромному опыту.
0
antanubis, #
Нету этого слоя сервисов, написанных на нормальных языках ООП =(
+1
alexglue, #
Я, может быть, проглядел это в статье, но с какой версией PHP проводилось сравнение в тестах?
Производительность PHP как бы несколько отличается от версии к версии )
+1
arseny30, #
PHP 5.4.4-14+deb7u7 (cli)
HipHop VM 2.5.0-dev (rel)
0
akalend, #
спасибо, будем изучать и внедрять
0
leoismyname, #
А куда? Что за специфические задачи?
+12
Blumfontein, #
Цукерберг, перелогиньтесь
+3
AlexP11223, #
HHVM и прочее не внедряли, а вот КРНР срочно всем понадобилось внедрять?
0
akalend, #
когда-то мне нужно было внедрить фейсбуковский движок, но тогда они не поддерживали монгу. Пришлось шаманить…
не хочется наступать на грабли, ну прежде чем внедрить — надо знать, что это за зверь
по этому будем изучать…

+4
VolCh, #
Смотрю пхп-код и такая ностальгия, как будто на 10+ лет помолодел — практически PHP3 :)
0
Flex25, #
1. Выражаю благодарность VK за KPHP.

2. Когда вы делали тесты, вы учли, что у HHVM есть стадия разогрева и реальные результаты надо снимать после хрен знает какого по счету прогона? Напишите подробнее, как тестировали HHVM.
0
arseny30, #
Учли конечно. Это данные где-то 12-ого запроса к серверу. По умолчанию на разогрев происходит во время выполнения первых 11-ти запросов.
На 12-ом заметен скачок с 3.5 до 0.44 секунд.
Похожих результатов можно добиться простым однократным запуском hhvm с параметром -v«Eval.Jit=true». Учитывая специфику теста, на саму компиляцию уйдет совсем немного времени и результат будет около 0.49 секунд.
0
Flex25, #
В таком случае все круто. Буду разбираться с KPHP.
0
Flex25, #
Еще вопрос вдогонку… А вы не производили замеры потребляемой памяти KPHP и HHVM? Ведь потребление памяти для high load тоже важно, но в тестах производительности этот момент часто упускают.
+3
Flex25, #
Вконтактовцы, пожалуйста, не поленитесь и сделайте документацию KPHP для обычных (не гуру) пользователей. Что-то типа «getting started» для тех, кто в танке…

Я попытался было разобраться, но не нашел никакой технической инфы про KPHP. В вашем репозитории в папке kphp-kdb/docs/ru/ лежит документация только для базы данных, а про KPHP ничего нет.

У HHVM документация тоже не ахти, но она все же есть. И есть еще собранные бинарники для популярных дистрибутивов. Если бы вы такое сделали, вообще было бы шикарно.
НЛО прилетело и опубликовало эту надпись здесь
–1
Ipatov_e, #
Скоро нас захлестнет волна сайтов написанных школьниками на «движке от ВК».
Лопоухим клиентам будут втридорога «втюхивать» сайты-визитки, на новом, навороченном движке, от самого ВК.
0
Stac, #
Не раньше, чем вы напишите «getting started» и сделаете пакеты для популярных ОС.
Да и вообще, сейчас школьники смотрят скорее в сторону навороченных ООП фреймворков, что для PHP, что для других языков.
0
inook, #
Такое ощущение, что вы своих программистов, которые писали KPHP, не выпускали из офиса, пока они доку не накатают и код не поправят.
Документация написанна на плевок в OpenSource сообщество. Вот по этому я и не люблю русских программистов в OpenSource сообществе.
0
Stac, #
Без паники. Теперь, когда есть документация, ее можно и улучшить, в т.ч. силами сообщества.
+8
Javer, #
У меня получились менее убедительные результаты в этом бенче на одной машине:

KPHP: 0.118
HHVM 2.5: 0.271
PHP 5.5.9: 1.982
PHP 5.3.28: 2.524

Проверить на чем-то более реальном нет возможности, поскольку «привет ООП».

Прирост скорости в 2 раза относительно HHVM в этом синтетическом тесте при таком урезанном функционале PHP не впечатляет, особенно если учесть, что в этом бенче производится ничто иное, как числодробительные операции и копирование блоков памяти в больших циклах, которые прекрасно оптимизирует компилятор gcc, в том числе не выполняя ничего вообще. Это легко заметить, если немного изменить код, чтобы результаты вычисления были где-то использованы. Другими словами, этот двукратный прирост — это заслуга gcc, а не KPHP.

Прироста в 7-9 раз в случае HHVM хватает с головой, при этом остается полноценный набор возможностей PHP уровня 5.5 с ООП и другими плюшками, и можно выполнить любой существующий код без изменений.

На самом деле ребята из команды HHVM уже проходили этот путь и у них в блоге доходчиво объясняется, почему трансляция PHP в C++ — это пройденный этап.
+3
arseny30, #
Числа, указанные в статье получены при компиляции с ключом -O3, а в выложенных исходниках она по-умолчанию происходит с ключом -Os
При желании можно исправить KPHP/tests/Makefile и пересобрать bench.php, предварительно удалив директорию в которую происходила компиляция. По-умолчанию это KPHP/tests/kphp_tmp.

Написание jit компилятора несколько более масштабная задача, чем написание транслятора. В частности его разработчикам придется проделать весь тот путь, который прошел gcc. И если gcc что-то оптимизирует, а HHVM нет, то только потому что в HHVM этот путь пройден не до конца.

Я не вижу никаких плюсов для VK в подходе с виртуальной машиной. Работать она будет медленней, усилий и ресурсов на нее пришлось бы потратить в разы больше.
Но конечно я понимаю, что всех интересует применимость KPHP к их задачам, а не только к VK.
0
byabuzyak, #
Полностью солидарен с Вами.
0
dmkuznetsov, #
Интересно, зачем нужно было писать транслятор, который, объективно говоря, можно применить в единичных случаях?
Почему нельзя было просто переписать все на С и облегчить себе поддержку проекта?
0
Rulexec, #
Всё равно пришлось бы городить каким-то образом песочницы. Когда случается рантайм-ошибка в PHP-коде — ничего страшного. Когда случается segmentation fault в сях — ломается всё.
0
akalend, #
xчто-то не получилось создать… все библиотеки создались объектные файлы,
сделал make kphp но результата ни какого.
не могу найти исполняемый файл kphp2c
0
akalend, #
все вопрос снят, разобрался… майк немного страдает отсутствием диагностики
–1
DjOnline, #
Добавьте сравнение с HHVM Hack, который теперь полная копия KPHP.

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