1. Мой код не идеален, уже двое заметили, за что им отдельная благодарнгсть
2. Задача часто встречаемая, может кому пригодится
3. Выложил исходники, может кто-то
а) сделает хорошие замечания/исправления
б) напишет плагин для другого стоража
Если плагигнов будет 2-3, то можно сделать фабрику и загружать их через конфиг. А пока что нет смысла городить огород, если это решение одного проекта.
помню это выступление на РИТе, где Лайвинтернет рассказывал, как на IV пне запустил свой подсчетчик кликов, написанный на си, который выдерживал несколько миллионов запросов.
я комментировал выше.
у меня была идея хранить все в map/SLT но мне показалось что 3-5 млн это достаточно большой хеш. Хотя попробую написать сторадж и для map/STL, а в случае сбоя/перегрузки — весь хеш грузить из БД или файла.
Была идея использовать FastCGI, но с libevent был уже опыт работы по этому сделали данное решение.
Что за решение на php такое, что давало задержку 1.5-2с?
ну не 1,5-2 а 0.5-1 сек, все равно не приятно.
там достаточно кривостей было, это я согласен. Сервер был перегружен,
Было использовано решение — принимать PHP скриптом и ложить в лог.
По крону каждые 15 мин забирать из лога и класть в БД. Но, в новом проекте данное решение не устраивает.
есть два необузданных коня: тарантул и кайот, которые могли бы занять место memcachedb.
1) проверенное решение в других проектах
2) key/value
3) занимает столько памяти, сколько выделим
4) достаточная производительность
5) устойчиво в случае сбоя или перегрузки, в отличие от memcache
можно было заморочиться с написанием собственного стораджа, но это имеет место если кол-во возможных переходов не столь велико (десятки тысяч)
Если их более 1 млн, то лучше использовать существующие решения
интересно сколько элементов пихали в мемкеш?
нормальное выступление, не переживай
другого выхода нет, мы не знаем длинну принимаемого сообщения. если прочесть более большой блок, то программа зависнет в ожидании данных.
а чем он плох,
меня он устраивает, находит ошибки на уровне чтения ini — файла с указание номера линии. в качестве генератора кода использован re2c.
согл
а что тут парсить-то. простой цикл… зачем тянуть посторонние либы.
спасибо за комменты учту
2. Задача часто встречаемая, может кому пригодится
3. Выложил исходники, может кто-то
а) сделает хорошие замечания/исправления
б) напишет плагин для другого стоража
Если плагигнов будет 2-3, то можно сделать фабрику и загружать их через конфиг. А пока что нет смысла городить огород, если это решение одного проекта.
она проксирование допускает?
если да, то не проблема запустить и в ноде.
доработку и останется время на рефакторинг!
можешь присоединиться, дам доступ в гит
что верно, то верно…
рефакторить и рефакторить,
много кусков взято из более ранних проектов.
у меня была идея хранить все в map/SLT но мне показалось что 3-5 млн это достаточно большой хеш. Хотя попробую написать сторадж и для map/STL, а в случае сбоя/перегрузки — весь хеш грузить из БД или файла.
Была идея использовать FastCGI, но с libevent был уже опыт работы по этому сделали данное решение.
мои тесты показали что 1100 — 1200 HTTP запросов в сек — это норма.
ну не 1,5-2 а 0.5-1 сек, все равно не приятно.
там достаточно кривостей было, это я согласен. Сервер был перегружен,
Было использовано решение — принимать PHP скриптом и ложить в лог.
По крону каждые 15 мин забирать из лога и класть в БД. Но, в новом проекте данное решение не устраивает.
спасибо за комментарий.
так что, если будут какие предложения, то могу доработать.
было бы меньше миллиона, вполне можно было замутить что-то своё
с РНР время отклика не устраивало.
при данной схеме, можно вполне обойтись и без PHP
напрямую класть из nginx в мемкешQ (есть такой модуль)
1) проверенное решение в других проектах
2) key/value
3) занимает столько памяти, сколько выделим
4) достаточная производительность
5) устойчиво в случае сбоя или перегрузки, в отличие от memcache
Если их более 1 млн, то лучше использовать существующие решения