evg_96, ну, на чистом NodeJS врядли кто-то пришет роутинг и т.п., для этого есть фреймворки.
Для задач обучения, ИМХО, как раз таки наоборот - лучше не использовать фреймворки - это позволит понять как они организованы внутри.
Касательно говнокода - не надо боятся писать код. Только практика может показать какие подходы лучше и почему.
Пиши как умеешь и как получается. Будет работать - уже неплохо. Дальше практика подскажет, как делать лучше.
Нет смысла передавать пароль в уже зашифрованном виде - т. к. ни что не мешает в коде страницы посмотреть как он шифруется. Для защиты пароля от перехвата надо использовать SSL.
2к пользователей создают до 300 запросов в секунду в одну таблицу при чем как на запись так и на чтение? Либо что-то не так либо что-то специфическое.
Может тогда не MySQL+PHP?
Часть времени тратится на установку соединения в бд при каждом запросе.
Та же nodejs может открыть соединение при старте и работать через него (через уже готовый пул соединений).
В приложении - код, который обращается в бд обернуть в кеширующий слой, где ключем кеширования будет запрос, а значением - результат. + надо ttl выставлять. Хранить это все можно в memcached/redis. При запросе проверять наличие значения в кеше по ключу (кстати это будет работать для select запросов, в вопросе не уточнено какой характер запросов).
Если запросы идуть сильно разные - то кеша может быть много.
В вебсервере - аналогично, ключ кеширования - параметры запроса, значение - ответ. В таком случае не будет подниматься даже PHP что бы глянуть в кеш или в базу.
Недостаток - данные могуть быть определенное время неактуальны (про сроку кеша)
PS в вопросе не написано, в чем собственно проблема.
Возможно будет достаточно тюнинга конфигов бд или добавления индексов.
Если проблема в скорости ответа - действительно ли БД это узкое горлышко или может PHP?
frontendo, неужели такой хайлоад, что это имеет какое-то существенное значение? был бы такой хайлод - таких бы вопросов не было.
Если жалко ходить в оперативку в redis и нет желания шарить данные между экземплярами сервиса - можно пробовать встраиваемые бд типа https://github.com/louischatriot/nedb (сам с ней не работал)
Но это все преждевременная оптимизация.
Oleg-Ukraine, да.
+ should имеет условия применения - он в ряде случаев использутеся только для score, а не для ограничения запросов.
Видимо, надо перестроить запрос, но мне сложно сделать это в уме не имея доступа к каким-то близким к реальным данным.
Иван, разве можно создать службу из произвольного исполняемого файла?
Я когда-то искал - там нужно определенным образом в коде указывать. https://stackoverflow.com/a/3582179
https://en.wikipedia.org/wiki/Camel_case