server { ...
location test.html {
proxy_pass http://backend;
}
}
upstream backend {
server http://10.0.0.2
}Такой вопрос: в чем основное преимущество асинхронных серверов ... перед связкой асинхронный сервер + любой язык
---
перед связкой асинхронный сервер + любой язык - не совсем понятно, что Вы имеете в виду. Асинхронный сервер или нет, это одно, а вот асинхронный или нет доступ к данным у ЯП - это совсем другое. Я уверен, что Вас больше интересует второе.
Вся прелесть, сложность и проблемы в асинхронном подходе возникают по одной и той-же причине. Результат на запрос приходит не сразу, а асинхронно. Это даёт огромное уменьшение времени отклика программы, если в ней используется результат нескольких не зависимых IO операций. Во всех остальных случаях синхронный подход проще, при таком-же времени доставки ответа. (IO - это работа с файлами, внешними api итп )
Nodejs имеет один существенный недостаток - у неё один процесс выполнения. По этому тяжелые вычисления на ней значительно уступают в производительности PHP на многопроцессорных/ядерных системах. (это дело легко обходится воркерами итп, но это еще один недостаток)
erlang, java и несколько других языков не имеют вышеуказанной проблемы.
Nodejs по сравнению с PHP имеет еще 2 важных плюса:
1. в ноде можно хранить данные, таймеры, дескрипторы итп между запросами. По этому это намного эффективнее различных механизмов кэширования PHP.
2. в ноде не тратится время на подгрузку кода.
>>В асинхронном сервере в единый момент времени обрабатывается столько запросов, сколько есть воркеров и в PHP/nginx точно также.
Не верно, ни в первом ни во втором случае. В асинхронном сервере есть всего один поток, который обрабатывает любое количество запросов, в nginx - точно так-же. О PHP - другая история, но на каждый запрос нужен как минимум thread или process.
1) насколько больше памяти занимает DOM (за пределами экрана) чем данные в модели
Это очень специфично. Здесь не столько вопрос о памяти, сколько нагрузка на layout engine (если не используется абсолютное позиционирование).
2) как браузер оптимизирует элементы за пределами экрана;
Зависит от браузера. Рендеринг их не происходит всегда, но лайаут пересчитывается в большинстве случаев. О webkit (chrome, safari) могу сказать, что оптимизация там отличная. Лайаут пересчитывается инкрементально. Сотни элементов почти не напрягают.
2) делая выгрузку уже загруженных элементов стоит их просто удалять или вставлять вместо них пустой блок высотой с эти элементы, чтобы сохранить позицию ползунка прокрутки, как это отразится на производительности?
Это будет накладнее. Удалить у блока детей, при установленной высоте блока - поможет браузеру. А с абсолютным позиционированием - вообще песня. Если есть возможность рассчитывать высоту блоков - то это лучший подход.
Вообще зачем гадать - есть ChromeDev tools timeline + profiles, в мозиле есть фаербаг итп.. Это и даст обьективный ответ.
Никак. Вы нарушаете этим условия пользовательского соглашения.
В качестве альтернатив:
1. OSRM (Openstreetmap routing )
2) вы можете воспользоватся The Google Directions API.