Что Вы рекомендуете для установки общего сервера с [закрытым] php
Ваш потоковый код не будет даже сортировать карту, потому что он выполняет операцию с HashMap, который по своей природе не отсортирован. Чтобы заставить ваш второй пример потока работать, вы можете использовать LinkedHashMap, который поддерживает порядок вставки:
Map<String, Integer> sortedMap = new LinkedHashMap<>();
unsortMap.entrySet()
.stream()
.sorted(Map.Entry.comparingByKey())
.forEachOrdered(x -> sortedMap.put(x.getKey(), x.getValue()));
Но теперь ваши два примера даже не имеют одинаковую структуру данных. TreeMap поддерживается деревом (красно-черным, если я правильно помню). Вы бы использовали TreeMap, если хотите иметь возможность выполнять итерацию в отсортированном виде или быстро искать ключ. LinkedHashMap - это hashmap со связанным списком, проходящим через него. Вы можете использовать это, если вам нужно поддерживать порядок вставки, например, при реализации очереди.
4 ответа
Лично, в то время как Lighttpd в порядке, я пошел бы с Nginx + FastCGI, если Вы заканчиваете тем, что шли с легким веб-сервером + решение FastCGI. Я выполнил сравнительные тесты и прочитал весь код, и Nginx является порядком величины, быстрее/больше стабильным при загрузке - это очень хорошо.
Но, это не то, что Вы спросили. По существу я сказал бы, что существует спектр security/scaleability по сравнению с компромиссами скорости в этих трех опциях, которые Вы перечисляете, и просто необходимо решить, где Вы хотите быть. Если Вы будете общим поставщиком услуг хостинга с недоверяемыми пользователями, устанавливающими god-knows-what PHP приложения, то Вы склонитесь больше к безопасности, если это будет совместно использовано среди большего количества доверяемых пользователей, Вы могли бы склониться к производительности. Вот мои мысли:
CGI + suexec: Это является безусловно самым безопасным, и самым эффективным/масштабируемым для Вас с точки зрения числа пользователей/сайтов в общей среде хостинга. Процессы порождены, и память использовала только, поскольку запросы входят. Конечно, порождение CGI делает это самым медленным в течение времени выполнения отдельных сценариев. Насколько медленнее? Хорошо необходимо было бы сравнить, но обычно если люди запускают продолжительные приложения (т.е. что-то как WordPress, который занимает 0.25-0.5 секунды только для загрузки, освобождает и инициализирует по каждому запросу), затем порождающий CGI штраф начинает выглядеть довольно незначительным в контексте.
FastCGI: проблема здесь (и не имеет значения, если Ваш веб-сервер является Apache, Lighttpd или Nginx) выясняет, сколько дочерних процессов FCGI Вы позволяете каждому пользователю оставить выполнением, потому что каждый процесс ест память, равную размеру интерпретатора PHP (в Linux не, все это соединено проводом, конечно, но я отступаю). И, в отличие от mod_php, эти процессы не являются общими для пользователями, таким образом, необходимо ограничить на пользователя. Например, ограничения Dreamhost это в 3 для их клиентов - теперь, для клиента, выполняющего веб-сайт, который получает пакеты больше чем 2-5 просмотров страницы в секунду, это на самом деле довольно плохо, потому что те запросы просто складывают, и сайт зависает. Теперь, мне нравится FastCGI с легким веб-сервером, когда я - запущенные приложения на выделенном сервере / кластер, когда я могу дать приложению сотни детей FCGI (все с веб-сервером privs, конечно, а-ля Apache/предварительное ветвление + mod_php). Но, я не думаю, что это имеет смысл для общего хостинга, где необходимо выделить/ограничить детей FCGI на пользователя.
Apache + mod_php: наименее безопасный начиная со всего работающего с веб-сервером privs, но Вашим объединением живых процессов PHP совместно используется так, это является лучшим на конце производительности. С точки зрения разработчика я не могу терпеть php_safe режим, и с точки зрения системного администратора это - действительно только иллюзия безопасности (это смягчает против глупых пользователей, но не защищает от фактического нападения), таким образом, у меня на самом деле был бы CGI, если моя другая опция должна включать safe_mode.
Dreamhost действительно сортирует гибрида, они делают Apache CGI + suexec по умолчанию, но позволяют (маленькому) проценту их большего количества пользователей, которые сложны, выбирают делать FCGI, если они хотят согласно ограничению и их собственному контролю использования памяти. Это сохраняет тонну ресурсов памяти по сравнению с включением FCGI для всех по умолчанию.
Другая проблема, если Вы говорите о стандартном коммерческом общем хостинге, Apache полнофункционален, имеет модули для примерно чего-либо (включая материал как mod_security, который Вы могли бы хотеть), и Вашим пользователям понравится он, потому что все их конфигурации .htaccess будут работать и т.д. - Вы столкнетесь с головными болями поддержки с чем-либо еще, когда они пойдут для установки Drupal или WordPress или безотносительно (намного меньше проблемы, если мы говорим внутренние пользователи).
Лично я рекомендовал бы просто сохранить простым запуститься и идти с CGI + suexec для лучшей безопасности и scaleability. Если Ваши пользователи захотят FCGI или mod_php, и у Вас есть хороший канал, открытый для предложений/коммуникации с ними, то они попросят его, но любой из них является намного большей головной болью для Вас только с крайними повышениями производительности для них, таким образом, мое предложение не состояло бы в том, чтобы сделать ни одного из них первоначально, но является быстро реагирующим, если они требуют его.
Я действительно сочувствую требованию сделать что-то "интересное" как Lighttpd + FCGI вместо стандартного Apache + CGI + suexec, но я в глубине души я действительно не могу рекомендовать это.
При выполнении нескольких серверов Вы могли бы закончить тем, что поместили CGI на некоторых и что-то еще для продвинутых пользователей на других. И обязательно имейте крон grep все www директора для вещей как версии старой задницы phpBB!
Я использовал InterWorx приблизительно в течение года теперь и был очень впечатлен. Это поддерживает сервер ЛАМПЫ с chroots Ваши сценарии для безопасности.
Я также использовал Ensim, но не нашел его столь же дружественным, быстро и это не имеет как много функций. Плюс он стоит намного больше.
Относительно PHP + FastCGI и безопасность, проверьте это сообщение в блоге.
Проблема с обеспечением общего хостинг-сервера состоит в том, как защитить веб-сайт от нападения и с внешней стороны и с внутренней части. PHP имеет встроенные функции для помощи, но в конечном счете это - неправильное место для рассмотрения проблемы.
Я уже записал о многих решениях, которые работают, но одна опция, на которую меня попросили снова и снова посмотреть, использует PHP + FastCGI. Есть уверенность, что использование FastCGI преодолеет проблемы производительности suexec или mod_suphp Apache, потому что процессы FastCGI сохраняются между просмотрами страницы.
Но прежде чем мы можем посмотреть на производительность, первый вопрос: как точно мы получаем PHP и FastCGI, работающий как различные пользователи на одном веб-сервере во-первых?