Это не так чтобы очень долго, но и не быстро. Считается, что меньше 2 секунд — это приемлемый результат для среднестатистического сайта.
Но, учитывая достаточно простой дизайн (малое кол-во картинок и CSS) и практически пустую БД, можно было ожидать хотя бы в районе 0.5 секунды.
Обратите внимание, что у Вас плохие показатели по Initial connection и по TTFB. Не факт, что Вы можете на них повлиять, т.к. они зависят от настроек сервера. Но дело в том, что они добавляют сотни миллисекунд оверхеда, на фоне которых экономия пары миллисекунд за счёт применения ассемблера совсем потерялась.
При оптимизации сайтов главная метрика — load time, а не время генерации на сервере. Да и временем генерации ответа за миллисекунды сложно удивить, было бы меньше 1 ms — было бы круто. А текущие результаты (6 — 30 ms) можно и на ЯВУ воспроизвести. Т.е. в теории выигрыш от применения ассемблера должен быть, но на данном примере его не видно.
Ну, ё-моё, опять 25… Забудьте Вы уже про скорость… Абстрагируйтесь от неё, если морфологическое сходство слов вас так сильно запутывает. Тем более, что такого термина как "скорость выполнения" в принципе нет в бенчмарках.
Бенчмарки меряют время ожидания (latency в секундах) и считают пропускную способность (throughput в ips или в rps).
При этом изменения latency обычно считают в процентах, а изменения throughput — в разах.
Ускорилось на 50% = latency уменьшилось на 50% = throughput вырос в 2 раза = ускорилось в 2 раза.
Вы же пытаетесь ввести какую-то свою терминологию, и не понятно откуда Вы её вообще взяли… Мне прям даже интересно на базе чего Вы так упорствуете… Дайте хоть ссылку на какую-нибудь benchmark-утилиту, которая вашей методологии подсчётов придерживается.
Автор конечно крут, но надо учитывать сколько лет он до этого писал на ассемблере… Я думаю, если взять такой же опыт в веб-программировании, то все абстракции будут уже давно вкурены и изучить какой-нибудь ещё один фреймворк можно будет за день :-)
Было бы интересно (откровенно говоря только в этом и интерес) провести полное нагрузочное тестирование этого решения.
Тут есть проблемка… Автор хорошо разбирается в ассемблере, но плохо в веб-программировании… Поэтому сайт получился не особо быстрый с точки зрения пользователя. Для примера запустил простенький тест на LoadImpact. VU load time получился в районе 2.3 секунды (даже всего при 3 посетителях), это уже медленно.
Так что устраивать серьёзное нагрузочное тестирование смысла нет. Веб-сервер скорее всего не настроен должным образом и просто захлебнется под нагрузкой даже не дойдя до кода автора.
Для сравнения у Хабра VU load time в районе 1.7 секунды (быстрее 2 секунд — это хороший результат).
И что? Мы измеряем время в рамках бенчмарков, ips — это производная (вычисляемая, а не измеряемая) характеристика. Ускорить алгоритм == сократить время его выполнения. Это общепринятая трактовка.
Другими словами, ускорение на 67% == ips вырос на 200%.
Поймите простую вещь, "рост ips" и "ускорение" — это не синонимы ни разу.
Было 100 ms, стало в 3 раза быстрее, т.е. стало 33 мс. Так понятнее?
Слово "ускорился" в контексте быстродействия синоним слова "подешевел".
Функция ускорилась в 2 раза == Функция подешевела в 2 раза == Стала занимать в 2 раза меньше времени.
Функция ускорилась на 50% == Функция подешевела на 50% == Стала занимать на 50% меньше времени.
Аллюзии к слову "скорость" тут совсем не в тему. У меня странное ощущение, от того, что мне приходится разжевывать такую базовую тему на Хабре… Причём эффекта ноль, никто даже не пытается задуматься над неверным пониманием этого аспекта.
Я понял Вашу отсылку к физическому понятию "скорость", но, к сожалению, как физик, вынужден отметить, что Ваши формулировки безграмотны с точки зрения физики и знак "=" там не уместен, т.к. у слова "ускорение" совершенно иной физический смысл, и ни в процентах, ни в разах оно в физике не измеряется.
Ничего я не путаю, увеличение скорости вычислений в 3 раза — это и есть сокращение времени вычислений на 67%… И то и то упрощенно называется ускорением.
А если хотите морфологией заняться, то не забывайте, что ускорение — это производная от скорости по времени, удачи в трактовке ;-)
С делением ЯВУ на классы я согласен, хотя там можно ещё интерпретаторы с JIT в отдельный класс выделить. А вот с тенденцией не согласен. Наоборот, тенденция писать на скриптовых языках слабеет с каждым годом. Народ активно смотрит в сторону Go, Elixir, Crystal, Nim, Clojure, etc.
Другое дело, что необязательно бросать все существующие наработки на PHP, Ruby, Python и JS. Во многих случаях достаточно выделить узкие места в отдельные сервисы на более быстрых языках, а ненагруженную часть проекта оставить, как есть.
P.S. Мне лично тоже нравится писать быстрый код, но опыт работы показывает, что в первую очередь бизнесу быстро нужен код, а не быстрый код.
Правильный вариант Вашего комментария звучит так:
"Ускорить на 66.(6)% = ускорить в 3 раза = увеличить скорость в 3 раза. Есть такая величина. Скорость."
P.S. Любая величина изначально принимается за 100% при расчётах. Допустим, после оптимизации стало в 3 раза быстрее, т.е. (100/3)% от начального значения, значит мы ускорили на (100 — 100/3)%.
Стало лучше. Но, справедливости ради, первоначально речь шла о потенциале ускорения от переписывания на асме. Фиг знает, причём тут потенциал замедления от обратного переписывания и к чему вдруг Вы начали его считать..
И давайте представим, что БД тоже написал «эффективный программист», на PHP…
Вы понимаете смысл оптимизации узких мест? Хранилище данных очень часто оказывается узким местом, именно поэтому в оптимизацию СУБД вложено столько человеко-лет. И несмотря на это когда нужна действительно высокая пропускная способность всё равно приходится отходить от реляционной модели.
Проблема в том, что ассемблер не поможет написать отзывчивый высоконагруженный веб-сервис… вроде и потенциал есть, но по факту граблей больше. И даже отличные знания асма, на уровне автора статьи, не застрахуют Вас от performance-ляпов, как у автора получилось со страницей тредов по тегу (20-30 мс там, где должно быть 7-8 мс). При использовании ЯВУ такие performance-ляпы встречаются реже, т.к. можно сконцентрироваться на оптимизации узких мест, не распыляясь на оптимизацию каждой функции.
Да, я потом уже почитал, что он закрылся… Печально, конечно, но посыл был в том, чтобы для экономии бюджета использовать чужие наработки в виде движков, текстур и т.д. Если делать всё самому при ограниченных ресурсах, то легче лёгкого закопаться в мелочах.
Есть ещё такое понятие Minimal Viable Product… Его можно сделать на чём угодно, лишь бы сэкономить на ресурсах, а потом его уже показывать, собирать обратную связь, искать инвесторов… И если интерес к проекту будет, то можно уже с нуля переписать.
Не выдумывайте! Считать не умеете Вы… Нельзя что-то ускорить на 200%. Максимум можно ускорить на 100% и это уже будет в бесконечность раз быстрее. А на 200% можно только замедлить.
Можно взять другие тесты.
Можно, только зачем, если в среднестатическом случае (для вышеописанного класса задач) 70% времени всё равно придётся на запросы к БД. Даже если весь остальной код будет выполняться за пару наносекунд, Вы всё равно получите лишь 30% ускорения. Учитывайте матчасть, а не только синтетику.
Если язык разработки будет статически и строго типизированным и компилируемым
Отличная идея! Только причём тут low-level? В ассемблере типизации вообще нет, в Си она слабая… А под Ваш критерий лучше подходит Haskell, или Idris, или на крайний случай Crystal.
Интерпретатор проигрывает маш.коду в 100 раз. Это на 9900%
Какая у Вас интересная версия математики… в 100 раз быстрее == на 99% быстрее.
Только причём тут это вообще? Я же написал "на данном классе задач", т.е. рендеринг простеньких HTML-страниц на основании данных, полученных из реляционной СУБД.
Каким боком тут Dhrystone, актуальность которого осталась где-то в 80-х? Или при взгляде на великолепные результаты ассемблера в синтетическом бенчмарке у вас автомагически SQL быстрее работать начинает?
PostgreSQL и MySQL иногда трудно использовать на виртуальном хостинге.
Это наверно большая редкость… Хоть я уже лет 7 вирутальным хостингом не пользуюсь, но не помню, чтобы с этим хоть раз были проблемы… Неужели за предыдущие 7 лет ситуация с виртуальным хостингом так ухудшилась?
Производительность на демо сервере сравнивать не очень удобно. Там у провайдера есть какое-то распределение ресурсов и иногда все начинает работать 2..3 раза медленнее.
Не, дело не в этом. Да, иногда по тегу и больше 100 мс ответ занимает, но чаще всего попадает в диапазон 20-30 мс и тут явно есть performance-bug.
P.S. Ещё на порядок сортировки тредов обратите внимание:
Движки форумов тоже разные по степени навороченности бывают. Если честно сравнивать, то затраты на SQL будут одинаковые. А дальше идет разница: время ответа HTTP-сервера (не более 0.02 мс везде), шаблонизатор (тут большую часть времени отожрёт Markdown, так что тоже будет примерно одинаково), оверхэд на ORM/QueryBuilder (в данном случае он небольшой, т.к. запросы тривиальные), вспомагательные мидлвары.
Другими словами, я бы не ожидал ускорения за счёт применения ассемблера более, чем на 20-30% при честном сравнении на данном классе задач.
Это не так чтобы очень долго, но и не быстро. Считается, что меньше 2 секунд — это приемлемый результат для среднестатистического сайта.
Но, учитывая достаточно простой дизайн (малое кол-во картинок и CSS) и практически пустую БД, можно было ожидать хотя бы в районе 0.5 секунды.
Обратите внимание, что у Вас плохие показатели по Initial connection и по TTFB. Не факт, что Вы можете на них повлиять, т.к. они зависят от настроек сервера. Но дело в том, что они добавляют сотни миллисекунд оверхеда, на фоне которых экономия пары миллисекунд за счёт применения ассемблера совсем потерялась.
Ассемблер то быстрый, а сайт получился медленный:
При оптимизации сайтов главная метрика — load time, а не время генерации на сервере. Да и временем генерации ответа за миллисекунды сложно удивить, было бы меньше 1 ms — было бы круто. А текущие результаты (6 — 30 ms) можно и на ЯВУ воспроизвести. Т.е. в теории выигрыш от применения ассемблера должен быть, но на данном примере его не видно.
Ну, ё-моё, опять 25… Забудьте Вы уже про скорость… Абстрагируйтесь от неё, если морфологическое сходство слов вас так сильно запутывает. Тем более, что такого термина как "скорость выполнения" в принципе нет в бенчмарках.
Бенчмарки меряют время ожидания (latency в секундах) и считают пропускную способность (throughput в ips или в rps).
При этом изменения latency обычно считают в процентах, а изменения throughput — в разах.
Ускорилось на 50% = latency уменьшилось на 50% = throughput вырос в 2 раза = ускорилось в 2 раза.
Вы же пытаетесь ввести какую-то свою терминологию, и не понятно откуда Вы её вообще взяли… Мне прям даже интересно на базе чего Вы так упорствуете… Дайте хоть ссылку на какую-нибудь benchmark-утилиту, которая вашей методологии подсчётов придерживается.
Автор конечно крут, но надо учитывать сколько лет он до этого писал на ассемблере… Я думаю, если взять такой же опыт в веб-программировании, то все абстракции будут уже давно вкурены и изучить какой-нибудь ещё один фреймворк можно будет за день :-)
Тут есть проблемка… Автор хорошо разбирается в ассемблере, но плохо в веб-программировании… Поэтому сайт получился не особо быстрый с точки зрения пользователя. Для примера запустил простенький тест на LoadImpact. VU load time получился в районе 2.3 секунды (даже всего при 3 посетителях), это уже медленно.
Так что устраивать серьёзное нагрузочное тестирование смысла нет. Веб-сервер скорее всего не настроен должным образом и просто захлебнется под нагрузкой даже не дойдя до кода автора.
Для сравнения у Хабра VU load time в районе 1.7 секунды (быстрее 2 секунд — это хороший результат).
И что? Мы измеряем время в рамках бенчмарков, ips — это производная (вычисляемая, а не измеряемая) характеристика. Ускорить алгоритм == сократить время его выполнения. Это общепринятая трактовка.
Другими словами, ускорение на 67% == ips вырос на 200%.
Поймите простую вещь, "рост ips" и "ускорение" — это не синонимы ни разу.
Было 100 ms, стало в 3 раза быстрее, т.е. стало 33 мс. Так понятнее?
Слово "ускорился" в контексте быстродействия синоним слова "подешевел".
Функция ускорилась в 2 раза == Функция подешевела в 2 раза == Стала занимать в 2 раза меньше времени.
Функция ускорилась на 50% == Функция подешевела на 50% == Стала занимать на 50% меньше времени.
Аллюзии к слову "скорость" тут совсем не в тему. У меня странное ощущение, от того, что мне приходится разжевывать такую базовую тему на Хабре… Причём эффекта ноль, никто даже не пытается задуматься над неверным пониманием этого аспекта.
Я понял Вашу отсылку к физическому понятию "скорость", но, к сожалению, как физик, вынужден отметить, что Ваши формулировки безграмотны с точки зрения физики и знак "=" там не уместен, т.к. у слова "ускорение" совершенно иной физический смысл, и ни в процентах, ни в разах оно в физике не измеряется.
Ничего я не путаю, увеличение скорости вычислений в 3 раза — это и есть сокращение времени вычислений на 67%… И то и то упрощенно называется ускорением.
А если хотите морфологией заняться, то не забывайте, что ускорение — это производная от скорости по времени, удачи в трактовке ;-)
С делением ЯВУ на классы я согласен, хотя там можно ещё интерпретаторы с JIT в отдельный класс выделить. А вот с тенденцией не согласен. Наоборот, тенденция писать на скриптовых языках слабеет с каждым годом. Народ активно смотрит в сторону Go, Elixir, Crystal, Nim, Clojure, etc.
Другое дело, что необязательно бросать все существующие наработки на PHP, Ruby, Python и JS. Во многих случаях достаточно выделить узкие места в отдельные сервисы на более быстрых языках, а ненагруженную часть проекта оставить, как есть.
P.S. Мне лично тоже нравится писать быстрый код, но опыт работы показывает, что в первую очередь бизнесу быстро нужен код, а не быстрый код.
Правильный вариант Вашего комментария звучит так:
"Ускорить на 66.(6)% = ускорить в 3 раза = увеличить скорость в 3 раза. Есть такая величина. Скорость."
P.S. Любая величина изначально принимается за 100% при расчётах. Допустим, после оптимизации стало в 3 раза быстрее, т.е. (100/3)% от начального значения, значит мы ускорили на (100 — 100/3)%.
Стало лучше. Но, справедливости ради, первоначально речь шла о потенциале ускорения от переписывания на асме. Фиг знает, причём тут потенциал замедления от обратного переписывания и к чему вдруг Вы начали его считать..
Вы понимаете смысл оптимизации узких мест? Хранилище данных очень часто оказывается узким местом, именно поэтому в оптимизацию СУБД вложено столько человеко-лет. И несмотря на это когда нужна действительно высокая пропускная способность всё равно приходится отходить от реляционной модели.
Проблема в том, что ассемблер не поможет написать отзывчивый высоконагруженный веб-сервис… вроде и потенциал есть, но по факту граблей больше. И даже отличные знания асма, на уровне автора статьи, не застрахуют Вас от performance-ляпов, как у автора получилось со страницей тредов по тегу (20-30 мс там, где должно быть 7-8 мс). При использовании ЯВУ такие performance-ляпы встречаются реже, т.к. можно сконцентрироваться на оптимизации узких мест, не распыляясь на оптимизацию каждой функции.
Да, я потом уже почитал, что он закрылся… Печально, конечно, но посыл был в том, чтобы для экономии бюджета использовать чужие наработки в виде движков, текстур и т.д. Если делать всё самому при ограниченных ресурсах, то легче лёгкого закопаться в мелочах.
Есть ещё такое понятие Minimal Viable Product… Его можно сделать на чём угодно, лишь бы сэкономить на ресурсах, а потом его уже показывать, собирать обратную связь, искать инвесторов… И если интерес к проекту будет, то можно уже с нуля переписать.
Да, тоже вариант. Он мне просто по субъективным причинам (не относящимся к типизации) меньше нравится, чем вышеуказанные языки.
Не выдумывайте! Считать не умеете Вы… Нельзя что-то ускорить на 200%. Максимум можно ускорить на 100% и это уже будет в бесконечность раз быстрее. А на 200% можно только замедлить.
Можно, только зачем, если в среднестатическом случае (для вышеописанного класса задач) 70% времени всё равно придётся на запросы к БД. Даже если весь остальной код будет выполняться за пару наносекунд, Вы всё равно получите лишь 30% ускорения. Учитывайте матчасть, а не только синтетику.
Ok, шляпка шурупчика не особо привлекает внимание.
Отличная идея! Только причём тут low-level? В ассемблере типизации вообще нет, в Си она слабая… А под Ваш критерий лучше подходит Haskell, или Idris, или на крайний случай Crystal.
Какая у Вас интересная версия математики… в 100 раз быстрее == на 99% быстрее.
Только причём тут это вообще? Я же написал "на данном классе задач", т.е. рендеринг простеньких HTML-страниц на основании данных, полученных из реляционной СУБД.
Каким боком тут Dhrystone, актуальность которого осталась где-то в 80-х? Или при взгляде на великолепные результаты ассемблера в синтетическом бенчмарке у вас автомагически SQL быстрее работать начинает?
Это наверно большая редкость… Хоть я уже лет 7 вирутальным хостингом не пользуюсь, но не помню, чтобы с этим хоть раз были проблемы… Неужели за предыдущие 7 лет ситуация с виртуальным хостингом так ухудшилась?
Не, дело не в этом. Да, иногда по тегу и больше 100 мс ответ занимает, но чаще всего попадает в диапазон 20-30 мс и тут явно есть performance-bug.
P.S. Ещё на порядок сортировки тредов обратите внимание:
Движки форумов тоже разные по степени навороченности бывают. Если честно сравнивать, то затраты на SQL будут одинаковые. А дальше идет разница: время ответа HTTP-сервера (не более 0.02 мс везде), шаблонизатор (тут большую часть времени отожрёт Markdown, так что тоже будет примерно одинаково), оверхэд на ORM/QueryBuilder (в данном случае он небольшой, т.к. запросы тривиальные), вспомагательные мидлвары.
Другими словами, я бы не ожидал ускорения за счёт применения ассемблера более, чем на 20-30% при честном сравнении на данном классе задач.