С исключениями в V8 надо быть очень осторожными. Разработчики из гугла на одной из конференций говорили, что движок очень плохо оптимизирует код в try { } блоке. Поэтому лучше оборачивать в try-catch только те куски кода, где действительно может появится исключения.
По алгоритму нагла можно почитать тут — en.wikipedia.org/wiki/Nagle's_algorithm
Если коротко, то это дополнительная буферизация, которая дает выигрыш, если приложение часто отправляет маленькие куски данных по сети. Это будет работать в том случае, если вы отправляете постоянно данные в сокет размером заметно меньшим половине MTU (в этом случае несколько пакетов можно отправить один TCP-пакетом и сэкономить на передаче заголовков TCP-пакетов). В случае HTTP-сервера этот алгоритм не имеет смысла использовать.
Смотря, какой клиент у вас будет. На node.js очень легко и просто написать TCP или UDP сервер. Все зависит от того, что у вас будет в роли клиента. Если вы собираетесь реализовать клиент на HTML5, то надо смотреть на уровень поддержки бинарных сокетов в Websocket, так как текстовый протокол передачи данных будет съедать оень много ресурсов. На стороне ноды есть удобные абстракции, чтобы вычитывать бинарные данные из сокета и разбирать полученные буферы. В этом плане node.js намного-намного круче, чем php :-)
Если вы реализуете реалтайм соединение, то перед вами под нагрузкой опять же станет проблема сборщика мусора на сервере, который может останавливать сервер на десятки или сотни мс, что для реалтайм шутера недопустимо. Но, в принципе, можно обойти и этот момент. Навскидку, я бы реализовал это так — надо иметь пул серверов под процессы, которые обрабатывают сами игры (если они будут сделаны как в CS или Quake). В каждом из таких процессов можно подавить сборку мусора, задав определенный флаг на запуске, ну и написать код таким образом, чтобы он не тек. Заканчивается раунд в игре — процесс убивается.
Все зависит от требования к real-time и к логике игры. Если у вас очень сложная логика, которая может потребовать ресурсоемких вычислений — то это не ваш выбор. У node.js есть сильное ограничение в виде однопоточности, то есть вы выполнением каких-нибудь сложных расчетов можете заблокировать полностью весь процесс. Плюс еще на больших нагрузках, когда приложение создает много различных объектов, garbage collector может долго отрабатывать. У меня после оптимизаций в тестах на 5к rps паузы достигали 200мс. Но с каждым релизом сборщик мусора становится все лучше и лучше. Свои тесты я проводил на версии 0.6 (сейчас актуальна ветка 0.8).
У меня сложилось ощущение, что node.js это отличный вариант для REST-сервисов с достаточно простой логикой. Так же стоит учесть, что нет возможности запустить приложение в несколько потоков с общей памятью, но в то же время можно запускать приложение в несклько процессов и обмениваться между ними сообщениями.
Кстати, не так давно mozilla выпустила браузерную realtime игру, клиент которой написан на HTML5, а сервер — на node.js. Называется — BrowserQuest. Исходники на гитхабе — github.com/mozilla/BrowserQuest
Честно признаться, не силен в клиентском яваскрипте. Работал давно на стороне клиента.
Точно могу сказать, что на сервере надо больше внимания обработке ошибок. Механизм исключений использовать для асинхронного кода нельзя вообще — только событий или коллбеки с передачей ошибок. Так же нельзя вообще писать код, который может заблокировать event-loop. Никакого кода, который требует много процессорных ресурсов в основном процессе приложения.
Но даже с моим опытом клиентского JS, могу точно сказать, что серверый JS это совсем другой язык. Самое главное преимущество — код исполняется только в одной среде и ты точно знаешь какие языковые конструкции поддерживаются. На самом деле возможности языка поражают, его сила на клиенте очень и очень недооценена. Все то, что делается в браузере при помощи underscore, есть в самом языке.
Я перешел на node.js потому, что срочно потребовалось написать приложение, поддерживающее сокеты, а не http. Ни с connect, ни с express не работал. Был опыт работы с socket.io, но в итоге для нового проекта я решил реализовать самому long-polling.
Не пробовал. Сейчас у меня все сервера крутятся на Amazon EC2. Честно сказать, я даже и не могу представить, как можно запускать Node.JS на GAE. GAE — это же по сути услуга сервиса запуска python и Java приложений. Нативной поддержки Node.JS там нет.
Если я не ошибаюсь, то у вас в реализации существует серьезная уязвимость. При проверке существует ли метод в теле вы не проверяете входные переменные.
Например, при попытке вызова такого URL-а, для существующего контроллера: www.example.com/api/?apitest.getApiEngineByName=test будет заинклуден файл test.php.
А если еще включена настройка allow_url_fopen, то можно будет вообще загрузить и подключить какой-нибудь шелл.
Ага, понял вас. По всей видимости мы немного по разному интерпретировали понятие сессии. Я имел ввиду не те данные, что хранятся в $_SESSION, а немного более широкое понятие.
А так да, конечно, стоит разделять данные, которые должны храниться для пользователя максимальное количество времени и данные, которые необходимо знать только в рамках текущей сессии (простите за тавтологию :-) ). К этим данным разные требования и, соответственно, разный механизм работы с ними.
Не совсем понял механизм, что вы предлагаете для вечноживущих сессий.
В любом случае, нужно хранить куку в какой-то базе данных, которая связана с профилем пользователя, по которой и проводится аутентификация.
На всякий случай расскажу как работают сессии в PHP:
Когда вы начинаете работать с сессионными данными для подключения, php задает куку с именем, который вы указываете в конфиге (по умолчанию PHPSESSIOID вроде) и уникальным значением, которое хранит в себе ID сессии пользователя. При каждом запросе к скрипту идет выборка этой куки и поиска сессионных данных, что соответствуют этой куке. Если сессионных данных не будет найдено, например, по причине того, что они хранились в APC, а вы перезапускали свой апач, то соответсвенно и слетит авторизация.
Ну например, стоит использовать базу данных для хранения сессий в том случае, если у вас количество серверов, которые обрабатывают запросы пользователей, больше одного. В этом случае вам файловая система и тем более APC не подходят. Memcached же не подходит по той причине, что данные сессий старых пользователей могут быть вытеснены новыми данными. Вам же, например, не очень приятно, когда вы заходите на какой-нибудь сайт каждый день, а он постоянно просит вводить у вас логин и пароль и не запоминает авторизацию. Это же плохой user-experience.
Именно поэтому имеет смысл сохранять данные сессии в персистентное внешнее хранилище данные, которое может быть и MySQL-ем, и Redis-ом или вообще каким-нибудь Membase-ом.
В данный момент я пишу небольшую мультиплеерную игру на Node.JS + Socket.IO В принципе, все не так уж и сложно. Пришлось правда пойти на небольшие хитрости. Как оказалось, что самая затратная операция по CPU в моем приложении это запись и чтения из сокета. По бенчмаркам я одним процессом node.js мог добиться около 2-3k rps на вход и 15k rps на выход (особенности моего приложения, что на одно сообщение на вход приходится около 5-10 сообщений на выход). Мне этой производительности было недостаточно. Решил изменить архитектуру сделав выполнение приложения в несколько процессов (остановился на 4-ех): 1 процесс, который отвечает за логику игры, и 3 процесса, которые отвечают за сетевые подключения. В итоге на синтетическом тесте получил такие цифры — 12k клиентов, которые создавали 12k запросов в секунду, и получали 120k событий в секунду. Пока этой цифры мне стало достаточно.
Делал я это все относительно давно, вроде как еще до версии Node.JS 0.6. Надо сейчас будет попробовать протестировать это же приложение, использую нативный модуль cluster, который позволяет делить между процессами сетевые подключение.
Ну и так же в версии 0.7 Node.JS были анонсированы isolates — что-то вроде тредов у которых нет общей памяти.
Если я правильно понял проблему, что вы хотите решить, то вам прямиком за модулем php memcached (а не memcache) с его compare and set операциями (http://us2.php.net/manual/en/memcached.cas.php)
Если коротко, то это дополнительная буферизация, которая дает выигрыш, если приложение часто отправляет маленькие куски данных по сети. Это будет работать в том случае, если вы отправляете постоянно данные в сокет размером заметно меньшим половине MTU (в этом случае несколько пакетов можно отправить один TCP-пакетом и сэкономить на передаче заголовков TCP-пакетов). В случае HTTP-сервера этот алгоритм не имеет смысла использовать.
Если вы реализуете реалтайм соединение, то перед вами под нагрузкой опять же станет проблема сборщика мусора на сервере, который может останавливать сервер на десятки или сотни мс, что для реалтайм шутера недопустимо. Но, в принципе, можно обойти и этот момент. Навскидку, я бы реализовал это так — надо иметь пул серверов под процессы, которые обрабатывают сами игры (если они будут сделаны как в CS или Quake). В каждом из таких процессов можно подавить сборку мусора, задав определенный флаг на запуске, ну и написать код таким образом, чтобы он не тек. Заканчивается раунд в игре — процесс убивается.
У меня сложилось ощущение, что node.js это отличный вариант для REST-сервисов с достаточно простой логикой. Так же стоит учесть, что нет возможности запустить приложение в несколько потоков с общей памятью, но в то же время можно запускать приложение в несклько процессов и обмениваться между ними сообщениями.
Кстати, не так давно mozilla выпустила браузерную realtime игру, клиент которой написан на HTML5, а сервер — на node.js. Называется — BrowserQuest. Исходники на гитхабе — github.com/mozilla/BrowserQuest
Точно могу сказать, что на сервере надо больше внимания обработке ошибок. Механизм исключений использовать для асинхронного кода нельзя вообще — только событий или коллбеки с передачей ошибок. Так же нельзя вообще писать код, который может заблокировать event-loop. Никакого кода, который требует много процессорных ресурсов в основном процессе приложения.
Но даже с моим опытом клиентского JS, могу точно сказать, что серверый JS это совсем другой язык. Самое главное преимущество — код исполняется только в одной среде и ты точно знаешь какие языковые конструкции поддерживаются. На самом деле возможности языка поражают, его сила на клиенте очень и очень недооценена. Все то, что делается в браузере при помощи underscore, есть в самом языке.
Например, при попытке вызова такого URL-а, для существующего контроллера:
www.example.com/api/?apitest.getApiEngineByName=test будет заинклуден файл test.php.
А если еще включена настройка allow_url_fopen, то можно будет вообще загрузить и подключить какой-нибудь шелл.
А так да, конечно, стоит разделять данные, которые должны храниться для пользователя максимальное количество времени и данные, которые необходимо знать только в рамках текущей сессии (простите за тавтологию :-) ). К этим данным разные требования и, соответственно, разный механизм работы с ними.
В любом случае, нужно хранить куку в какой-то базе данных, которая связана с профилем пользователя, по которой и проводится аутентификация.
Когда вы начинаете работать с сессионными данными для подключения, php задает куку с именем, который вы указываете в конфиге (по умолчанию PHPSESSIOID вроде) и уникальным значением, которое хранит в себе ID сессии пользователя. При каждом запросе к скрипту идет выборка этой куки и поиска сессионных данных, что соответствуют этой куке. Если сессионных данных не будет найдено, например, по причине того, что они хранились в APC, а вы перезапускали свой апач, то соответсвенно и слетит авторизация.
Именно поэтому имеет смысл сохранять данные сессии в персистентное внешнее хранилище данные, которое может быть и MySQL-ем, и Redis-ом или вообще каким-нибудь Membase-ом.
Делал я это все относительно давно, вроде как еще до версии Node.JS 0.6. Надо сейчас будет попробовать протестировать это же приложение, использую нативный модуль cluster, который позволяет делить между процессами сетевые подключение.
Ну и так же в версии 0.7 Node.JS были анонсированы isolates — что-то вроде тредов у которых нет общей памяти.