зависит от текущих задач. В том то и прелесть наличия отдельного стореджа. завтра ваша задача поменяется, вы меняете структуру "горячих данных", при этом процесс записи остается неизменным.
Например: сегодня вам нужно показывать диалоги (основной пост + комментарии), завтра туда добавляются лайки и репосты, послезавтра вы начинаете анализировать темы диалогов и предлагать в них же обсудить тему с заинтересованными людьми.
у монги есть один не приятный нюанс для вашей задачи. В будущем с высокой вероятностью вам прийдется каким-либо образом строить агрегацию данных ваших диалогов, и тогда при любом построении структуры коллекций прийдется делать map/reduce, что у монги получается не очень. Исходя из этих тезисов, я бы посоветовал хранить данные по старинке в чем нибуть реляционном, а горячие данные вливать во что-нибуть простое типа Redis или производных. Такой подход позволит и не проиграть в производительности и избежать проблем в дальнейшем развитии проекта.
P.S. когда то тоже страдал монгой, но потом пришло осознание, что для более менее сложного проекта без РСУБД никуда не деться:)
одна из немногих полнофункциональных иде, точеных именно под js стек. + большой набор плагинов под специфичные нужды, больше комьюнити, регулярные обновления.
семерку вы активируете старым (семерочным), потом ставите сверху восьмерку и вводите ваш ключ. Если не пускает, значит какие то проблемы, обращайтесь в саппорт.
Работал на нем с базой товаров (естественно смешеный русский и английский языки), кроме полнотекстового поиска еще использовался как быстрая временная база данных для фронта. Никаких проблем с базой товаров (с огромным количеством предложений в каждом, хранящимся в виде вложенного массива + атрибуты) размером около 3 с половиной милионов записей не наблюдалось. Морфологический поиск работал так же стабильно.
данные воркерам можно отдать прямо в теле задачи. А синхронные методы gearman позволяют дернуть колбек с результатом, пришедшим от воркера. Посчитайте сколько задач отправили, посчитайте сколько колбеков словили — работаете дальше.
удаляемый файл имеет числовое имя со стандртным расширением, но при удалении в событии выскакиевает некое .fuse_hidden вместо имени. Это происходит не всегда, зависимости найти не могу, возможно к этому файлу идет обращение, сейчас не могу отследить. Прошу прощения за неточный вопрос
насколько я помню у него были проблемы с поддержкой виртуальной среды и его рекомендовали только для использования на реальном железе, но может уже все поменялось, не буду утверждать. Но всеже интересно как вы собираетесь этим набором тестов гонять апач.
при этом вы помечаете решением ответ про ab) самый простой вариант если вы хотите так заморочаться и не тестировать просто железо, что было бы намного логичнее — форкнуть какой-либо опен-сорс проект, использующий данную связку, забить базу и тогда юзать ab или siege, или же в вашей постоновке вопроса, ответ звучит «никак»
производительность софта зависит только от физических составляющих и пытаться нагрузить веб-сервер отдачей статики глупо, т.к. при фактической огромной разнице в производительности двух машин, результат теста будет примерно одинаковым и первое, во что вы упретесь при таком тесте это ширина канала
Если вы тестируете производительность апача на отдачу статической страницы «It works», то ни в ab, ни в siege смысла вообще нет, вам нужно отдельно протестировать производительность важных для вас физических состовляющих сервера(обычно цпу, оп, канал, если будете раздавать статику — производительность диска) и сравнить результат со своими другими vm. Тулзы для теста каждой составляющей не подскажу, т.к. давно не интересовался, гугл думаю быстро сможет найти
Последняя идея вполне ничего. Вы начните, а потом и планы развития появятся и скучно точно не будет=) Вы же сами писали, что это фан, значит по поводу коммерческой рентабельности заморачиваться не стоит
Например: сегодня вам нужно показывать диалоги (основной пост + комментарии), завтра туда добавляются лайки и репосты, послезавтра вы начинаете анализировать темы диалогов и предлагать в них же обсудить тему с заинтересованными людьми.