Артем Кустиков

Шардинг имеет смысл именно когда данные чаще всего достаются из одного шарда. Картинки, например, или статистика по различным серверам/сервисам. Юзера, как основаная сущность приложения, должны физически лежать в одной базе. И даже теоретически макс возможные 6 млрд пользователей в базе займут пару терабайт, что для мускула не проблема - https://habrahabr.ru/post/64851/

html5.by/blog/audio - Web Audio смотрели? там миксеры есть.

process.on("uncaughtException", ....)
Работает точно (https://nodejs.org/api/process.html#process_event_... просто в этом методе все что можно сделать это записать в лог, или отправить сообщение админу, что все плохо. На клиента ничего отправить не получится

Полимер - это просто обёртки над web-components + пяток расширений. А web-componets это чисто браузерная технология. То есть весь серверный рендеринг можно свести к результату типа ....
Но без SEO это никак не поможет.
Polymer - это просто что-то типа новых типов инпутов если совсем обобщать. И рендеринг у него идет только методами DOM API браузера

Посмотри сетевой лог загрузки в хроме - там все станет ясно, какой запрос самый долгий.

В общем случае - никак. Всякие респонзивы и адаптивы + возможный зум в браузере. Убъют все расчеты.
Возможность передавать через текущие размеры и оффсет через сервер тоже не спасет, скриншотилка может открыть страницу в том разрешении т.д.
Самый рабочий вариант - привинтить к виджету debug режим контролируемый из GET параметров (?superwidget-debug=1), потом в нем на загрузке создавать DIV[style="position: absolute;z-index:9999; top:0; background: #0c0; height: 10px;"] и в него большим фонтом писать всю нужную инфу. Потом этот текст можно прогнать через OCR и получить реальные параметры виджета.

options.level который приходит в formatter никакого отношения к ' level: 'info', // тип логирования' не имеет
logger.error/logger.info/logger.debug - вот это оно
установка уровня ' level: 'info' пропускает logger.error и logger.info

Прикрепи JSON который приходит на POST запрос, должно быть что-то типа:

{
location: {
 type: 'XXX',
 coordinates: [3123, 232, 232]
}
}

C# под Windows хостингом - дорогой вариант, под линуксом - просто изврат. И очень тормозной в сравнении с остальными вариантами: https://www.techempower.com/benchmarks/#section=data-r9
У дотнета строго ограниченная область применения (пишу как дотнет-девелопер с 10-летним стажем) - бизнес-системы с интеграцией различного бизнес-софта и привязкой к Azure/MS SQL. High-load - ни разу не его сфера.
Java/node/C++/Python/Ruby намного лучше подойдут для ваших целей.

client.id уникальный для каждого сервера ID сессии и в теории, при неправильной обработке disconnect, он может быть назначен совсем другому клиенту. В общем случае контролировать прямую связь soket.io client.id и ID клиента в базе - задача не из простых.
Намного проще хранить этот ID на клиенте (localStorage) и передавать его с каждым сообщением и поддерживать один актуальный маппинг MySQL ID <=> client.id в памяти сервера.

По поводу параллельно открытых вкладок проблема известная - браузеры по умолчанию могут держать 2-3 постоянно открытых коннекта (websocket) на один URL. Решается синхронизацией табов через localStorage: html5demos.com/storage-events
Или https://groups.google.com/forum/#!topic/socket_io/...,
или stackoverflow.com/questions/18654567/save-socket-i...