Магия программирования

Тема в разделе "WASM.HEAP", создана пользователем SadKo, 6 май 2019.

  1. q2e74

    q2e74 Active Member

    Публикаций:
    0
    Регистрация:
    18 окт 2018
    Сообщения:
    988
    Огромное спасибо! Просто огромное.
    --- Сообщение объединено, 8 май 2019 ---
    а какие у java проблемы с сериализацией? кроме того что RMI дырявый всю безопасность портил? или парсить и конвертировать из формата в формат это тоже проблемы с сериализацией?
     
  2. SadKo

    SadKo Владимир Садовников

    Публикаций:
    8
    Регистрация:
    4 июн 2007
    Сообщения:
    1.610
    Адрес:
    г. Санкт-Петербург
    Проблемы обычно в кривых входных данных, особенно от всяких "шарага-сервис". Где в одном месте даты, например, передаются одним способом, в другом - другим, где-то используется нестандартный base64-набор символов и т.д.
    А так проблем с сериализацией действительно нет. Другое дело, что сейчас стало модным чуть ли не ссылки на классы впиливать в аннотации, а это, ИМХО, плохо.
    --- Сообщение объединено, 8 май 2019 ---
    А, нет, есть одна проблема: большие документы и потоковая обработка. Далеко не все сериализаторы умеют парсить документы в поточном режиме, а загрузка в память далеко не всегда оправдана.
     
  3. im.

    im. Active Member

    Публикаций:
    0
    Регистрация:
    16 сен 2017
    Сообщения:
    310
    SadKo, почти зацитировал мои ранние высказывания о критики С++ и преимуществах Java :derisive:
    Все верно сказал.
     
  4. f13nd

    f13nd Well-Known Member

    Публикаций:
    0
    Регистрация:
    22 июн 2009
    Сообщения:
    1.953
    Представь, что у тебя полно времени и желания всем чего-то доказать. Сделать что-то как все - хуже, чем вообще не браться, потому что ты особенный и не ровня всем остальным. Тогда возможно многое станет понятней.
     
  5. Aoizora

    Aoizora Active Member

    Публикаций:
    0
    Регистрация:
    29 янв 2017
    Сообщения:
    351
    Никаких проблем с сериализацией нет. Чет-то тут ребята все на парсинг JSON бутхят, а мы в своем проекте пошли дальше и уже вовсю использует protocol buffers.
     
  6. im.

    im. Active Member

    Публикаций:
    0
    Регистрация:
    16 сен 2017
    Сообщения:
    310
    Самое кошерное сейчас это MsgPack, для себя делал аналогичное решение, позже появился MsgPack с его грамотным битовым использованием ресурсов и вот это крутяк! Наконец значения -1 удобно хранить без лишних байт.
     
  7. q2e74

    q2e74 Active Member

    Публикаций:
    0
    Регистрация:
    18 окт 2018
    Сообщения:
    988
    Мне вот этот подход нравиться, что касается памяти, хотя и ценой скорости медленно но верно.
     
  8. SadKo

    SadKo Владимир Садовников

    Публикаций:
    8
    Регистрация:
    4 июн 2007
    Сообщения:
    1.610
    Адрес:
    г. Санкт-Петербург
    А ещё меня сегодня посетила идея о том, что все API, базирующиеся на протоколе HTTP - сущее говно по определению.
     
  9. _DEN_

    _DEN_ DEN

    Публикаций:
    0
    Регистрация:
    8 окт 2003
    Сообщения:
    5.383
    Адрес:
    Йобастан
    SadKo, как предлагаешь приложению взаимодействовать с БД социальных сетей? :)
     
  10. SadKo

    SadKo Владимир Садовников

    Публикаций:
    8
    Регистрация:
    4 июн 2007
    Сообщения:
    1.610
    Адрес:
    г. Санкт-Петербург
    Вопрос не в том, как я предлагаю взаимодействовать, а в том, как этот HTTP обрабатывается на сервере. А обрабатывается он в синхронном режиме.
    Теперь представьте: некоторый клиент начал слать JSON, и где-то в середине прекратил. А потоки на вашем сервере ждут поступления новой инфы, так как десериализовать JSON частично не могут.
    Но это не так страшно, пока у вас все обслуживающие потоки не повисли в таком состоянии - крутая ситуация, да?
     
  11. _DEN_

    _DEN_ DEN

    Публикаций:
    0
    Регистрация:
    8 окт 2003
    Сообщения:
    5.383
    Адрес:
    Йобастан
    SadKo, не, всё не так :) До "обслуживающих потоков" дело доходит только после того как запрос полностью прочитан. До этого момента запрос читается асинхронным API ОС, не требующим наличия отдельных потоков в приложении. Количество одновременно доступных буферов для чтения запросов ограничено лишь ОЗУ и правильным конфигом.
     
  12. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    6.074
    всё началось ещё в 20-ом веке, когда у прогеров ушла инженерная специализация и объекты программирования стали сугубо виртуальными. так же правильно подметил Aoizora, == КОММЕРС == тамо требуется не столько качественное решение, сколько прибыльное. Сейчас, кстати, идёт более смешная тенденция == орут во всю глотку про ии, пч в ближайшие 5 лет будет фатальный дефицит даже замшелых прогеров. С инженерами эта проблема ужо достигла АХТУНГА.
     
  13. SadKo

    SadKo Владимир Садовников

    Публикаций:
    8
    Регистрация:
    4 июн 2007
    Сообщения:
    1.610
    Адрес:
    г. Санкт-Петербург
    То есть, вы сначала весь HTTP запрос вычитываете в память, а только потом десериализуете?
    Ну я вас поздравляю, здесь вы можете уткнуться в нехватку памяти либо низкую производительность.

    Ситуация с HTTP плоха тем, что плохо контролируема, либо приходится городить такие костыли, что мама не горюй.

    На тех же TCP сокетах можно организовать куда более удачную схему взаимодействия: от клиента прокладывается канал из N TCP-соединений до сервера, по которым они в асинхронном режиме могут гонять данные.
    Если клиент попробует установить N+1 соединение, то оно режектится сервером. Если клиент будет тупить с отправкой пакетов, это не займёт остальные коннекции и обслуживающие потоки сервера, то есть сервер не будет тупить вместе с клиентом.А асинхронный обмен данными позволяет уменьшить общее количество обслуживающих потоков и, при этом, поднять общую полезную нагрузку на канал.
    Иными словами, каждому клиенту можно предоставить свой гарантированный QoS.

    А в случае с HTTP, когда все ломятся в одну точку и, при этом, равноправны в своих действиях, такой подход труднореализуем. А учитывая то, что большинство API сейчас базируется на HTTP - сами понимаете, что, в итоге, выходит.
     
  14. _DEN_

    _DEN_ DEN

    Публикаций:
    0
    Регистрация:
    8 окт 2003
    Сообщения:
    5.383
    Адрес:
    Йобастан
    Это зависит от параметров запроса. Запрос может быть отправлен как целиком, так и частями (multipart / chunked transfer encoding).

    Ну так ты же сам привел пример с JSON-ом, который нет смысла пытаться парсить, пока не получишь все содержимое целиком. Как именно парсить содержимое - это выясняется из заголовка Content-Type.

    Заголовок Keep-Alive и ты получишь описаную далее схему взаимодействия - браузеры так и работают. Открывают сразу несколько параллельных соединений и далее работают в их Keep-Alive пуле (за некоторыми уточнениями).

    Ну а в случае с голыми TCP-сокетами все точно так же будут ломиться на одну точку host:port, в чем разница?

    Не совсем понимаю почему ты так хорошо шаришь в линуксах, и при этом у тебя такое странное искаженное представление о HTTP :)
     
  15. SadKo

    SadKo Владимир Садовников

    Публикаций:
    8
    Регистрация:
    4 июн 2007
    Сообщения:
    1.610
    Адрес:
    г. Санкт-Петербург
    Это не отменяет тот факт, что запрос может быть обработан в потоковом режиме

    Ничего подобного. JSON может парситься на лету, в один проход. В итогде имеем ситуацию, когда парсер тупо подвисает на socketRead'е.

    Keep-Alive - это механизм для поддержания соединения, а не контроля его обрыва. Ваш клиент (пусть будет браузер) засылает в TCP-сокет HTTP запрос и ждёт ответа на него. Пока браузер ждёт ответ, сокет простаивает -> низкая эффективность обмена данными по TCP-сокету, синхронное взаимодействие.

    Разница в том, что вы куда более разумно распределяете системный ресурс, и полезная нагрузка на один сетевой сокет поднимается в разы, т.к. для такого же объёма передаваемых данных нужно использовать меньше TCP-коннекций.
    Отсутствует дополнительный overhead в виде совершенно ненужных HTTP-заголовков.

    У меня совершенно не странное и не искажённое представление. Я пишу исходя из наблюдений того, что творится в Enterprise решениях. Совсем недавно у нас, как раз, была ситуация, когда один из клиентов системы благополучно положил на короткий промежуток времени endpoint API по следующей схеме:
    1. Клиенский сервис открыл кучу соединений и недослал куски JSON в запросах.
    2. Сериализаторы повисли на чтении из сокета.
    3. Как следствие, забились все обслуживающие HTTP-соединения потоки.
    4. Результат: система встала в режиме Denial of Service, при котором другие клиенты не могли выполнять запросы к ней.

    При решении через жёстко контролируемые пулы TCP-соединений такой проблемы в принципе не могло возникнуть.
    Если бы один из клиентов устроил такой DoS, то подвис бы пул подключений этого клиента. При этом, остальные клиенты чувсвовали бы себя вполне комфортно.

    Я не понимаю, чего тут может быть непонятного.
     
  16. _DEN_

    _DEN_ DEN

    Публикаций:
    0
    Регистрация:
    8 окт 2003
    Сообщения:
    5.383
    Адрес:
    Йобастан
    SadKo, не, всё, дальше рассусоливать лень :) Оставайся при своем мнении, мне не жалко :)
     
  17. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    6.074
    тогда вопрос: почему хухль/ютуб не падает, если с хттп такая ужасть???
     
  18. _DEN_

    _DEN_ DEN

    Публикаций:
    0
    Регистрация:
    8 окт 2003
    Сообщения:
    5.383
    Адрес:
    Йобастан
    Подсказка в названии треда :derisive:
     
  19. SadKo

    SadKo Владимир Садовников

    Публикаций:
    8
    Регистрация:
    4 июн 2007
    Сообщения:
    1.610
    Адрес:
    г. Санкт-Петербург
    Количество серваков у них неограниченное. А ужасть так или иначе есть, просто вы её не замечаете.
     
  20. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    6.074
    дело не в кол-ве серваков, а в оптимальности их загрузки. Так вот у хухля практически нет холостых простоев. Ты любые деньги потрать, но неоптимальность их всегда сожрёт.. ВСЕГДА :)