Огромное спасибо! Просто огромное. --- Сообщение объединено, 8 май 2019 --- а какие у java проблемы с сериализацией? кроме того что RMI дырявый всю безопасность портил? или парсить и конвертировать из формата в формат это тоже проблемы с сериализацией?
Проблемы обычно в кривых входных данных, особенно от всяких "шарага-сервис". Где в одном месте даты, например, передаются одним способом, в другом - другим, где-то используется нестандартный base64-набор символов и т.д. А так проблем с сериализацией действительно нет. Другое дело, что сейчас стало модным чуть ли не ссылки на классы впиливать в аннотации, а это, ИМХО, плохо. --- Сообщение объединено, 8 май 2019 --- А, нет, есть одна проблема: большие документы и потоковая обработка. Далеко не все сериализаторы умеют парсить документы в поточном режиме, а загрузка в память далеко не всегда оправдана.
SadKo, почти зацитировал мои ранние высказывания о критики С++ и преимуществах Java Все верно сказал.
Представь, что у тебя полно времени и желания всем чего-то доказать. Сделать что-то как все - хуже, чем вообще не браться, потому что ты особенный и не ровня всем остальным. Тогда возможно многое станет понятней.
Никаких проблем с сериализацией нет. Чет-то тут ребята все на парсинг JSON бутхят, а мы в своем проекте пошли дальше и уже вовсю использует protocol buffers.
Самое кошерное сейчас это MsgPack, для себя делал аналогичное решение, позже появился MsgPack с его грамотным битовым использованием ресурсов и вот это крутяк! Наконец значения -1 удобно хранить без лишних байт.
А ещё меня сегодня посетила идея о том, что все API, базирующиеся на протоколе HTTP - сущее говно по определению.
Вопрос не в том, как я предлагаю взаимодействовать, а в том, как этот HTTP обрабатывается на сервере. А обрабатывается он в синхронном режиме. Теперь представьте: некоторый клиент начал слать JSON, и где-то в середине прекратил. А потоки на вашем сервере ждут поступления новой инфы, так как десериализовать JSON частично не могут. Но это не так страшно, пока у вас все обслуживающие потоки не повисли в таком состоянии - крутая ситуация, да?
SadKo, не, всё не так До "обслуживающих потоков" дело доходит только после того как запрос полностью прочитан. До этого момента запрос читается асинхронным API ОС, не требующим наличия отдельных потоков в приложении. Количество одновременно доступных буферов для чтения запросов ограничено лишь ОЗУ и правильным конфигом.
всё началось ещё в 20-ом веке, когда у прогеров ушла инженерная специализация и объекты программирования стали сугубо виртуальными. так же правильно подметил Aoizora, == КОММЕРС == тамо требуется не столько качественное решение, сколько прибыльное. Сейчас, кстати, идёт более смешная тенденция == орут во всю глотку про ии, пч в ближайшие 5 лет будет фатальный дефицит даже замшелых прогеров. С инженерами эта проблема ужо достигла АХТУНГА.
То есть, вы сначала весь HTTP запрос вычитываете в память, а только потом десериализуете? Ну я вас поздравляю, здесь вы можете уткнуться в нехватку памяти либо низкую производительность. Ситуация с HTTP плоха тем, что плохо контролируема, либо приходится городить такие костыли, что мама не горюй. На тех же TCP сокетах можно организовать куда более удачную схему взаимодействия: от клиента прокладывается канал из N TCP-соединений до сервера, по которым они в асинхронном режиме могут гонять данные. Если клиент попробует установить N+1 соединение, то оно режектится сервером. Если клиент будет тупить с отправкой пакетов, это не займёт остальные коннекции и обслуживающие потоки сервера, то есть сервер не будет тупить вместе с клиентом.А асинхронный обмен данными позволяет уменьшить общее количество обслуживающих потоков и, при этом, поднять общую полезную нагрузку на канал. Иными словами, каждому клиенту можно предоставить свой гарантированный QoS. А в случае с HTTP, когда все ломятся в одну точку и, при этом, равноправны в своих действиях, такой подход труднореализуем. А учитывая то, что большинство API сейчас базируется на HTTP - сами понимаете, что, в итоге, выходит.
Это зависит от параметров запроса. Запрос может быть отправлен как целиком, так и частями (multipart / chunked transfer encoding). Ну так ты же сам привел пример с JSON-ом, который нет смысла пытаться парсить, пока не получишь все содержимое целиком. Как именно парсить содержимое - это выясняется из заголовка Content-Type. Заголовок Keep-Alive и ты получишь описаную далее схему взаимодействия - браузеры так и работают. Открывают сразу несколько параллельных соединений и далее работают в их Keep-Alive пуле (за некоторыми уточнениями). Ну а в случае с голыми TCP-сокетами все точно так же будут ломиться на одну точку host:port, в чем разница? Не совсем понимаю почему ты так хорошо шаришь в линуксах, и при этом у тебя такое странное искаженное представление о HTTP
Это не отменяет тот факт, что запрос может быть обработан в потоковом режиме Ничего подобного. JSON может парситься на лету, в один проход. В итогде имеем ситуацию, когда парсер тупо подвисает на socketRead'е. Keep-Alive - это механизм для поддержания соединения, а не контроля его обрыва. Ваш клиент (пусть будет браузер) засылает в TCP-сокет HTTP запрос и ждёт ответа на него. Пока браузер ждёт ответ, сокет простаивает -> низкая эффективность обмена данными по TCP-сокету, синхронное взаимодействие. Разница в том, что вы куда более разумно распределяете системный ресурс, и полезная нагрузка на один сетевой сокет поднимается в разы, т.к. для такого же объёма передаваемых данных нужно использовать меньше TCP-коннекций. Отсутствует дополнительный overhead в виде совершенно ненужных HTTP-заголовков. У меня совершенно не странное и не искажённое представление. Я пишу исходя из наблюдений того, что творится в Enterprise решениях. Совсем недавно у нас, как раз, была ситуация, когда один из клиентов системы благополучно положил на короткий промежуток времени endpoint API по следующей схеме: 1. Клиенский сервис открыл кучу соединений и недослал куски JSON в запросах. 2. Сериализаторы повисли на чтении из сокета. 3. Как следствие, забились все обслуживающие HTTP-соединения потоки. 4. Результат: система встала в режиме Denial of Service, при котором другие клиенты не могли выполнять запросы к ней. При решении через жёстко контролируемые пулы TCP-соединений такой проблемы в принципе не могло возникнуть. Если бы один из клиентов устроил такой DoS, то подвис бы пул подключений этого клиента. При этом, остальные клиенты чувсвовали бы себя вполне комфортно. Я не понимаю, чего тут может быть непонятного.
дело не в кол-ве серваков, а в оптимальности их загрузки. Так вот у хухля практически нет холостых простоев. Ты любые деньги потрать, но неоптимальность их всегда сожрёт.. ВСЕГДА
