Это понятно из кода в заметки. Для меня осталась загадкой аналогия с конкатенацией 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 сервера. Может быть я плохо копал, но для меня полученные на графиках цифры остались загадочными.
Всё равно эти цифры вызывают когнитивный диссонанс :)
Хочется думать, что кешер — это что-то маленькое, шустрое, очевидное в понимании (понять как работает libevent совсем не сложно). А тут получается 41М кода крутится в памяти, и непонятно чем эта вся машинерия занимается. К слову, memcached занимает 2-3К на сервер-процесс.
Всё сказанное выше — личное субъективное мнение. Уверен, что у ehcache есть своя ниша и он там успешно применяется.
1. Я в Java не спец, не буду спорить :)
2. Именно сколько сервер занимает места в памяти. Например, мне нужен 1Г кеш, а сервер+JVM занимает 150М (условно). Тогда, чтобы всё влезло в память и не свопилось, мне нужно смотреть, чтобы в системе было 1.15Г свободной памяти.
>При превышении памяти все будет идти на диск, так что это не будет сильной проблемой
То есть это будет не cache, а storage. И весь выигрыш в производительности будет съеден дисковыми операциями, от которых мы активно уклонялись. А полученная система будет всё больше похожа на RDBMS, где «горячие» данных хранятся в памяти, а всё остальное укладывается на диск.
По ходу прочтения возникло пару вопросов:
1. Как-то подозрительно, что по скорости он обгоняет memcached. Выделение памяти в JVM просиходит быстрее, чем обычный allocate операционной системы?
2. Если импользовать этот кешер, какие накладные расходы по памяти могут возникнуть? Т.е. используюя например memcached ясно, что сервер занимает несколько килобайт (сотен килобайт) памяти. А как дело обстоит с ehcache?
Но ведь по сути, фреймворк — не более чем собрание чужих протестированных «велосипедов». Если понадобится какая-то из ряда вон выходящая возможность, придется разбираться в тонне чужих идей и в еще бОльшем количестве кода.
Я веду к тому, что не надо идеализировать тот же django. Если разрабатываемый проект полностью укладывается в возможности того или иного фреймворка, то тогда да, действительно, всё что нужно сделать — это просто использовать предоставленные наработки.
Простите, но прочитав код и описание, не нашел ничего «действительно умного». Просто реализация сессий под свои конкретные нужды (т.е. временное кеширование сессионной инофрмации в memcache).
Ага. Таки съел.
Там еще есть нюанс с приоритетами операций в PHP. Второй тернарный оператор надо взять в круглые скобки. Вставить правильный код так и не получилось :(
Удивительно, но у меня тоже вчера сломался мой 959NF. Отдал в сервис центр. Надеюсь, что они не закатают огромную цену.
Порадовала тётя, которая на приёме сидит. Говорит, ну мол бывали случаи, когда ремонтировали месяц и взяли 200 грн. А ремонт состоял в замене предохранителя.
В PHP простые типы оттдельно, классы (объекты) отдельно. Возвращая строку «lol» ты возвращаешь именно строку.
Но есть фишки — можно преобразовать массив в объект и объект в строку.
А вообще, всё в мануалах написано :)
Не стоит на нее смотреть как на серьезную production библиотеку. Скорее как на забаву, развлечение. К тому же, она наглядно показывает, как работают fluent interfaces. И можно в код поглядеть, возможно какие-то мысли пригодятся при разработке asList :)