текут в основном системные либы, используемые в экстеншенах,
У меня демон неделями висит без перезагрузки и мониторинг показывает ровную прямую,
так что, используем те либы, которые не текут.
ы отправляете udp-пакеты, т.е. «записал — забыл». Это неблокирующая операция, и она очень быстрая. Очередь, организована ли она у вас на gearman/rabbitmq/чем-то ещё, будет работать в разы медленнее
Если исп rabbitmq то это будет медленнее за счет избыточности протокола AMQP
и реализации rabbitMq на блокируемых соединениях
сбор статистики всегда предполагает какой-то оверхед собственно на сам
в пинба это решено путем отправления пакета в демон сбора статистики уже по окончанию отработки скрипта в RSHUTDOWN
а какая схема используется у Вас и каковы накладки?
Так nosql как раз и придумали для простых веб-приложений, где целостность и транзакционность не нужна :-)
Транзакционность поддерживается в ряде NoSQL
иначе не вылезла бы CAP ...
Серьезные бизнес-платформы будут жить на ACID-принципах, выполнять сложные выборки и надежно фиксировать транзакции, связанные с деньгами клиентов.
это верно, но выборки вероятно можно упростить, или некоторые из них подготовить заранее :), а вот от транзакций связанных с платежами конечно не скрыться. И в этом месте безусловно можно пожертвовать производительностью. И Я был бы безмерно счастлив, если бы платежные транзакции на моем сервисе совершались хотя бы раз в секунду! Я даже готов отдавать стр «проведения платежа» за 0.98 сек. Да при таком потоке бабла исключительно только для «страницы проведения платежей» я готов забашлять выделенный сервер или даже два, если один не будет справляться…
Компонент Model (самый ресурсоемкий): Если мы говорим об электронном магазине, то не закешированная страница электронного каталога, используя sphx +первичный ключ БД вполне может полностью сформировать данные за 0.2-2ms
если мы начнем наворачивать ORM то отдача возрастет до 140ms и более…
и это к сожалению правда жизни.
Компонент View: Хотите быстро формировать контент — не используйте стандартные шаблонизаторы. Мы предварительно «компилим» шаблоны в шаблонную строку, а потом просто используем sprintf который формирует необходимый контент методом подстановки. А разве шаблонизаторы работают не так???
И это работает даже быстрее чем блиц alexeyrybak.com/blitz/blitz_ru.htm
Я трейсил шаблонизатор. Он составляет до 1-2% времени формирования стр. Это еще может сэкономить 0.5-3 ms (в зависимости от сложности шаблонной логики и используемого шаблонизатора)
Компонент: Controller. мы используем nginx в качестве контроллера. Он разруливает урлы и в параметре page fastCGI переменной передает имя класса, который нужно подгрузить. На этом экономим еще 1-2 ms.
Конечно со всем этим хозяйством геморой: нужно запускатиь скрипты компиляции шаблонов и настройки конфигов nginx перед дистрибьюцией продукта или после апдейта…
хотя это делается в большинстве «простых» архитектур.
Но можно делать «правильно», а можно делать быстро
я рассказал как можно сделать быстро. Возможно есть пути сделать еще быстрее…
Я не использовал Битрикс, видел его исходники (20М) лишь десятилетней давности (знаю что сейчас уже многое соптимизированно и переписано да и самому стыдно за тот код, который я писал 5 лет назад), я не могу ни чего сказать плохого про этот продукт, Сергея Рыжкова знаю лично, возможно он меня тоже вспомнит при встречи.
То, что его продукт хорошо продается — это его большая заслуга. Значить он (продукт) полностью покрывает потребности клиентов и приносит им пользу. Трудно сделать полностью универсальное коробочное решение, удовлетворяющее все потребности.
Могу еще раз подтвердить, что в данной статье есть полезные советы и мысли…
конкретно по сторажу проблем не было, так как использоват реализацию tree из Tokyo
если не считать проверки на балансировку дерева по истечения интервала или выполнение DELETE > 10%
заморочки получились в правильной обязке libevent работающей на n потоков. в общем до ума на 100% не довел, а познакомился с Тарантулом, понял что он именно то что мне нужно и эффективнее моего сторожа и забил. В итоге приобрел хороший опыт.
Что касается блокировок, то в случае INSERT/DELETE просто делал блокировку через mutex.
на очень больших нагрузках не тестировал, но синтетические тесты показали не плохую производительность. Возможно и стоило довести до ума…
на мой взгляд
1) сериализацию можно реализовать, это совсем не трудно, но надо понимать, что всякая сериализация/десерриализация — это время… как минимум O(n)
2) если хранилище сделать персистентным, то смысла в сериализации я не вижу, так как в основном сериализация используется, как передача данных между циклами обработки как правило одного приложения. Как раз тема персистентного хранилища. Если приложений несколько, и на разных языках (не удивительно и такое встречается), то использование данного вида сериализации вообще не имеет смысла, так как эта хреновина будет либо PHP-only. Либо если делать в виде отдельного демона — то это уже велосипед аналогов Тарантула или Токио. А оно надо? Лучше все равно не сделаешь. Хотя у меня были попытки www.slideshare.net/akalend/treedb-keyvalue-nosql-database
и даже не плохие: см. слайд 17 (производительность). Но уперся в ряд прочих проблем…
так что из всего вышеизложенного словоблудия я вижу следующий смысл:
— если реализовывать, то только как персистентное хранилище shmap
— реализовать как класс (несколько классов: map, hash, queue, list,? )
— Implements Irerator или ArrayIterator, чтоб можно было использовать в конструкции foreach
— Serialize/Unserialize ????? или hash2array/array2hash, map2array/array2map etc…
У меня демон неделями висит без перезагрузки и мониторинг показывает ровную прямую,
так что, используем те либы, которые не текут.
и обработка сигналов
и таймер
и TCP общение (клиент и сервер ) в обном флаконе
и реализации rabbitMq на блокируемых соединениях
в пинба это решено путем отправления пакета в демон сбора статистики уже по окончанию отработки скрипта в RSHUTDOWN
а какая схема используется у Вас и каковы накладки?
service mydaemon start
SIGHUP — перезагрузка конфигурации — рестарт
SIGTERM — мягкое завершение без потери данных
спасибо за ценную информацию
это можно было реализовать и на чистом си.
иначе не вылезла бы CAP ...это верно, но выборки вероятно можно упростить, или некоторые из них подготовить заранее :), а вот от транзакций связанных с платежами конечно не скрыться. И в этом месте безусловно можно пожертвовать производительностью. И Я был бы безмерно счастлив, если бы платежные транзакции на моем сервисе совершались хотя бы раз в секунду! Я даже готов отдавать стр «проведения платежа» за 0.98 сек. Да при таком потоке бабла исключительно только для «страницы проведения платежей» я готов забашлять выделенный сервер или даже два, если один не будет справляться…
Компонент Model (самый ресурсоемкий): Если мы говорим об электронном магазине, то не закешированная страница электронного каталога, используя sphx +первичный ключ БД вполне может полностью сформировать данные за 0.2-2ms
если мы начнем наворачивать ORM то отдача возрастет до 140ms и более…
и это к сожалению правда жизни.
Компонент View: Хотите быстро формировать контент — не используйте стандартные шаблонизаторы. Мы предварительно «компилим» шаблоны в шаблонную строку, а потом просто используем sprintf который формирует необходимый контент методом подстановки. А разве шаблонизаторы работают не так???
И это работает даже быстрее чем блиц alexeyrybak.com/blitz/blitz_ru.htm
Я трейсил шаблонизатор. Он составляет до 1-2% времени формирования стр. Это еще может сэкономить 0.5-3 ms (в зависимости от сложности шаблонной логики и используемого шаблонизатора)
Компонент: Controller. мы используем nginx в качестве контроллера. Он разруливает урлы и в параметре page fastCGI переменной передает имя класса, который нужно подгрузить. На этом экономим еще 1-2 ms.
Конечно со всем этим хозяйством геморой: нужно запускатиь скрипты компиляции шаблонов и настройки конфигов nginx перед дистрибьюцией продукта или после апдейта…
хотя это делается в большинстве «простых» архитектур.
Но можно делать «правильно», а можно делать быстро
я рассказал как можно сделать быстро. Возможно есть пути сделать еще быстрее…
Я не использовал Битрикс, видел его исходники (20М) лишь десятилетней давности (знаю что сейчас уже многое соптимизированно и переписано да и самому стыдно за тот код, который я писал 5 лет назад), я не могу ни чего сказать плохого про этот продукт, Сергея Рыжкова знаю лично, возможно он меня тоже вспомнит при встречи.
То, что его продукт хорошо продается — это его большая заслуга. Значить он (продукт) полностью покрывает потребности клиентов и приносит им пользу. Трудно сделать полностью универсальное коробочное решение, удовлетворяющее все потребности.
Могу еще раз подтвердить, что в данной статье есть полезные советы и мысли…
спасибо за подсказку xhprof- буду курить!
2 сек на запрос — это жесть! мой HiLoad 5-7 ms — это норма.
если не считать проверки на балансировку дерева по истечения интервала или выполнение DELETE > 10%
заморочки получились в правильной обязке libevent работающей на n потоков. в общем до ума на 100% не довел, а познакомился с Тарантулом, понял что он именно то что мне нужно и эффективнее моего сторожа и забил. В итоге приобрел хороший опыт.
Что касается блокировок, то в случае INSERT/DELETE просто делал блокировку через mutex.
на очень больших нагрузках не тестировал, но синтетические тесты показали не плохую производительность. Возможно и стоило довести до ума…
1) сериализацию можно реализовать, это совсем не трудно, но надо понимать, что всякая сериализация/десерриализация — это время… как минимум O(n)
2) если хранилище сделать персистентным, то смысла в сериализации я не вижу, так как в основном сериализация используется, как передача данных между циклами обработки как правило одного приложения. Как раз тема персистентного хранилища. Если приложений несколько, и на разных языках (не удивительно и такое встречается), то использование данного вида сериализации вообще не имеет смысла, так как эта хреновина будет либо PHP-only. Либо если делать в виде отдельного демона — то это уже велосипед аналогов Тарантула или Токио. А оно надо? Лучше все равно не сделаешь. Хотя у меня были попытки www.slideshare.net/akalend/treedb-keyvalue-nosql-database
и даже не плохие: см. слайд 17 (производительность). Но уперся в ряд прочих проблем…
так что из всего вышеизложенного словоблудия я вижу следующий смысл:
— если реализовывать, то только как персистентное хранилище shmap
— реализовать как класс (несколько классов: map, hash, queue, list,? )
— Implements Irerator или ArrayIterator, чтоб можно было использовать в конструкции foreach
— Serialize/Unserialize ????? или hash2array/array2hash, map2array/array2map etc…