http://www.techempower.com/benchmarks/#section=data-r9&hw=i7&test=query <http://www.techempower.com/benchmarks/#section=data-r9&hw=i7&test=query> - если это JSON serialization (время которой является определяющим фактором скорее всего), то вполне допускаю, что JSON::XS может быть круче (пока). Пока нет кода тестов - сложно говорить.
> On Feb 12, 2015, at 12:07 PM, Dmitry Smal <[email protected]> wrote: > > Потому что Go быстрее Perl. Внутри работает тотже epoll, поэтому Go так же > асинхронный. > Если по тестам получилось медленнее - значит в Go просто отрабатывает больше > кода (тесты не эквиваленты). > > > On 02/12/2015 11:37 AM, Анатолий Гришаев wrote: >> 12.02.2015 11:22, Dmitry Smal пишет: >>> Там perl (+plack) обгоняет Go. >>> Что слегка не реалистично. >>> >> А почему не реалистично сравнивать надо соответственно >> Например там Go обгоняет mojolicious, это треды, а plack это асинхронщина. >> Что доказывает, что язык на быстродействие оказывает минимальное влияние. >> >> P.S. Plack там идет под kelp-raw. >> >> >> >>> On 02/12/2015 01:33 AM, Alexander Lourier wrote: >>>> Илья Винокуров ссылку дал на сайт, где тесты разных платформ делают. У них >>>> вся тестовая среда на github выложена. Мне кажется, того, что там есть, >>>> вполне достаточно. >>>> >>>> On Wed Feb 11 2015 at 20:18:44 Михаил Монашёв <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> Здравствуйте, Alexander. >>>> >>>> > Я предлагаю взять более-менее реалистичную задачу и погонять её под >>>> > более-менее реалистичными тестами. Например: >>>> > >>>> > Архитектура: приложение, memcached, mysql. >>>> > Задача: показывать рассказы из базы данных (каждый порядка 100 >>>> > килобайт), кэшируя их в memcached (небольшого объёма). >>>> > Входной урл: "/$id". >>>> > Ключ в memcached: "$id". >>>> > Запрос к базе: "select data from stories where id=$id". >>>> > Ответ оборачивается в простенький HTML-шаблон. Все спецсимволы >>>> > заменяются на HTML entities, как положено. Новые строки - на <br>. >>>> > Результат возвращается клиенту. >>>> > >>>> > Как тестируем: >>>> > 1. запросы по небольшому подмножеству случайных ID (чтобы всё >>>> > заведомо влезало в memcached) >>>> > 2. запросы по всему множеству ID (чтобы всё не влезало в memcached и >>>> > приходилось дёргать базу) >>>> > 3. запросы по всему множеству ID, параллельно начинаем затормаживать >>>> > базу данных (lock tables write, sleep, unlock tables) >>>> > >>>> > Замеряется количество запросов в секунду, которые сервер смог >>>> > обслужить, количество ошибок в секунду, ну и latency. >>>> > >>>> > Этот тест более-менее приближен к реальным условиям и проверяет >>>> > разные возможности - интенсивный сетевой обмен, вычислительную >>>> > работу (процессинг HTML), эффективность использования ресурсов >>>> > машины. Причём в пропорциях, обычных для веб-приложений. >>>> > >>>> > Что скажете? Есть у кого время написать такие приложения на разных >>>> > языках? >>>> >>>> Тестирую сейчас твою задачу. Надо под memcached отдельный сервер, а то >>>> он много процессора кушает. У меня их 6 шт. и каждый по 25% процессора >>>> потребляет. И под БД тоже наверное не помешает, если данных будет так >>>> много, что перестанет в мемкешед влезать, то БД станет узким местом. >>>> Хотя с другой стороны можно всё на один сервер засунуть и пусть там >>>> демон, memcached и mysql вместе живут, так в реальности часто и >>>> бывает, но тогда все быстрые демоны покажут одинаковый результат. >>>> >>>> И хорошо бы где-то иметь общий для всех дамп БД, чтобы на нём можно >>>> было тестить. >>>> >>>> -- >>>> С уважением, >>>> Михаил mailto:[email protected] >>>> <mailto:[email protected]> >>>> >>>> -- >>>> Moscow.pm mailing list >>>> [email protected] <mailto:[email protected]> | http://moscow.pm.org >>>> <http://moscow.pm.org/> >>>> >>>> >>> >>> >>> >> >> >> > > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
