Высокая производительность → In-memory-data-grid. Режимы работы, индексы, блокировки
Я продолжаю небольшой цикл статей на тему In-memory-data-grid.
В первой статье была раскрыта сама концепция IMDG без конкретных примеров и деталей реализации. Сегодня мы копнем чуть глубже.
В первой статье была раскрыта сама концепция IMDG без конкретных примеров и деталей реализации. Сегодня мы копнем чуть глубже.
Высокая производительность → In-memory-data-grid. Масштабируемые хранилища данных из песочницы
В последнее время интерес к облачным архитектурам растет с каждым днем, так как это один из наиболее эффективных способов масштабировать приложение, не прикладывая больших усилий, а самым узким местом любого высоконагруженного проекта является хранилище данных, в частности реляционная БД. Для борьбы с недостатками традиционных БД в основном используется 2 подхода:
1) Кэширование результатов выполнения запросов
2) NoSQL решения
Сегодня я хочу познакомить вас с таким типом хранилища данных, который объединяет достоинства обоих подходов и при этом имеет ряд преимуществ перед упомянутыми выше решениями: In-memory-data-grid (IMDG).
1) Кэширование результатов выполнения запросов
- плюсы: высокая скорость доступа к данным
- минусы: требует компромисса между актуальностью данных и скоростью доступа, т.к. данные в кэше могут устареть, а удалять старые данные из кэша с последующим кэшированием новых — это дополнительные задержки и нагрузка на систему
2) NoSQL решения
- плюсы: хорошая горизонтальная масштабируемость, доменная модель данных совпадает с моделью хранения данных
- минусы: низкая скорость получения результатов в случае использования диска, практически невозможно обеспечить работу внутрикорпоративного софта, который ориентирован на работу с конкретной реляционной БД.
Сегодня я хочу познакомить вас с таким типом хранилища данных, который объединяет достоинства обоих подходов и при этом имеет ряд преимуществ перед упомянутыми выше решениями: In-memory-data-grid (IMDG).
Веб-разработка → Простой дополнительный контроль состояния данных memcached
Мониторинг memcached — дело далеко не последней важности. Как на этапе тестирования, так и на этапе сопровождения уже работающего нагруженного ресурса. Средств «из коробки» для этого не так уж и много, а если вы работает с PHP, то зачастую ограничиваетесь средствами memcache (или memcached), а именно Memcache::getStats()
$memcache = new Memcache;
$memcache->connect('localhost',11211);
print_r($memcache->getStats());
что возвращает типичный набор данных
Array ( [pid] => 25722 [uptime] => 4487286 [time] => 1308323074 [version] => 1.2.2 [pointer_size] => 64 [rusage_user] => 2646.005365 [rusage_system] => 17108.873237 [curr_items] => 37761 [total_items] => 10764857 [bytes] => 140070186 [curr_connections] => 5 [total_connections] => 17360659 [connection_structures] => 31 [cmd_get] => 89154830 [cmd_set] => 10764857 [get_hits] => 83452021 [get_misses] => 5702809 [evictions] => 0 [bytes_read] => 3527860756618 [bytes_written] => 4234517241183 [limit_maxbytes] => 2147483648 [threads] => 1 ) Вроде всё хорошо.
Мы видим, что у нас занято 133,5 Mb из 2 Gb выделенных под memcached и около 37 тыс. ключей.
Hits к misses относиться как 83/5, что тоже не внушает опасений.
Высокая производительность → Введение в шаблонизатор Blitz
Из документации о Blitz: Чрезвычайно быстрый и мощный шаблонизатор для очень больших интернет-проектов.
Приведу несколько фактов:
Приведу несколько фактов:
- Это шаблонизатор используемый Хабром;
- Этот шаблонизатор используется на высоко-нагруженных проектах, он написан на C, подключается как расширение PHP;
- Его скорость сопоставима с самим php (бенчмарк под катом);
- Верстальщики будт счастливы, так как в шаблонах нет логики приложения, нет циклов, ветвлений и т.д.;
- Один из его авторов Алексей Рыбак fisher.
Персональные блоги → язык программирования M, он же MUMPS, ДИАМС. параллельная обработка
! привет
.свою сагу начну с упоминания моего учителя и профи языка программирования М и удивительного друга Александра Велиева который ведёт сайт www.cgi2m.net.ua откуда я и копирую со своими комментариями его статью
Я счастлив, что М успешно справился с новым вызовом времени — параллельной обработкой.
Это новейший и абсолютно иной вид программистского мышления.
Начало этой истории — зима 2006 года.
Знакомая попросила для брата-студента книгу о Прологе.
Я разыскал Пролог-библию Братко и наконец решил её прочесть снова.
В ней я прочёл, как элегантно Братко нашёл алгоритм наибольшего общего делителя без вычислений.
Это решение было настолько элегантно, что я решил написать что-либо подобное в М.
Я написал программу на бумаге и боялся её запустить.
Как старый мумпсер я знал о строгих ограничениях на количество подпроцессов и не мог оценить размера базы данных, который для этого понадобится.
Я не хотел начинать испытания такой элегантной и мощной программы с таких вещей, как крах базы данных или отказ компилятора.
Но узнав GT.M лучше, я начал сомневаться в своих сомнениях и решил попросить совета на comp.lang.mumps.
Сразу же г-н. K.S.Bhaskar ответил мне.
Благодаря его советам и поддержке я смог её успешно испытать. Вот код:
Испытания этой программы в GT.M было успешным — об этом Вы можете прочесть на форуме comp.lang.mumps.
.свою сагу начну с упоминания моего учителя и профи языка программирования М и удивительного друга Александра Велиева который ведёт сайт www.cgi2m.net.ua откуда я и копирую со своими комментариями его статью
:: Параллельная обработка :.
Я счастлив, что М успешно справился с новым вызовом времени — параллельной обработкой.
Это новейший и абсолютно иной вид программистского мышления.
Как я боялся своей программы
Начало этой истории — зима 2006 года.
Знакомая попросила для брата-студента книгу о Прологе.
Я разыскал Пролог-библию Братко и наконец решил её прочесть снова.
В ней я прочёл, как элегантно Братко нашёл алгоритм наибольшего общего делителя без вычислений.
Это решение было настолько элегантно, что я решил написать что-либо подобное в М.
Я написал программу на бумаге и боялся её запустить.
Как старый мумпсер я знал о строгих ограничениях на количество подпроцессов и не мог оценить размера базы данных, который для этого понадобится.
Я не хотел начинать испытания такой элегантной и мощной программы с таких вещей, как крах базы данных или отказ компилятора.
Но узнав GT.M лучше, я начал сомневаться в своих сомнениях и решил попросить совета на comp.lang.mumps.
Сразу же г-н. K.S.Bhaskar ответил мне.
Благодаря его советам и поддержке я смог её успешно испытать. Вот код:
;Эта программа создаёт численные ряды ;a - простые числа(делятся на 1 и себя) ;b - ряды делителей ;c - ряд простых чисел example ; k ^a,^b,^c,^pid s Lim=1000000,^p=0,h1=$h f i=2:1:Lim s ^a(i)=i s (i,^c(1))=1 f s i=$o(^a(i)) q:i="" d .j a(i,Lim)::0 i d c .e d a(i,Lim) w Lim,i,! s h2=$h zwr q a(v1,v2) s ^pid($j)=,(^b(v1,v1),^c(v1))=v1,c=v1+v1 i c<v2 f n=c:v1:v2 k ^a(n) s (^b(v1,n),^c(n))=n k ^pid($j) q c k p m p=^pid s c="" f s=0:1 s c=$o(p©) q:c="" s c=$g(p) s:c<s ^pid=s w P ,i, ,s, ,c,! q
Испытания этой программы в GT.M было успешным — об этом Вы можете прочесть на форуме comp.lang.mumps.