Мы тестировали (тестируем) WebP на продакшене, по моим данным «в среднем по больнице» картинки WebP на 50% меньше по объёму, чем JPEG при неотличимом на глаз качестве. Для мобильных пользователей социальных сайтов, где картинки составляют основную часть трафика — это серьёзное улучшение.
Единственная проблема — исходное изображение в JPEG, поэтому за трафик приходится платить CPU при перекодировании (ну или хранить и JPEG, и WebP рядом).
Flow my tears, the policeman said — тоже альтернативная реальность и с неплохой концовкой.
Эта книга слабая, имо, но из-за канвы сюжета (вау! США проиграли войну!) очень популярна «у них», судя по всему.
А вот Убик я б экранизировать не стал — зрителям тогда придётся принимать что-то сильнодействующее перед просмотром, чтоб быть «на одной волне» с автором.
Безусловно, стоит посмотреть Jemalloc. На моём опыте, он более производителен, чем Hoard.
Кроме того, есть ещё некий lockless allocator. Сам пока не пробовал, но их бенчмаркинг утверждают, что он даже лучше Jemalloc: locklessinc.com/
Ильяс, а я правильно понял, что вы перекладываете из сырых данных в свои таблицы и потом строите по этому графики?
А можно узнать зачем?
Предполагалось, что существующие виды отчетов как раз вот такие случаи все должны решать.
Если не решают, то либо вы что-то не так делаете, либо вам не хватает какого-то функционала. Вопрос — какого?
Кстати, недавно добавились еще медиана, произвольные перцентили по времени запроса + т.н. «гистограмма» частот (т.е. можно посмотреть «внутрь» среднего числа и построить графики распределения времени запроса, например).
uWSGI Stats Server — это статистика одного сервера, которую он сам отдаёт.
Pinba изначально предназначалась для автоматического сбора и агрегации данных с множества серверов.
Плюс в неё с самого начала закладывались таймеры, который позволяют засекать время определённых участков кода и строить агрегированные отчеты уже по операциям, а не по запросам.
>При этом не используется база данных и не добавляется лишний код в обработку каждого реквеста.
Если не использовать таймеры, то ничего не добавляется, вся статистика собирается и отсылается автоматом (в PHP. Хотя и в других языках тоже наверняка).
История такая:
Набор патчей с подобным функционалом начал делать Владимир Вологжанин еще в Мамбе, хотя идея была Андрея.
В какой-то момент Андрей это всё сам переписал и выложил под GPL.
Поскольку GPL несовместима с PHP License (верней наоборот, но не суть), я уговорил Андрея поменять на что-то более permissive, немного подправил и патч предложил в PHP Core.
Патч приняли и теперь оно живёт своей жизнью.
Все вышеупомянутые люди (включая меня) работают в Баду и сейчас, если вам интересно.
Исходники нужно сконфигурировать/собрать с такими же опциями, что и бинарник, включая CFLAGS/CXXFLAGS.
Судя по опыту людей, они всё-таки какие-то флаги добавляют, которые в документации отсутствуют: groups.google.com/d/msg/pinba-engine-ru/mQDa18eup-c/8NUPyWoITpoJ
Поэтому, как возможно решение, можно собрать самому и то, и другое из исходников.
>Есть N множеств чисел, в каждом множестве не более 100тыс элементов,
>и нужно понять, входит ли данное число в n-ное множество?
Да, но еще надо проходить по этому множеству от начала до конца и чтобы это множество занимало минимум памяти.
Решение меня интересует не на PHP, конечно, а на С — мы же ищем более эффективный алгоритм, чем Judy.
Во-первых, я не совсем понимаю ваше отношение к патентованным алгоритмам.
То есть, да, софтварные патенты — зло и всё такое, я совершенно согласен. Но они сть и это факт. В данном случае человек запатентовал алгоритм и намеренно выложил его имплементацию в общий доступ, т.е. фактически защитил нас от патентных троллей. Не вижу в этом ничего плохого.
Во-вторых, расскажите плз про более эффективные алгоритмы, я совсем не против еще более улучшить и демона, и скрипты.
Задача такая: хранить много не очень больших (макс. десятки тысяч элементов) списков интов, по которым надо быстро проходить и по которым должны быть быстрые лукапы. Ну, и памяти они должны занимать минимум, конечно.
На данный момент это всё реализовано на Judy1.
В-третьих, да, вещи довольно очевидные, но я и не претендую на открытие Америки. С другой стороны, я уверен, что большинство про Judy не слышали и с удовольствием посмотрят на красивые диаграммки и узнают про новый инструмент.
Все аналогично штатным массивам: $judy[] = $value; $value = $judy[0];
Только здесь жестко фиксирован тип индексов и значения элементов ограничены соотв-м типом.
В айпаде патентованный прямоугольник не смущает? :)
А LGPL или нет — разница большая. Авторы, конечно, могут сменить лицензию на свой код, но не задним числом. А значит, этот код всегда будет публично доступен под LGPL.
Ну и накатили утром, так чтоб весь день держать руку на пульсе.
Единственная проблема — исходное изображение в JPEG, поэтому за трафик приходится платить CPU при перекодировании (ну или хранить и JPEG, и WebP рядом).
Эта книга слабая, имо, но из-за канвы сюжета (вау! США проиграли войну!) очень популярна «у них», судя по всему.
А вот Убик я б экранизировать не стал — зрителям тогда придётся принимать что-то сильнодействующее перед просмотром, чтоб быть «на одной волне» с автором.
Кроме того, есть ещё некий lockless allocator. Сам пока не пробовал, но их бенчмаркинг утверждают, что он даже лучше Jemalloc: locklessinc.com/
WiFi, питание, все есть.
Про крышу поспрашиваю, но сомневаюсь.
А можно узнать зачем?
Предполагалось, что существующие виды отчетов как раз вот такие случаи все должны решать.
Если не решают, то либо вы что-то не так делаете, либо вам не хватает какого-то функционала. Вопрос — какого?
Кстати, недавно добавились еще медиана, произвольные перцентили по времени запроса + т.н. «гистограмма» частот (т.е. можно посмотреть «внутрь» среднего числа и построить графики распределения времени запроса, например).
Pinba изначально предназначалась для автоматического сбора и агрегации данных с множества серверов.
Плюс в неё с самого начала закладывались таймеры, который позволяют засекать время определённых участков кода и строить агрегированные отчеты уже по операциям, а не по запросам.
>При этом не используется база данных и не добавляется лишний код в обработку каждого реквеста.
Если не использовать таймеры, то ничего не добавляется, вся статистика собирается и отсылается автоматом (в PHP. Хотя и в других языках тоже наверняка).
Вопрос к нему.
Спасибо, добавил ссылку на pinba.org.
Набор патчей с подобным функционалом начал делать Владимир Вологжанин еще в Мамбе, хотя идея была Андрея.
В какой-то момент Андрей это всё сам переписал и выложил под GPL.
Поскольку GPL несовместима с PHP License (верней наоборот, но не суть), я уговорил Андрея поменять на что-то более permissive, немного подправил и патч предложил в PHP Core.
Патч приняли и теперь оно живёт своей жизнью.
Все вышеупомянутые люди (включая меня) работают в Баду и сейчас, если вам интересно.
Кстати, с Геррита мы уже ушли на самописное решение для review + интеграцию с Jira.
Судя по опыту людей, они всё-таки какие-то флаги добавляют, которые в документации отсутствуют:
groups.google.com/d/msg/pinba-engine-ru/mQDa18eup-c/8NUPyWoITpoJ
Поэтому, как возможно решение, можно собрать самому и то, и другое из исходников.
>и нужно понять, входит ли данное число в n-ное множество?
Да, но еще надо проходить по этому множеству от начала до конца и чтобы это множество занимало минимум памяти.
Решение меня интересует не на PHP, конечно, а на С — мы же ищем более эффективный алгоритм, чем Judy.
То есть, да, софтварные патенты — зло и всё такое, я совершенно согласен. Но они сть и это факт. В данном случае человек запатентовал алгоритм и намеренно выложил его имплементацию в общий доступ, т.е. фактически защитил нас от патентных троллей. Не вижу в этом ничего плохого.
Во-вторых, расскажите плз про более эффективные алгоритмы, я совсем не против еще более улучшить и демона, и скрипты.
Задача такая: хранить много не очень больших (макс. десятки тысяч элементов) списков интов, по которым надо быстро проходить и по которым должны быть быстрые лукапы. Ну, и памяти они должны занимать минимум, конечно.
На данный момент это всё реализовано на Judy1.
В-третьих, да, вещи довольно очевидные, но я и не претендую на открытие Америки. С другой стороны, я уверен, что большинство про Judy не слышали и с удовольствием посмотрят на красивые диаграммки и узнают про новый инструмент.
Только здесь жестко фиксирован тип индексов и значения элементов ограничены соотв-м типом.
А LGPL или нет — разница большая. Авторы, конечно, могут сменить лицензию на свой код, но не задним числом. А значит, этот код всегда будет публично доступен под LGPL.