Я предлагаю взять более-менее реалистичную задачу и погонять её под более-менее реалистичными тестами. Например:
Архитектура: приложение, 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), эффективность использования ресурсов машины. Причём в пропорциях, обычных для веб-приложений. Что скажете? Есть у кого время написать такие приложения на разных языках? On Tue Feb 10 2015 at 19:57:44 Михаил Монашёв <[email protected]> wrote: > Здравствуйте, Alexander. > > > К бэкендам лучше ходить. Иначе это опять какая-то синтетика, которая > > проверяет производительность парсера HTTP, генератора ответов. > > А так добавится парсер ответов от мемкешеда и генератор запросов к > нему. :-) Ты ещё подумай, как сильно это усложнит написание кода на > разных языках. > > Чтобы не спорить можно 2 варианта сделать: с и без запросов к > мемкешеду. Так пойдёт? > > > -- > С уважением, > Михаил mailto:[email protected] > > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org >
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
