[Moscow.pm] Сравнение языков

[Dmitry Smal]

Потому что 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 Михаил Монашёв 
>>> <postmaster на softsearch.ru <mailto:postmaster на softsearch.ru>> 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:postmaster на softsearch.ru
>>>     <mailto:postmaster на softsearch.ru>
>>>
>>>     --
>>>     Moscow.pm mailing list
>>>     moscow-pm на pm.org <mailto:moscow-pm на pm.org> | http://moscow.pm.org
>>>
>>>
>>>
>>
>>
>>
>
>
>

----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150212/82c5bfae/attachment-0001.html>