Это понятно из кода в заметки. Для меня осталась загадкой аналогия с конкатенацией c-style строк.
Соль статьи не склеивание, а вызов функции с большим количеством параметров. Склеивание — это скорей побочный эффект, потому что была выбрана функция array_merge.
Брали у хостингуа колокол. Если проплата просрочена на пару дней — они тупо питание из сети дёргают. И им всё равно, что может база лечь или ФС побиться. Отвратительно!
Мне кажется, что использовать протобаф с PHP немного бессмысленно. Поясню.
Во-первых, PHP — динамический язык и при изменении исходных текстов проекта ничего перекомпилировать не надо. Изменяя .proto файл нужно каждый раз генерировать заглушки. Это несколько ломает идеологию. Такой подход оправдан, например, в Java где обязательно есть фаза компиляции.
Во-вторых, из предыдущего свойства также вытекает сложность поддержки протокола, если количество машин исчисляется сотнями, и количество ОС/языков тоже велико. Это всё дело нужно поддерживать и пристально следить.
И в-третьих, насколько я понял, разбор пакетов, приходящих в приложение выполняет та же генерируемая заглушка. А PHP для этого не самый лучший кандидат для работы с бинарными данными. Весь профит, получаемый от экономии на трафике будет уничтожен увеличением нагрузки на сервера. Пока не будет pecl-либы, написанной С, говорить о применении protobuf в PHP рано.
Ради простоты внутренней архитектуры и быстродействия было решено сделать редис однопоточным. Он простой в понимании => простой в применении.
С другой стороны, непонятно, зачем нагружать редис так, что нужны все 8 ядер? Этоже kv- _store_. Т.е. основное предназначение сохранять данные, а обрабатывать их должно приложение, которое уже может работать на нескольких потоках.
Стандартная на текущий момент связка javascript + flash sockets. Конечно, не самый идеальный вариант. Ждем html5 web sockets :)
>ява-скрипт пока не умеет работать разбирать двоичные данные
Поэтому текст явно лучше именно в подобных случаях, где можно обойтись без бинарного кодирования.
А вообще, если всё так это чат (кстати, вы так и не ответили, что же это за приложение такое), я бы сначала глянул на jabber-related технологии. Например на BOSH. Выглядит многообещающим, но к сожалению, погонять нету времени и возможности.
Я предполагал, что клиентская часть приложения будет обмениваться сообщениями непосредственно с брокером посредством постоянного соединения.
Опять таки, если я правильно понял, то приложение, которое вы разрабатываете, будет похоже на текстовый чат. Т.е. большинство сообщений между сервером и клиентом могут ходить текстом а не бинарными пакетами.
Если планируется использовать AJAX, то смысла поднимать «внутри» очень быстрый AMQP брокер, скрывая его за nginx-ом, вообще-то говоря мало. Фронтенд скорей умрет от огромного количества соединений, создаваемых клиентами, которые poll-ят сервер.
Единственноее применение возможности передавать бинарные данные не средствами HTTP, как мне кажется, это толстые клиенты. Например, flash игрушки. Для остального (в том числе и для web-чата как в примере) хватит HTTP + какой-нибудь формат передачи (XMPP, JSON etc)
Может быть кто-то в курсе, есть ли в Украине компании, которые занимаются такого рода размещением?
Есть подозрение, что при работе с Агавой для «не местных» может возникнуть много бумажной волокиты. Да и 100% что оформление будет не быстрым.
Было бы хорошо, если бы вы явно обозначили преимущества перед тем же XMPP. Это не просто прихоть, а желание понять, когда следует использовать данных подход и какой профит он принесет.
Как раз таки php-fpm был сделан и сейчас используется для большого продакшена. Точно не знаю, но кажется что именно -fpm используется в badoo.com, где и работает создатель этого проекта.
Интересно, если фронт работ всё-таки «доработать»,«выловить баги»,«оттестировать», зачем им «творцы» (цитата из статьи)? Хватит средних ответственных исполнителей.
Я наверное неточно выразился. Перевести термины с английского на русский может каждый. Хотелось бы понять, например, writing в случае reverse-proxy — это writing на проксируемый сервер + writing клиенту? Или в случае active connections, учитываются ли там keep-alive соединения с backend-ом?
Было бы хорошо, если бы кто-то на пальцах рассказал как эти параметры интерпритировать, например в случае reverse-proxy или fast-cgi сервера. Может быть я плохо копал, но для меня полученные на графиках цифры остались загадочными.
Соль статьи не склеивание, а вызов функции с большим количеством параметров. Склеивание — это скорей побочный эффект, потому что была выбрана функция array_merge.
Во-первых, PHP — динамический язык и при изменении исходных текстов проекта ничего перекомпилировать не надо. Изменяя .proto файл нужно каждый раз генерировать заглушки. Это несколько ломает идеологию. Такой подход оправдан, например, в Java где обязательно есть фаза компиляции.
Во-вторых, из предыдущего свойства также вытекает сложность поддержки протокола, если количество машин исчисляется сотнями, и количество ОС/языков тоже велико. Это всё дело нужно поддерживать и пристально следить.
И в-третьих, насколько я понял, разбор пакетов, приходящих в приложение выполняет та же генерируемая заглушка. А PHP для этого не самый лучший кандидат для работы с бинарными данными. Весь профит, получаемый от экономии на трафике будет уничтожен увеличением нагрузки на сервера. Пока не будет pecl-либы, написанной С, говорить о применении protobuf в PHP рано.
С другой стороны, непонятно, зачем нагружать редис так, что нужны все 8 ядер? Этоже kv- _store_. Т.е. основное предназначение сохранять данные, а обрабатывать их должно приложение, которое уже может работать на нескольких потоках.
И что с этого? Там используется асинхронный способ работы с данными
>ява-скрипт пока не умеет работать разбирать двоичные данные
Поэтому текст явно лучше именно в подобных случаях, где можно обойтись без бинарного кодирования.
А вообще, если всё так это чат (кстати, вы так и не ответили, что же это за приложение такое), я бы сначала глянул на jabber-related технологии. Например на BOSH. Выглядит многообещающим, но к сожалению, погонять нету времени и возможности.
Опять таки, если я правильно понял, то приложение, которое вы разрабатываете, будет похоже на текстовый чат. Т.е. большинство сообщений между сервером и клиентом могут ходить текстом а не бинарными пакетами.
Если планируется использовать AJAX, то смысла поднимать «внутри» очень быстрый AMQP брокер, скрывая его за nginx-ом, вообще-то говоря мало. Фронтенд скорей умрет от огромного количества соединений, создаваемых клиентами, которые poll-ят сервер.
Было бы интересно узнать, где ТС использует AMQP.
Есть подозрение, что при работе с Агавой для «не местных» может возникнуть много бумажной волокиты. Да и 100% что оформление будет не быстрым.