Как вы определяете идеальный размер буфера при использовании FileInputStream?
Для отправки писем с использованием функции php mail. Но для функции электронной почты требуется SMTP-сервер для отправки сообщений электронной почты. мы должны упомянуть SMTP-хост и SMTP-порт в файле php.ini. После успешной настройки SMTP-сервера письма будут отправлены успешно отправленными через php-скрипты.
7 ответов
Оптимальный размер буфера связан со многими вещами: размер блока файловой системы, размер кэша ЦП и задержка кэша.
Большинство файловых систем настроено для использования размеров блока 4 096 или 8192. В теории при конфигурировании размера буфера, таким образом, Вы читаете несколько байтов больше, чем дисковый блок, операции с файловой системой могут быть чрезвычайно неэффективными (т.е. если бы Вы настроили свой буфер для чтения 4 100 байтов за один раз, каждое чтение потребовало бы 2 чтений блока файловой системой). Если блоки уже находятся в кэше, то Вы волнуете оплату цены RAM-> задержка кэша L3/L2. Если Вы неудачны, и блоки еще не находятся в кэше, Вы платят цену на диск-> задержка RAM также.
Поэтому Вы рассматриваете большинство буферов, измеренных как питание 2, и обычно больше, чем (или равный) размер дискового блока. Это означает, что одно из Ваших потоковых чтений могло привести к нескольким чтениям дискового блока - но те чтения будут всегда использовать полный блок - никакие потраченные впустую чтения.
Теперь, это смещается вполне немного в типичном сценарии потоковой передачи, потому что блок, который читается из диска, собирается все еще быть в памяти при ударе следующего чтения (мы делаем последовательные чтения здесь, в конце концов) - таким образом, Вы волнуете оплату RAM-> цена задержки кэша L3/L2 на следующее чтение, но не диск-> задержка RAM. С точки зрения порядка величины диск-> задержка RAM является столь медленной, что это в значительной степени затопляет любую другую задержку, с которой Вы могли бы иметь дело.
Так, я подозреваю, что, если Вы запустили тест с различными размерами кэша (не сделали этого сам), Вы, вероятно, найдете большое влияние размера кэша до размера блока файловой системы. Выше этого я подозреваю, что вещи выровнялись бы довольно быстро.
существуют тонна из условий и исключений здесь - сложности системы на самом деле вполне колеблются (просто получение дескриптора на L3->, кэш L2 передает, ум bogglingly комплекс, и это изменяется с каждым типом ЦП).
Это приводит к ответу 'реального мира': Если Ваше приложение похоже на 99% там, установите размер кэша на 8 192 и движение (еще лучше, предпочтите инкапсуляцию производительности и используйте BufferedInputStream для сокрытия деталей). Если Вы находитесь в 1% приложений, которые очень зависят от дисковой пропускной способности, обрабатывают Вашу реализацию, таким образом, можно выгрузить различные дисковые стратегии взаимодействия, и обеспечивать кнопки и наборы, чтобы позволить пользователям тестировать и оптимизировать (или придумывать некоторых сам оптимизация системы).
Да, это, вероятно, зависит от различных вещей - но я сомневаюсь, что это будет иметь очень много значения. Я склонен выбирать 16K или 32K как хороший баланс между использованием памяти и производительностью.
Примечание, что у Вас должен быть блок попытки/наконец в коде для проверки потока, закрывается, даже если исключение выдается.
В большинстве случаев это действительно не имеет значения так очень. Просто выберите хороший размер, такой как 4K или 16K и придерживайтесь его. Если Вы положительны , что это - узкое место в Вашем приложении, то необходимо начать представлять для нахождения оптимального размера буфера. Если Вы выбираете размер, это является слишком маленьким, Вы будете напрасно тратить время, делая дополнительные операции ввода-вывода и дополнительные вызовы функции. Если Вы выбираете размер, это является слишком большим, Вы начнете видеть много неудачных обращений в кэш, которые действительно замедлят Вас. Не используйте буфер, более крупный, чем Ваш размер кэша L2.
В идеальном случае у нас должно быть достаточно памяти для чтения файла в одной операции чтения. Это было бы лучшим исполнителем, потому что мы позволяем системе управлять Файловой системой, единицами выделения и жестким диском по желанию. На практике Вам повезло знать размеры файла заранее, просто использовать средний размер файла, окруженный для 4K (единица выделения по умолчанию на NTFS). И лучший из всех: создайте сравнительный тест для тестирования нескольких опций.
Чтение регистрирует с помощью NIO Java, FileChannel и MappedByteBuffer, скорее всего, приведут к решению, которое будет намного быстрее, чем какое-либо вовлечение решения FileInputStream. В основном карта распределения памяти большие файлы, и использует прямые буферы для маленьких.
Вы могли использовать BufferedStreams/readers и затем использовать их буферные размеры.
я полагаю, что BufferedXStreams используют 8192 в качестве размера буфера, но как Ovidiu сказал, необходимо, вероятно, запустить тест на целом наборе опций. Его действительно попытка зависеть от конфигураций файловой системы и настроек дисков относительно того, каковы лучшие размеры.
Как уже упомянуто в других ответах, используйте BufferedInputStreams.
После этого, я предполагаю, что размер буфера действительно не имеет значения. Любой программа является вводом-выводом связанный, и растущий размер буфера по значению по умолчанию BIS, не окажет большого влияния на производительность.
Или программа является зависящим от ЦП в MessageDigest.update (), и большинство времени не потрачено в коде приложения, так тонкая настройка, это не поможет.
(Хм... с несколькими ядрами, потоки могли бы помочь.)