Комментарии 76
Прекрасная и очень вменяемая статья, спасибо большое.
Внятно, по делу и без приукрас вида «мы тут hello world за 10 минут сделали».
Комментарий: Sync, безусловно жизненно необходим, хотя и уродлив. Лучше, чем без него, но что поделать. Как он, кстати, будет пробрасывать исключения? Файбер или тред клевы именно тем, что в них внятно пробрасываются исключения.
Вопрос: можете ли вы отказаться от nginx в этой ситуации? Я бы ради кометов и вебсокетов не особо волнуясь поставил бы веб-сервер на erlang вместо nginx.
Просто порт 4000 — всё таки штука стремная, отвалится у многих пользователей.
Насколько можно сервер на ноде втыкать вперед?
Внятно, по делу и без приукрас вида «мы тут hello world за 10 минут сделали».
Комментарий: Sync, безусловно жизненно необходим, хотя и уродлив. Лучше, чем без него, но что поделать. Как он, кстати, будет пробрасывать исключения? Файбер или тред клевы именно тем, что в них внятно пробрасываются исключения.
Вопрос: можете ли вы отказаться от nginx в этой ситуации? Я бы ради кометов и вебсокетов не особо волнуясь поставил бы веб-сервер на erlang вместо nginx.
Просто порт 4000 — всё таки штука стремная, отвалится у многих пользователей.
Насколько можно сервер на ноде втыкать вперед?
+17
> Комментарий: Sync, безусловно жизненно необходим, хотя и уродлив.
Нотацию «someObject.someMethod.sync(someObject, arg1, arg2)» необходимо использовать только для вызова сторонних функций, которые не обернуты в ".async()". Свои же функции можно вызывать напрямую: gist.github.com/1159101 (getUserSummary_nodejs_sync.js)
> Как он, кстати, будет пробрасывать исключения?
Так же, как и Fiber — нативно.
> Вопрос: можете ли вы отказаться от nginx в этой ситуации?
Не могу. На нем много другой логики, которую очень не хочется доверять nodejs.
> Я бы ради кометов и вебсокетов не особо волнуясь поставил бы веб-сервер на erlang вместо nginx.
Я вообще скоро комет перепишу на Erlang :)
> Просто порт 4000 — всё таки штука стремная, отвалится у многих пользователей.
Пока не сталкивался, вроде у всех работает. А в чем может быть проблема?
> Насколько можно сервер на ноде втыкать вперед?
Не стоит. Nginx сейчас — как «guard», в котором я всегда уверен, который никогда не отвалится. Тем более, upstream позволяет в случае таймаута перебросить запрос на другой сервер. Он, как бы, сглаживает нестабильность nodejs.
Нотацию «someObject.someMethod.sync(someObject, arg1, arg2)» необходимо использовать только для вызова сторонних функций, которые не обернуты в ".async()". Свои же функции можно вызывать напрямую: gist.github.com/1159101 (getUserSummary_nodejs_sync.js)
> Как он, кстати, будет пробрасывать исключения?
Так же, как и Fiber — нативно.
> Вопрос: можете ли вы отказаться от nginx в этой ситуации?
Не могу. На нем много другой логики, которую очень не хочется доверять nodejs.
> Я бы ради кометов и вебсокетов не особо волнуясь поставил бы веб-сервер на erlang вместо nginx.
Я вообще скоро комет перепишу на Erlang :)
> Просто порт 4000 — всё таки штука стремная, отвалится у многих пользователей.
Пока не сталкивался, вроде у всех работает. А в чем может быть проблема?
> Насколько можно сервер на ноде втыкать вперед?
Не стоит. Nginx сейчас — как «guard», в котором я всегда уверен, который никогда не отвалится. Тем более, upstream позволяет в случае таймаута перебросить запрос на другой сервер. Он, как бы, сглаживает нестабильность nodejs.
+7
Проблема с 4000 в том, что у админов параноиков все порты закрыты, а 80-й ходит через squid.
Там даже PUT запрещен.
Насчёт nginx понял. Выставить erlang на гигабитный интерфейс — не страшно. Дальше, пока не знаю.
Там даже PUT запрещен.
Насчёт nginx понял. Выставить erlang на гигабитный интерфейс — не страшно. Дальше, пока не знаю.
+2
сталкивались. решаеться переводом комета на 443 порт — он обычно даже не проверяеться на траффик и по нему можно плаин-сокетами ходить или вебсокетами
0
Хорошая мысль, надо посмотреть. Хотя, не исключаю больной на голову политики отсекать не SSL трафик по 443
+2
там фишка в том, что сначала идет стандартный HTTP-заголовок Connection:upgrade и все такое, поэтому даже если есть промежуточные проверки, то они проходятся. А дальше уже соединение открыто и обычно ssl внутри не проверяеться. Будет сложно только с сильно умными, которые проверяют траффик и все пакеты, тогда да — не пройдет. Пока с такими не встречались
0
Точно. Сделаю завтра comet.tactoom.com:80
+1
Спасибо за статью.
Несколько вопросов:
Насколько node-cluster надёжен? Как вы его контролируете?
Пользовались ли чем-то другим кроме него (forever)?
Несколько вопросов:
Насколько node-cluster надёжен? Как вы его контролируете?
Пользовались ли чем-то другим кроме него (forever)?
+1
> Насколько node-cluster надёжен?
В плане работы — надежен. Но у него глючный интерфейс cli() start/restart/shutdown. Иногда, при удаленном запуске (через capistrano) не убивает старые процессы, либо вообще ничего не делает. Если зайти на сервер напрямую, то все работает нормально. Все никак не могу с этим разобраться.
У node-cluster нет нативной демонизации, по сему пришлось писать обертку, которая форкает сама себя с setsid=true.
При работае со «stand-alone» (для Cloud процессов, которые не слушают http), пришлось допиливать graceful shutdown/restart.
Еще панисал плагин для node-cluster для слежения за памятью воркеров (если нужно, могу выложить).
> Пользовались ли чем-то другим кроме него (forever)?
Да, forever использую для демонизации Beseda (COMET), поскольку у него всего один процесс.
В плане работы — надежен. Но у него глючный интерфейс cli() start/restart/shutdown. Иногда, при удаленном запуске (через capistrano) не убивает старые процессы, либо вообще ничего не делает. Если зайти на сервер напрямую, то все работает нормально. Все никак не могу с этим разобраться.
У node-cluster нет нативной демонизации, по сему пришлось писать обертку, которая форкает сама себя с setsid=true.
При работае со «stand-alone» (для Cloud процессов, которые не слушают http), пришлось допиливать graceful shutdown/restart.
Еще панисал плагин для node-cluster для слежения за памятью воркеров (если нужно, могу выложить).
> Пользовались ли чем-то другим кроме него (forever)?
Да, forever использую для демонизации Beseda (COMET), поскольку у него всего один процесс.
+1
Откройте секрет вот такого подхода:
<div class="json-data" style="display: none" data-data="%JSON_STRING%"></div>
+3
Простите, а какая нагрузка на ваш проект в целом? (сколько примерно пользователей, сколько уников в день)
Тот же вопрос по-другому: нужна ли вся эта чехарда с масштабированием и т.п., явно нацеленная на огромную аудиторию проекта, непосредственно вам?
Тот же вопрос по-другому: нужна ли вся эта чехарда с масштабированием и т.п., явно нацеленная на огромную аудиторию проекта, непосредственно вам?
+6
> Простите, а какая нагрузка на ваш проект в целом? (сколько примерно пользователей, сколько уников в день)
~2к хостов в день
~300-500 человек онлайн
> Тот же вопрос по-другому: нужна ли вся эта чехарда с масштабированием и т.п.
А вы попробуйте без «чехарды» поднять такой проект и держать хотя бы 100 онлайн :)
~2к хостов в день
~300-500 человек онлайн
> Тот же вопрос по-другому: нужна ли вся эта чехарда с масштабированием и т.п.
А вы попробуйте без «чехарды» поднять такой проект и держать хотя бы 100 онлайн :)
+1
2000 хостов в день это мало. Справиться один сервер, по крайней мере для обычного сайта.
А как вы считаете количество человек онлайн?
Нашёл тут у вас одну неэффективность — на странице tactoom.com/interest/Tactoom-Feedback при наведении на подпись (Tactoom-Feedback, например) делается POST Ajax запрос для каждой ссылки заново.
А как вы считаете количество человек онлайн?
Нашёл тут у вас одну неэффективность — на странице tactoom.com/interest/Tactoom-Feedback при наведении на подпись (Tactoom-Feedback, например) делается POST Ajax запрос для каждой ссылки заново.
+2
А в чем проблема?
Стандартные форумы на относительно стандартных виртуальных хостингах такую нагрузку держат легко. nginx, разумеется, поднят.
Стандартные форумы на относительно стандартных виртуальных хостингах такую нагрузку держат легко. nginx, разумеется, поднят.
+1
Стандартные форумы на стандартных виртуальных хостингах (не впс, а именно хостинг) сто человек онлайн?
Ну-ну.
Не, если там только текст, если нгинкс поднят с proxy_cache/fastcgi_cache, то еще может быть и поверю, но даже если на сервере просто странички с большим количеством графики и комментариев, не удержит хостинг за ~100 рублей 100 человек онлайн, точно говорю.
Ну-ну.
Не, если там только текст, если нгинкс поднят с proxy_cache/fastcgi_cache, то еще может быть и поверю, но даже если на сервере просто странички с большим количеством графики и комментариев, не удержит хостинг за ~100 рублей 100 человек онлайн, точно говорю.
+1
Ну один выделенный сервер точно удержит 100 человек онлайн и больше. Что вы там делаете с этими людьми онлайн, что требуется такая развесистая архитектура?
0
Дык то выделенный сервер, в том-то и дело. Даже слабенький сервер при наличии рук, растущих из правильного места, удержит. И более того, может творить те еще чудеса.
А виртуальный хостинг — увы, нет, не удержит.
А виртуальный хостинг — увы, нет, не удержит.
0
Так тут-то не виртуальный хостинг, тут дофига серверов, а нагрузки всего ничего.
0
Я отвечал на коммент, что стандартный форум на стандартном виртуальном хостинге легко удержит нагрузку порядка ~100 человек онлайн.
Я не автор и к разработке tactoom никакого отношения не имею.
А что в tactoom такого сложного делается, не знаю.
Подозреваю, что они постоянно на любое действие пользователя через ajax (а то и через websocket) дергают слой бизнес-логики, а то и базу данных, отсюда и нагрузка такая, более высокая, чем от стандартного plain web 1.0 форума.
Только что глянул: да, там от каждого залогиненного пользователя раз в ~10 секунд отходит ajax-запрос — видимо, используется технология long polling для организации чата.
Ну и практически нет переходов по страничкам, практически все действия осуществляются через ajax — все взаимодействие с людьми, новые посты и т.п.
Я не автор и к разработке tactoom никакого отношения не имею.
А что в tactoom такого сложного делается, не знаю.
Подозреваю, что они постоянно на любое действие пользователя через ajax (а то и через websocket) дергают слой бизнес-логики, а то и базу данных, отсюда и нагрузка такая, более высокая, чем от стандартного plain web 1.0 форума.
Только что глянул: да, там от каждого залогиненного пользователя раз в ~10 секунд отходит ajax-запрос — видимо, используется технология long polling для организации чата.
Ну и практически нет переходов по страничкам, практически все действия осуществляются через ajax — все взаимодействие с людьми, новые посты и т.п.
0
И кстати, более интересно сколько запросов выполняется за день
0
IP.Board
5-6k хостов, 70-75k хитов в сутки
в пиках около 300-350 человек онлайн (сейчас прямо 200)
nginx на отдачу статики, за ним apache с mod_php5 (практически не тюненый, много лишнего висит)
Что мы неправильно делаем? :)
Хостинг, правда, за 510 рублей и с несколько задранными параметрами (для новых аккаунтов их урезали). Памяти 500 метров — сейчас упираемся в предел и ищем варианты оптимизации.
5-6k хостов, 70-75k хитов в сутки
в пиках около 300-350 человек онлайн (сейчас прямо 200)
nginx на отдачу статики, за ним apache с mod_php5 (практически не тюненый, много лишнего висит)
Что мы неправильно делаем? :)
Хостинг, правда, за 510 рублей и с несколько задранными параметрами (для новых аккаунтов их урезали). Памяти 500 метров — сейчас упираемся в предел и ищем варианты оптимизации.
+2
Видимо вы фанат nodejs :) 2К хостов в день это как раз на тему преждевременной оптимазации, что говорят зло (многие умные и известные дядьки в их книгах по программированию).
Жду инвайтов на сайт, зарегался не дали мне ничо, элита блин с 2К хостами… :)
Жду инвайтов на сайт, зарегался не дали мне ничо, элита блин с 2К хостами… :)
+4
У нас один серв на достаточно обычном Core2Duo с четырмя Гб ОЗУ и обычных сказёвых дисках выдерживает при еджениксе-«тупом и медленном пыхе» (самописный движок) сносно держит до 700 активных пользователей и роботов (специально отключали кеш и проверяли). Это социальная сеть с общением, блогами, файлохранилищем и магазином.
Ваше заявление настораживает. Вы проведите нагрузочное тестирование на всякий случай. Может овчинка выделки не стоит в общем процессе.
Ваше заявление настораживает. Вы проведите нагрузочное тестирование на всякий случай. Может овчинка выделки не стоит в общем процессе.
0
Выглядит так что было интереснее написать сверхэффективный проект на node.js способный невиданно масштабироваться, до того как понять будет ли это востебованно.
+4
Вы не путайте максимальную нагрузочную ёмкость и скорость генерации страницы.
Человек описывал, как он хотел сделать быстро работающий сайт.
Человек описывал, как он хотел сделать быстро работающий сайт.
+2
Как я понял ее просто как хотел, а как сделал. И я понял как раз как наоборот, сделано так чтобы можно было легко и масштабировать, когда web/cloud процессы могут работать на любых машинах. Наверника техническая задача решена отлично, хочется пожелаем проекту испытать ту нагрузку, на которую заложена архитектура.
+2
С @visionmedia в плане пуллов действительно всё очень грустно. С другой стороны они в числе тех, кто добился чего-то на Ноде и может немного позволить расслабится. С удовольствием прочитаю вторую часть :)
P.S. А не много ли 300мс в среднем при такой масштабной подготовке?
P.S. А не много ли 300мс в среднем при такой масштабной подготовке?
+2
> кто добился чего-то на Ноде и может немного позволить расслабится
Они гипер-вальяжные.
> P.S. А не много ли 300мс в среднем при такой масштабной подготовке?
Есть минимум, ниже которого отклик не может быть быстрее физически, как не масштабируй. 300ms — это золотая середина. И это не много.
Поиск, например, 10-50ms.
Они гипер-вальяжные.
> P.S. А не много ли 300мс в среднем при такой масштабной подготовке?
Есть минимум, ниже которого отклик не может быть быстрее физически, как не масштабируй. 300ms — это золотая середина. И это не много.
Поиск, например, 10-50ms.
+5
Вы написали, что использовали redis в качестве очереди. Скажите, рассматривали ли вы другие альтернативы (например, rabbitmq) и почему именно redis.
+1
Я работал с MemcacheQ, Amazon SQS, Active MQ… Все они неплохие. Но зачем добавлять еще одну технологию в стэк, если Redis справляется с этой задачей просто идеально?
+4
редис очень-очень быстрый и не только очереди, тогда как все остальное — большое и дает только очереди (при этом с сложным протоколом и большим оверхедом — это я про AMQP)
+2
Участвовало только 2 человека в разработке? Сколько времени потребовалось на нее?
+3
Как бекапы устроены?
+1
Это там, где «секрет»
Mongodb journaling, Mongodelay 4h, redis slave + snapshots.
Mongodb journaling, Mongodelay 4h, redis slave + snapshots.
+1
Почему Rackspace Cloud Storage, а не Amazon S3?
+3
Ощущения от прочтения схожи с ощущениями от экскурсии с рассказом о том, как строили пирамиды. Дикое количество кода, огромное количество проблем… И ещё один G+ в результате.
Ну и от описания просто дико, люто, бешено веет ровно тем же самым снобизмом, которым веет от поста и комментариев автора. В принципе, это можно считать комплиментом — настолько, насколько снобизм можно считать стилем.
Ну и от описания просто дико, люто, бешено веет ровно тем же самым снобизмом, которым веет от поста и комментариев автора. В принципе, это можно считать комплиментом — настолько, насколько снобизм можно считать стилем.
+3
Хорошо написано, спасибо. Наглядная иллюстрация к принципу о танцоре и тапочках. И проект интересный, жду инвайта.
+1
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
А чем профилируете? Вы там писали, что профилировали сборку объектов из базы.
+1
Собственно, а почему вы выбрали «сырую и спорную технологию» для реализации?
+5
Спасибо за статью, с нетерпением буду ждать второй части, очень не хватает таких обзоров реальных рабочих проектов.
Кстати, сходу вопрос, а вот не пожалели что связались с нодой? Стоило ли потраченное время полученной отдачи?
Там выше в комментариях говорили что 300-500 онлайн это мало, но я так понимаю все делалось не для 300-500, а с зазором на рост в десятки и сотни раз. Если все правильно понимаю держать это все будет в разы дольше. Кстати не проводили нагрузочное тестирование, каков потолок при нынешних ресурсах и насколько легко все это будет масштабироваться (горизонтально как я понимаю).
Кстати, а чего связались со статикой на ноде против того же nginx, это хоть как-то оправдано?
P.S. < 0ms это сколько? o_O
Кстати, сходу вопрос, а вот не пожалели что связались с нодой? Стоило ли потраченное время полученной отдачи?
Там выше в комментариях говорили что 300-500 онлайн это мало, но я так понимаю все делалось не для 300-500, а с зазором на рост в десятки и сотни раз. Если все правильно понимаю держать это все будет в разы дольше. Кстати не проводили нагрузочное тестирование, каков потолок при нынешних ресурсах и насколько легко все это будет масштабироваться (горизонтально как я понимаю).
Кстати, а чего связались со статикой на ноде против того же nginx, это хоть как-то оправдано?
P.S. < 0ms это сколько? o_O
+2
[-Inf; 0)
+3
> Кстати, сходу вопрос, а вот не пожалели что связались с нодой? Стоило ли потраченное время полученной отдачи?
Не жалею. Но и не скажу, что особо рад.
> Кстати, а чего связались со статикой на ноде против того же nginx, это хоть как-то оправдано?
Статику отдает nginx. На node написаны скрипты, которые ее собирают.
> < 0ms это сколько
0.9 ms
Не жалею. Но и не скажу, что особо рад.
> Кстати, а чего связались со статикой на ноде против того же nginx, это хоть как-то оправдано?
Статику отдает nginx. На node написаны скрипты, которые ее собирают.
> < 0ms это сколько
0.9 ms
0
Какая версия Mongoose текла и коматозила? В комментах вы упоминали, что все было написано за 8 месяцев. Вторая версия mongoose была выпущена меньше 2х месяцев назад, вроде переделали ее хорошо. Я сам отказался от первой — она не так сильно тормозила, как была сырая. Если у вас не взлетела вторая, значит, не стоит переходить на нее?
0
Я сейчас занимаюсь разработкой проекта на ноде + html5. В качестве kvs и связи между серверами разделенной логики redis, в качестве основной БД — mongo и как ORM — mongoose. Было интересно почитать.
Есть и вопрос. Судя по вашим словам mongoose показал себя не с очень хорошей стороны. А вы не пробовали определить какие именно места являются самыми проблемными? Все же не хотелось бы от него отказываться, но сделать реальные замеры производительности сейчас не является возможным.
Есть и вопрос. Судя по вашим словам mongoose показал себя не с очень хорошей стороны. А вы не пробовали определить какие именно места являются самыми проблемными? Все же не хотелось бы от него отказываться, но сделать реальные замеры производительности сейчас не является возможным.
0
Недавно пробовали MongoDB в свое проекте. Несколько смутило отсутствие транзакций. Расскажите, пожалуйста, о свое опыте обеспечения целостности данных в монго.
+1
Поклацайте вот этот доклад spf13.com/post/mongodb-e-commerce-and-transactions
Там все сказано по поводу целостности и атомарных операций в mongo.
Денормализации много, на каждое денормализованное значение есть функция пересчета/починки.
Там все сказано по поводу целостности и атомарных операций в mongo.
Денормализации много, на каждое денормализованное значение есть функция пересчета/починки.
0
все очень интересно
спасибо
спасибо
0
Добрый день. Прошло 3 года с момента написания этой статьи (вроде как самой свежей Вашей статьи). Статья написана очень подробно и интересно. Но всё-таки прошло некоторое время, достаточно большое для современных технологий. Хотелось бы узнать Вашу точку зрения, насколько такая модель оказалась эффективной? Или Вы что-то более интересное нашли? Было рад услышать от Вас комментарии, а также мысли на тему «плюсы, минусы, подводные камни».
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Tactoom.com изнутри — социальная блог-платформа на NodeJS/NoSQL