Какой из серверов Warp и Snap-сервера Yesod следует выбрать для высокопроизводительного сервера приложений?
Я видел тесты на домашней странице Yesod, но они в основном для статических файлов. И тесты на сайте Snap устарели.
Я пытаюсь выставить модуль Haskell как сервис. Логика сервера состоит в том, чтобы получить имя функции и аргументы в json, вызвать функцию haskell и снова доставить вывод в виде json. Прозрачность ссылок гарантирует безопасность потоков и возможность запоминать и кэшировать функции.
Если бы я поддерживал одновременные соединения порядка 2–5 тыс., Как бы я реализовал это? Насколько масштабируемым может быть такой подход?
2 ответа
Я настоятельно рекомендую сделать выбор между Warp/Yesod и Snap, основываясь на том, какая система предоставляет вам лучший набор инструментов для создания вашего приложения. И Warp, и Snap используют один и тот же менеджер GHC I/O, и оба они высоко оптимизированы. Я был бы удивлен, если бы хорошо написанное приложение для каждой системы, делающее что-то нетривиальное, показало значительный разрыв в производительности.
Ваш последний абзац немного расплывчатый, но я думаю, что основной ответ для Warp или Snap - просто написать свой код, и менеджер ввода / вывода будет масштабироваться настолько хорошо, насколько это возможно. Если вы действительно находите параллельные соединения узким местом, вы можете попробовать опробовать метод prefork, используя GHC 7.8 (еще не выпущен, но имеет значительно улучшенный менеджер ввода / вывода) или несколько серверов.
Большинство тестов, опубликованных для Warp и Snap, основаны на чрезвычайно простом и очень надуманном тесте, который возвращает статическую строку "pong". Это отлично подходит для оценки эффективности веб-сервера при разборе HTTP-запросов, построении HTTP-ответов и т. Д., Но в большинстве приложений время, затрачиваемое на выполнение этих задач, будет незначительным. Во-вторых, я предполагаю, что любые различия в производительности между Warp и Snap могут уменьшиться в будущем, поскольку оба сервера продолжают улучшаться и приближаются к теоретическому пределу. Кроме того, я ожидаю, что оба сервера также выиграют от улучшения производительности в GHC 7.8.
Haskell - отличный выбор для получения высокой производительности при большом количестве одновременных подключений. У Haskell есть зеленые темы, которые чрезвычайно дешевы по сравнению с темами в большинстве других языков. Это дает веб-платформам Haskell огромное преимущество. Мы можем запустить новый поток для каждого соединения и использовать огромное количество усилий, затраченных на оптимизацию GHC, для достижения высокой производительности при сохранении хорошей модели программирования.
Относительно Yesod против Snap есть причина, по которой эти два проекта существуют как отдельные. Они подходят к проблеме веб-разработки в Haskell с двух совершенно разных направлений. Они оба выигрывают от производительности, которую дает вам Haskell, поэтому вы должны выбирать между ними в зависимости от того, какой подход вы предпочитаете. Вот несколько ресурсов, с которых можно начать: