Java I/O для объёмных данных

#оптимизация #файлы #java

                    
Нужен совет опытных по поводу производительности Java I/O и много другого. Задачка
такая - в нескольких потоках клиент шлет http post запрос весом до 1 мб каждый, в ответ
приходят еще больший по весу (2-4 мб) ответ в формате JSON, который нужно спарсить
и аккуратно завернуть в .csv файл. Количество запросов может доходить до десятков тысяч,все
ответы сервера пишутся в 1 файл. Сервер один и тот же. (что делать с Keep-Alive ? )
. Соответственно возникает вопрос - а какие инструменты при этом использовать ?

Соединение: HttpClient / HttpUrlConnection /Netty/etc
Чтение ответа : BufferedReader/Scanner/etc
Чем Json парсить ? jackson/gson/simple json
Чем писать в файл, и нужно ли вообще писать во время работы или же лучше кидать в
какой нибудь ArrayList, потом спарсить и записать.

В общем, буду рад любым советам и подсказкам)
Вопрос не мой, просто помогаю человеку :)    

Ответы

Ответ 1

Здравствуйте @Михаил М. сказать, что Вы как-то смутно задали вопрос это тоже самое
что вообще ничего не сказать).
производительности Java I/O  - во первых уточнили бы какую яву собираетесь использовать.
в любом случае у Вас будет многопоточность сразу советую смотреть в сторону java concurrency
apis. думаю появится много проблемм и ожиданий в очередях пока Вы будете парсить такие
обьемы а потом еще и записывать в один файл. - это какая-то жесть(возможно я не правильно
понял задачу)
тем более что запросов до десятков тысяч.
что значит что делать с keep-alive ?, если я правильно понимаю у каждого request/response
- свое время жизни и регулироваться они будут самостоятельно.
ну да и по порядку: 
1 - для запросов мне в мобильных разработках помогла и хорошо себя зарекомендовала
вот эта либа http-request - там сразу на страничке все описано в доль и поперек
2 - здесь тоже все может выполнить предыдущая либа.
3 - gson - себя зарекомендовал с очень хорошей стороны, хоть и не без косяков))
4 - я не понимаю почему все в один файл, возможно стоило вначале описать функциональность
которую Вы хотите в итоге добиться, я бы хронил уже готовые для записи .csv  в мапке
и завел бы отдельный поток который бы и записывал их поочередно. это спосет Вас от
многопоточного доступа к файловой системе. и позволит как минимум всем потокам по очереди
получать право на запись в мапку, и постоянное право у записывающего потока на чтение
из нее.
касаемо первых двух пунктов могу сказать еще только что если пользоваться стандартными
средствами то я бы использовал BufferedInputStream и HttpUrlConnection


Ответ 2

1.) Для объемных файлов конкретный api особо не влияет на скорость передачи, все
упрется в возможности железа. Заморачиваться с nio стоит, если есть например много
легких соединений, и есть проблемы с переключениями контекстов. Так что выбирайте удобный,
отлаженный api. Я бы взял apache http client 4.
2) BufferedReader - хорошее решение
3) Я бы взял jackson - мощный и быстрый. Gson скорее более специализированное решение
для конвертации между бинами и json.
4) Писать лучше во время работы из другого потока, будет pipelinig. И запись конечно
должна быть буферизованной, например через BufferedWriter.
Keep alive лучше выключить. Файлы большие, время установки соединений ничтожно меньше
времени передачи. Только морока будет с настройкой сервера.
Еще советую на клиенте и сервере установить размеры tcp буфферов в один мегабайт,
алгоритм нигла оставить включенным, scaling tcp окна тоже оставить включенным.
И еще общий совет: делай каждую стадию отдельной группой потоков, потоки соединяй
очередями. Это называется SEDA. Так ты сможешь получить максимальную пропускную способность.
Кстати, увеличение длин очередей увеличивается пропускную способность, но ухудшает
latency. Имей в виду.
  Автор ответа - Денис Боровиков, [http://vk.com/id36765][1]