1. Если был хотябы 1 запрос к сереру то картинка уже не грузиться из системы
а отдаеться из памяти
if(image == undefined){
2. Считывание картинки обернуто в асинхронный метод
fs.stat('p.gif', function(err, stat) { // Проверяем существует ли файл
if (!err){ елси нет ошибки считываем и отдаем
image = fs.readFileSync('p.gif');
res.end(image);
}
else
res.end();
});
1) Как связана рекурсия со скоростью отдачи картинки, не совсем понятно.
напрямую
пример
получили GET запрос, вставили данные в базу, отдали картинку, закрыли соединение
и
получили GET запрос, отправили рекурсивный запрос на обработку данных(не ждем результата идем дальше) отдали картинку, закрыли соединение,
2) Если вы имели дело с высоко-нагруженными проектами то наверно замечали если какой то процесс сильно нагружает диск — то тормозит практически вся система
3) не получилось бы так у меня скрипт отстукивает с одной открытой страницы через каждый 15 (30 в зависимости от настройки) секунд — и если делать так как вы предлагает то ваш лог файла в конце дня будет весить десятки гигабайт а возможно и больше.
4) Готов поспорить с вами вы не напишете access_log за 15 секунд в нужном мне формате
Вы немного не поняли: оно собирает в памяти данные только на 1 просмотр. т.е если вы включили компьютер и оставили страницу открытую на целый день она будет собирать по вашем просмотру данные в память целый день.
Если вы открыли страницу и через минуту перейдете на другую страницу в nodeJS будут данные в памяти собираться по вашему просмотру только эту минуту и когда вы перейдете на другую страницу они вставятся в MongoDB.
P.S. Вру — целый день не будет собираться, сработает ограничение по времени 2 часа и данные вставятся а по вам будет считаться что вы закрыли страницу.
Nginx не скидывает буфер в файл (лог) после каждого запроса — это я знаю, тоже очень люблю nginx за его производительность.
Постараюсь найти ссылку на сравнительное тетсирование nodeJS и nginx. Хотя в принипе на отдаче однопиксельной картинки и самому не сложно его сделать. Там результаты должны быть очень похожими, другое дело что Nginx намного безотказней.
Это не ошибка проектирования — так было задумано — эти данные важны. Есть категория людей которые любят открывать сразу много вкладок в браузере даже могут в некоторых запустить видео плеер (выключить звук или поставить видео на паузу чтобы качалось) — инфа по этим пользователям также важно. И пользователь может открыть вкладку потом уйти с нее на другую страницу и потом вернуться.
Рекурсивен — имелось ввиду то что пользователю можно отдать заголовок 200 с телом ответа а данные по этому пользователю еще обрабатываются.
У меня данные не пишуться в базу при каждом HTTP запросе, они сначала агрегируються в памяти самого NodeJS и только когда перестают приходить новые данные вставляются в базу данных. Если вы заметили в статье пока у юзера открыта страница измененные даныне по нему приходят все время с заданным интервалом.
Да вроде бы как в новой так и в старой версии NodeJS он работает одинаково «Миллион одновременных соединений на Node.js» — можете почитать эту статью там автор делает замеры времени передачи тиков (они как раз этим методом отправляються)
NodeJs рекурсивен, задержка на отдачу этой картинки не больше чем у nginx
Если делать так как вы предлагаете то пришлось бы этот лог файл писать где-то в оперативной памяти иначе бы nginx на таком количестве запросов замучал бы HDD и загнулся.
Я не думаю что на написание парсера логов постройки всей системы на базе nginx ушло бы на много меньше времени чем на реализацию всего этого на NodeJS
Код воркера — 56 строк, код сервера ~ 100 — и это с описанием подключения библиотек, объявлением переменных, отступами и комментариями.
Мы его настраивали когда файлы MongoDB хранились на обычном жестком диске. Сам процесс Mongod жрал много ресурсов — сказывались задержки от HDD. Увеличили время стал жрать намного меньше только изредка всплески в момент сброса данных на диск. C переходом на SSD необходимость настройки этого параметра отпала
Медленнее, причем на много. Я в свое время делал такие эксперименты с php и Memcache
Memcache конечно очень быстр но не так быстро как nodeJS хранит у себя в памяти
Много вопросов. Постараюсь ответить на некоторые из них
1. journal'инг — выключен — потеря данных этой статистики за несколько минут для этого проекта не критична
Отказоустойчивость Node — если вы работали с ней то знаете что любая мелкая ошибка в дочерних потоках — валит этот поток, а если в головном то и весь веб-сервер.
Решали следующим образом в головном потоке мониторились дочерние потоки и в с случае падения рестартились.
На случай падения головного потока использовался forever — если сервер падал он тут же его рестартил и ошибку с которой он упал писал в лог
2. Есть внутренняя статистика она пишет какие то элементарные вещи по трафику, она доступна в режиме реального времени, та которую я в статье описывал агрегируется с интервал в 1 час — этого было вполне достаточно.
3. Большой трафик, гугл и так использовал сэмплирование для построение отчетов + приходило письмо от них с просьбе снизить нагрузку на их сервисы
4.Apache Storm / Hadoop/Spark не знаком с ними, не пишу на JAVA
Изначально был большой опыт написания различного кода на php/MySQL /JS / HTML
в nodeJS синтаксис JS по большей части поэтому выбор пал в ее сторону.
5. Каким образом вы обрабатываете ситуацию когда надо отправить некоторое событие, но юзер сразу же закрывает вкладку/переходит на другую страницу?
никак не обрабатываем, данные теряются, для нас не критично потому что важен не конкретный юзер а картина в целом. Если это критично то можно увеличить интервал оправки данных или отлавливать событие закрытия страницы и отправлять в этот момент данные.
6.Данные не буферизуем
7.Считаю что оправдано хранить в памяти — так они апдейтяться практически моментально — если конечно данные не слишком важные и раз в месяц потеря данных за 1 минуту не страшна.
8. Сам сайт и статистика на одном сервере — статистика потребляет всего несколько процентов ресусров. Видео хоститься на CDN
9. Если посещаемость возрастет прямо на порядок (что очень маловероятно, проект довольно старый) то аналитику перенесем на отдельный сервер.
PID — уникальное поле, оно должно идентифицировать уникальный просмотр. Генерируется на базе уникального id пользователя (он генерируется на базе IP и еще некоторой инфы) + текущей юникс метки, UAgent, разрешения экрана и некой случайной величины.
Открыли страницу создался PID, тут же обновили эту же самую страничку у вас абсолютно другой PID будет.
Генерируется в яваскрипте на странице пользователя, уникальный id пользователя приходит с сервера через куки
Сравнительные тесты MongoDb vs реляционные базы данных сам не делал (а давно хотелось)
В этом проекте до написания внешней статистики (под внешней я понимаю то что данные передаются из браузера посетителя) была внутренняя статистика в нее данные пишутся напрямую из движка сайта (данных гораздо меньше, и они апдейтят различные индексы в уже созданных документах)
При каждом открытии веб-страницы движок сайта по окончанию генерации ответа делал несколько запросов в MongoDB на апдейт счетчиков
документы в монге имели вложенную структуру.
Реляционная база не позволила бы сделать такое и так быстро апдейтить такое количество счетчиков.
Получается уже был опыт положительный опыт работы с MongoDB (она хорошо себя зарекомендавала) также уже умели строить отчеты по данным из MongoDB
Поэтому во внешней аналитике было решено задействовать ее. В ходе разработки не раз менялся набор данных которые мы сохраняли (при старте не было Окончательного ТЗ) — с монгой в этом плане очень удобное — не нужно менять структуру таблицы, просто добавляй нужные данные и все.
Соглашусь с вами что в той аналитике которую я описал в рамках статьи MongoDB не дает никаких весомых преимуществ, вполне возможно что Postgresql в чем то бы ее сделал. Одно точно скажу что с Postgresql гораздо быстрее бы строились отчеты (опыт работы с SQL гораздо больший чем с NoSQL).
а отдаеться из памяти
2. Считывание картинки обернуто в асинхронный метод
В 99.99% случаях картинка отдается из памяти
напрямую
пример
получили GET запрос, вставили данные в базу, отдали картинку, закрыли соединение
и
получили GET запрос, отправили рекурсивный запрос на обработку данных(не ждем результата идем дальше) отдали картинку, закрыли соединение,
2) Если вы имели дело с высоко-нагруженными проектами то наверно замечали если какой то процесс сильно нагружает диск — то тормозит практически вся система
3) не получилось бы так у меня скрипт отстукивает с одной открытой страницы через каждый 15 (30 в зависимости от настройки) секунд — и если делать так как вы предлагает то ваш лог файла в конце дня будет весить десятки гигабайт а возможно и больше.
4) Готов поспорить с вами вы не напишете access_log за 15 секунд в нужном мне формате
Если вы открыли страницу и через минуту перейдете на другую страницу в nodeJS будут данные в памяти собираться по вашему просмотру только эту минуту и когда вы перейдете на другую страницу они вставятся в MongoDB.
P.S. Вру — целый день не будет собираться, сработает ограничение по времени 2 часа и данные вставятся а по вам будет считаться что вы закрыли страницу.
Постараюсь найти ссылку на сравнительное тетсирование nodeJS и nginx. Хотя в принипе на отдаче однопиксельной картинки и самому не сложно его сделать. Там результаты должны быть очень похожими, другое дело что Nginx намного безотказней.
У меня данные не пишуться в базу при каждом HTTP запросе, они сначала агрегируються в памяти самого NodeJS и только когда перестают приходить новые данные вставляются в базу данных. Если вы заметили в статье пока у юзера открыта страница измененные даныне по нему приходят все время с заданным интервалом.
«Миллион одновременных соединений на Node.js» — можете почитать эту статью там автор делает замеры времени передачи тиков (они как раз этим методом отправляються)
Если делать так как вы предлагаете то пришлось бы этот лог файл писать где-то в оперативной памяти иначе бы nginx на таком количестве запросов замучал бы HDD и загнулся.
Я не думаю что на написание парсера логов постройки всей системы на базе nginx ушло бы на много меньше времени чем на реализацию всего этого на NodeJS
Код воркера — 56 строк, код сервера ~ 100 — и это с описанием подключения библиотек, объявлением переменных, отступами и комментариями.
Memcache конечно очень быстр но не так быстро как nodeJS хранит у себя в памяти
1. journal'инг — выключен — потеря данных этой статистики за несколько минут для этого проекта не критична
Отказоустойчивость Node — если вы работали с ней то знаете что любая мелкая ошибка в дочерних потоках — валит этот поток, а если в головном то и весь веб-сервер.
Решали следующим образом в головном потоке мониторились дочерние потоки и в с случае падения рестартились.
На случай падения головного потока использовался forever — если сервер падал он тут же его рестартил и ошибку с которой он упал писал в лог
2. Есть внутренняя статистика она пишет какие то элементарные вещи по трафику, она доступна в режиме реального времени, та которую я в статье описывал агрегируется с интервал в 1 час — этого было вполне достаточно.
3. Большой трафик, гугл и так использовал сэмплирование для построение отчетов + приходило письмо от них с просьбе снизить нагрузку на их сервисы
4.Apache Storm / Hadoop/Spark не знаком с ними, не пишу на JAVA
Изначально был большой опыт написания различного кода на php/MySQL /JS / HTML
в nodeJS синтаксис JS по большей части поэтому выбор пал в ее сторону.
5. Каким образом вы обрабатываете ситуацию когда надо отправить некоторое событие, но юзер сразу же закрывает вкладку/переходит на другую страницу?
никак не обрабатываем, данные теряются, для нас не критично потому что важен не конкретный юзер а картина в целом. Если это критично то можно увеличить интервал оправки данных или отлавливать событие закрытия страницы и отправлять в этот момент данные.
6.Данные не буферизуем
7.Считаю что оправдано хранить в памяти — так они апдейтяться практически моментально — если конечно данные не слишком важные и раз в месяц потеря данных за 1 минуту не страшна.
8. Сам сайт и статистика на одном сервере — статистика потребляет всего несколько процентов ресусров. Видео хоститься на CDN
9. Если посещаемость возрастет прямо на порядок (что очень маловероятно, проект довольно старый) то аналитику перенесем на отдельный сервер.
Поправлю в статье
Открыли страницу создался PID, тут же обновили эту же самую страничку у вас абсолютно другой PID будет.
Генерируется в яваскрипте на странице пользователя, уникальный id пользователя приходит с сервера через куки
В этом проекте до написания внешней статистики (под внешней я понимаю то что данные передаются из браузера посетителя) была внутренняя статистика в нее данные пишутся напрямую из движка сайта (данных гораздо меньше, и они апдейтят различные индексы в уже созданных документах)
При каждом открытии веб-страницы движок сайта по окончанию генерации ответа делал несколько запросов в MongoDB на апдейт счетчиков
документы в монге имели вложенную структуру.
Реляционная база не позволила бы сделать такое и так быстро апдейтить такое количество счетчиков.
Получается уже был опыт положительный опыт работы с MongoDB (она хорошо себя зарекомендавала) также уже умели строить отчеты по данным из MongoDB
Поэтому во внешней аналитике было решено задействовать ее. В ходе разработки не раз менялся набор данных которые мы сохраняли (при старте не было Окончательного ТЗ) — с монгой в этом плане очень удобное — не нужно менять структуру таблицы, просто добавляй нужные данные и все.
Соглашусь с вами что в той аналитике которую я описал в рамках статьи MongoDB не дает никаких весомых преимуществ, вполне возможно что Postgresql в чем то бы ее сделал. Одно точно скажу что с Postgresql гораздо быстрее бы строились отчеты (опыт работы с SQL гораздо больший чем с NoSQL).