Каков лучший метод сериализации для объектов в memcached?
Проблема в том, что вы не можете использовать
class { '::my_app::repo': }
и
include my_app::repo
в одном и том же наборе манифестов.
Документация для этого находится на https://puppet.com/docs/puppet/5.3/lang_classes.html#declaring-classes . В результате вы можете использовать ресурсное объявление (например, class) только один раз для каждого класса, и вы не можете смешивать его с include, но вы можете include создать класс столько раз, сколько захотите. .
В вашем случае я бы посоветовал вам использовать рефакторинг include для ваших my_app классов.
3 ответа
Я попробовал несколько методов и обосновался на сжатом JSON как лучший баланс между скоростью и объемом потребляемой памяти. Собственная функция Рассола Python немного быстрее, но полученные объекты не могут использоваться с клиентами не-Python.
я вижу 3:1, сжатие так все совпадения данных в кэш-памяти и приложении получает sub-10ms время отклика включая рендеринг страницы.
Вот сравнение JSON, Экономии, Буферов Протокола и YAML, с и без сжатия:
http://bouncybouncy.net/ramblings/posts/more_on_json_vs_thrift_and_protocol_buffers/
Похож на этот тест, получил те же результаты, которые я сделал со сжатым JSON. Так как я не должен предопределять каждую структуру, это походит на самый быстрый и наименьший межплатформенный ответ.
Одно основное соображение, "Вы хотите должными быть указать каждое определение структуры" ?
, Если Вы соглашаетесь с этим, затем Вы могли бы смотреть на:
- Буферы Протокола - http://code.google.com/apis/protocolbuffers/docs/overview.html
- Экономия - http://developers.facebook.com/thrift/ (более приспособленный к сервисам)
Оба из этих решений требуют, чтобы вспомогательные файлы определили каждую структуру данных.
<час>, Если Вы предпочли бы не подвергаться разработчику наверху предопределения каждой структуры, затем смотрите на:
- JSON (с помощью Python cjson и собственного PHP json). Оба действительно действительно быстры, если Вы не должны передавать двоичное содержание (такое как изображения, и т.д....).
- еще один Язык разметки http://www.yaml.org/ . Также действительно быстро, если Вы получаете правильную библиотеку.
Однако я полагаю, что оба из них имели проблемы с переносом двоичного содержания, которое является, почему они были исключены для нашего использования. Примечание: YAML может иметь хорошую двоичную поддержку, необходимо будет проверить, что клиентские библиотеки - видят здесь: http://yaml.org/type/binary.html
<час>В нашей компании, мы прокрутили нашу собственную библиотеку (Extruct) для межъязыковой сериализации с двоичной поддержкой. У нас в настоящее время есть (прилично) внедрения FAST в Python и PHP, хотя это не очень человекочитаемо из-за использования base64 на всех строках (двоичная поддержка). В конечном счете мы будем портировать их на C и использовать более стандартное кодирование.
Динамические языки как PHP и Python становятся действительно медленными, если Вы имеете слишком много повторений в цикле или должны посмотреть на каждый символ. C, с другой стороны, сияет при таких операциях.
, Если требуется видеть реализацию Extruct, сообщите мне. (контактная информация в http://blog.gahooa.com/ под "Обо Мне")
"Межплатформенная поддержка (Python, Java, C#, C++, Ruby, Perl)"
Слишком плохой это критерии является первым. Намерение позади большинства языков состоит в том, чтобы выразить фундаментальные структуры данных и обрабатывающий по-другому. Это - то, что делает несколько языков "проблемой": они все отличаются.
А единственное представление, это хорошо через многие языки, обычно невозможно. Существуют компромиссы в богатстве представления, производительности или неоднозначности.
JSON соответствует остающимся критериям приятно. Сообщения компактны и анализируют быстро (в отличие от XML). Вложение обрабатывается приятно. Изменение структуры, не взламывая код всегда сомнительно - при удалении чего-то старый код повредится. При изменении чего-то, что требовалось, старый код повредится. Если Вы добавляете вещи, однако, JSON обрабатывает это также.
мне нравится человекочитаемый. Это помогает с большой отладкой и поиском и устранением неисправностей.
тонкость наличия кортежей Python превращается в списки, не интересная проблема. Приложение получения уже знает структуру, получаемую, и может настроить ее (если она имеет значение.)
<час>Редактирование на производительности.
Парсинг XML и документов JSON от http://developers.de/blogs/damir_dobric/archive/2008/12/27/performance-comparison-soap-vs-json-wcf-implementation.aspx
xmlParse 0.326 jsonParse 0.255
JSON, кажется, значительно быстрее для того же содержания. Я использовал Python SimpleJSON и модули ElementTree в Python 2.5.2.