Может писать просто в базу ? Потери те же по времени.
Если запись в базу и запись в кэш одинаковы, зачем тогда кэш? Судя по формулировке имеются проблемы в архитектуре, а не многопоточности в кэше. И нужно задуматься, откуда возникла тема с многопоточкой и нужна ли она вообще? Если есть проблемы с неконсистентностью данных, то нужно понимать, что их не решит ни кэш, ни база.
@webvany как инженер и практик связанный с бизнесом меня в первую очередь интересуют оптимальные решения. Если завтра окажется, что разработка в конкретной локации обойдется дешевле (сильно подозреваю, что такое может иметь место в Ульяновске) на языке Х, то именно на таком языке и будет новый проект.
Так что это не отзыв, а просто мнение прагматика.
Хабр, тостер на пхп, остальное на руби. Подробнее тут. Кстати, обращаю внимание на ответ Дениса. Выбор языка обусловлен имеющимся в наличии разработчиками, а не самим языком. Ибо в первом приближении основные мейнстримовые языки схожи, и требуемую разработчикам инфраструктуру обеспечивают фрейворки.
@0whitewolf0 касательно CodeIgniter из личного опыта не скажу. Те, кто его юзают говорят, что проект не очень живой. Лично для себя поняв, что на разработку и супорт админки уходит много времени остановился на Yii.
@VovanZ тут налицо неправильные выводы и наблюдей. На CMS треш и угар обусловлен не их архитектурой, а, как я уже говорил, людьми работающие с ней. Коробочные CMS зачастую удел вебмастера - человека близкого к программингу, но задастую программистом не являющегося. Он что-то может докрутить в админке, что-то скопипастить модулями и даже что-то может написать сам. Но на том же фрейворке он работать не станет, потому что просто не умеет. С фрейворком же начнет работать человек с каким ни каким, но опытом и даже весьма вероятно уже сформировавшийся культурой написания кода (которая (!!!) не обусловлена архитектурой самого фрейворка).
Могу так абсолютно точно утверждать на примере сапорта сайтов арбитражных судов базирующихся на Drupal. Треш да, угар да, содомия конечно. Но если к этому правильно подойти, то потом даже джуниоры начинают писать вполне аккуратный поддерживаемый код.
Поэтому структуру и архитектуру заставляет себя соблюдать сам разработчик либо его наставник/тимлид. На чем при этом пишется проект совершенно не важно.
1. Нифига не заставляет ("не обходится без говнокода, костылей, косяков архитектуры"). Это зависит от конкретного разработчика и мало связанно с используемой системой.
@nepster09 А смысл? Дерево не перестроили, делать по нему нормальные выборки нельзя. Почему кстати выбран NS? И откуда такое большое дерево? Мне слабо вериться, что к вам бежит регаться миллион юзеров. Преждевременная оптимизация зло. Нужно исходить из реального размера дерева, его ветвистости и требований быстроты выборки. Может оказаться, что AL или MP будут для задачи более оптимальными. Не говоря уже про возможные модификации в духе разряженного NS.
Как и любой persistent connection (например, в postgresql) он дает выигрышь в случае когда операция установление соединения долгая. В контексте данной задачи сервер с redis-ом может работать по tcp с удаленной машины. Тогда из-за накладных tcp расходов выигрышь от постоянного соединения будет. В случае же работы по unix socket большого прироста мы не получим ввиду мизерности накладных расходов на установку коннекта.
Неплохо. @nazarpc, а в какой момент начинается измерение и в какой считается законченным? Я вот использую access лог nginx-а, он может записывать время ответа бэкэнда. Кстати, для нагрузочного тестирования лучше использовать httperf
@Rhaps107 какой вопрос, такой и ответ ) Вопрос был во времени получении ключа, а не оптимизации скорости работы скрипта. К примеру, у меня движок от самого начала работы до самого конца работы (честное начало и окончание) отрабатывает за ~7-30 мс.
Если запись в базу и запись в кэш одинаковы, зачем тогда кэш? Судя по формулировке имеются проблемы в архитектуре, а не многопоточности в кэше. И нужно задуматься, откуда возникла тема с многопоточкой и нужна ли она вообще? Если есть проблемы с неконсистентностью данных, то нужно понимать, что их не решит ни кэш, ни база.