правильнее, если это хайлоад:
картинку класть сразу на тот сервер (или два) откуда будет произведена отдача, далее в очередь поместить информацию о новом контенте.
постоянно мониторить очередь, например раз в сек и при наличие в ней элементов — запустить скрипт обработки ( ресайз + запись в БД) и делать это на отдельном сервере (как правило на том — который отдает статику)
В качестве сервера очередей у нас используется memcacheq
вместо хеша использую id
а для разных размеров расширенное имя:
012345.jpg — оригинал — возможно хранится в другой папке
012345_320x240.jpg
012345_640x480.jpg
тесты устарели, их надо менять. это кропотливая работа, но я это сделаю
Было бы хорошо, чтоб это сделал автор статьи, ты и так очень занят. А те кто давно используют блиц и без тестов знают, что он самый быстрый из всего доступного… Жаль, что Onk не хочет открывать свою поделку.
Могу ошибаться, но мне всегда казалось, что Андрей негативно отзывается о Smarty =)
Назови мне того, кто о нем отзывался не негативно…
Моя мысль была: использовать синтаксис приближенный к смарти, и я предложил свою помощь. Он более распростаненный, нежеле перловский HTML::Template
Конечно было бы хорошо увидеть его тоже в результатах тестирования.Несомненно, так как они одного класса…
сравнение со всеми РНРшными шаблнизаторами — это популизм. Достаточно одного смарти и еще одного-двух самый «быстрых»…
притом методология сравнения должна включать не только циклы, а:
— вложенность блоков
— инклуды
— калбэки
— плагины
в общем тут надо подумать… мне так «с неба» трудно что подсказать
потому что когда делались бенчмарки, проект ctpp как бы был за кадром. На то время — ctpp был не очень быстрым. Вроде как Шетухин его подправил и вторая версия пошустрее. У меня была идея, и Андрей был не против подправить синтаксис шаблонизатора в более приближенное к смарти. Но потом как-то мою идею не поддержало начальство и это дело заглохло.
1) Информация опоздала как минимум года на три…
2) это не самый быстрый шаблонизатор, есть быстрее, к сожалению автор его не хочет отдавать на ОпенСоурс
3) Говоря о блице, необходимо расказать об альтернативах, например cttp en.wikipedia.org/wiki/CTPP
4) хотелось бы услышать и недостатки… а то уж, слишком радужные впечатления.
у меня 1300 rps на ноуете 2.3 GHz 1Mg, но этого должно вполне хватить для обработки 10к
на продакшене процессор помощнее 4-8 ядер, памяти побольше, в общем должно быть еще быстрее.
сервер жрет 601К и 2 % CPU — даже смешно.
я про то, что если метод синхронный, то это заблокирует текущий поток, что бы не блокировалось все приложение, надо плодить потоки, правильно?
libevent библиотека с асинхронным ввод/выводом, т.е. использует неблокирующие сокеты. Все работает в одном потоке, только параллельно: как только приходит запрос на сокет, создается буфер и его начинает обрабатывать кэллбэк, если пришел еще один запрос, то новый буфер начинает обрабатывать следующий кэлбэк, если ответ от брокера не пришел, т.е буфер пуст, переходим к обработке следующего буфера и так проходимся по цепочке всех синициированных буферов. По окончанию работы кэлбека — буфер отдается в сокет и освобождается.
поллинг проще реализовывать и масштабировать. Из всего что я видел, я сделал вывод – все Comet решения слишком уж хакерские, изворотливые и очень тяжело масштабируются. Они плохо масштабируются, потому что web платформы построены на модели запрос-ответ.
я в своем проекте на nodejs написал мини прокси amqp -> long-poll, который по идее должен и 100к держать без проблем
честно говоря хз
до 10К надо еще мне дорости.
но вроде держать 10к не проблема? вот более 50к — это проблема.
Планирую commet-consume использовать. Пока с этим есть небольшие проблемки,
картинку класть сразу на тот сервер (или два) откуда будет произведена отдача, далее в очередь поместить информацию о новом контенте.
постоянно мониторить очередь, например раз в сек и при наличие в ней элементов — запустить скрипт обработки ( ресайз + запись в БД) и делать это на отдельном сервере (как правило на том — который отдает статику)
В качестве сервера очередей у нас используется memcacheq
сылка по теме www.grid.net.ru/nginx/upload.ru.html
php-webdav.pureftpd.org/project/php-webdav
а для разных размеров расширенное имя:
012345.jpg — оригинал — возможно хранится в другой папке
012345_320x240.jpg
012345_640x480.jpg
я сделал вывод, что на Хабре трудно что либо доказать, особенно если это связано с hiload. По этому на дискуссии уже стараюсь не поддоваться.
Но, спасибо, что заглянул…
Моя мысль была: использовать синтаксис приближенный к смарти, и я предложил свою помощь. Он более распростаненный, нежеле перловский HTML::Template
Конечно было бы хорошо увидеть его тоже в результатах тестирования.Несомненно, так как они одного класса…
сравнение со всеми РНРшными шаблнизаторами — это популизм. Достаточно одного смарти и еще одного-двух самый «быстрых»…
притом методология сравнения должна включать не только циклы, а:
— вложенность блоков
— инклуды
— калбэки
— плагины
в общем тут надо подумать… мне так «с неба» трудно что подсказать
хороший пост.
а проигрыш на кэлбэках.
хотя за статью — спасибо, очень приятно. Сам использую блиц в разных проектах года три-четыре.
2) это не самый быстрый шаблонизатор, есть быстрее, к сожалению автор его не хочет отдавать на ОпенСоурс
3) Говоря о блице, необходимо расказать об альтернативах, например cttp en.wikipedia.org/wiki/CTPP
4) хотелось бы услышать и недостатки… а то уж, слишком радужные впечатления.
спасибо
на продакшене процессор помощнее 4-8 ядер, памяти побольше, в общем должно быть еще быстрее.
сервер жрет 601К и 2 % CPU — даже смешно.
и вот еще одно мнение: amix.dk/blog/post/19414
интересно посмотреть
до 10К надо еще мне дорости.
но вроде держать 10к не проблема? вот более 50к — это проблема.
Планирую commet-consume использовать. Пока с этим есть небольшие проблемки,
спасибо за комментарий.