не много и не мало прошло с момента данного поста.
случайно забрёл в свои записи на Хабре, чего не делал уже давно, и вот не могу удержаться от вопроса.
Как в итоге сложилось-то? Что выбрали? К чему пришли? 5 лет прошло как никак. Интересно всё-таки сделать ретроспективу :)
а я знаю тайное знание где за 120 стригут не практиканты )))
но да не в этом дело.
Дело в том, что у программистов не развито практически чувство старшего мастера.
Мы все сами с усами. И сами рвёмся в бой с пылким взором!
В итоге и получается то, что получается.
Просто автор пишет о следствиях, тогда как давно пора задуматься о причинах и способах устранения их из ИТшной проф. области.
в целом верно всё написано, и способность выбрать наиболее эффективный способ реализации адекватный поставленной задачи (сложность, сроки и т.п.) это признак профессионала.
Но есть одно НО.
Есть задачи в которых требования меняются со временем. Увеличивается нагрузка посещаемостью, требования по оформлению и т.д. и т.п.
И чертовски обидно когда приходят и говорят «что же ты зараза сделал всё так плохо, что вот N месяцев спустя у нас ничего не работает». Упуская момент что N месяцев оно всё работало, а сейчас изменились бизнесс требования.
Архитекторов, например, не заставляют перестроить здание в краткие сроки через пару лет, существенно изменяя изначальные требования.
Текст написан с одной стороны, и да, нужно быть профессионалом и не увлекаться, когда речь идёт о реальном проекте, реальных деньгах и ограниченном времени.
Однако, к ИТ специалистам, как к футболистам и политикам, есть такое отношение со стороны народа, что народ всегда знает как сделать лучше. Что фигнёй мы занимаемся и сложного-то ничего в работе нет.
Вот это заблуждение так же надо искоренять из работодателей, заказчиков и менеджеров. Тогда будут и повышения квалификации и нормальное отношение программистов к выполнению своих обязанностей, без чрезмерного увлечения технологиями.
У нас же в ИТ порой каждый менеджер «знает как лучше» и «знает как быстрее», о чём обязательно уведомляет программиста, рассказывает ему своё мнение, заставляет выслушать, отъедая тем самым рабочее время, а потом ещё за это же время пеняет, что мол не уложился, дурью маялся.
а что делать? врачами знаете ли тоже сразу не становятся. и рано или поздно те же интерны начинают ставить эксперименты на живых пациентах, точнее тренироваться.
Так же как и парикмахеры и прочие специальности.
imho, результаты не могут быть взяты на веру, так как у вас слишком много случайных факторов (медленный канал со скачками скорости, нагрузка на сервер и разница в скорости выдачи им результатов, другие процессы на вашей машине с браузером)
и к тому же " Прогонял каждый сайт по одному разу "
Бенчмарк подразумевает многократные повторения и сбор статистической информации.
В то же время сама тема интересная, но измерения надо производить тогда уж на той же машине, где крутятся браузеры, чтобы убрать фактор случайностей в канале и на серверах, повторять на одном и том же контенте и многократно. И явно ловить момент окончания рендеринга и от него отсчитывать милисекунды до показа, потому что именно это время будет бесполезным.
В любом случае, пользователь не готов видеть чистый не отрендереный html, который дёргается и извивается по мере загрузки стилей и скриптов, пользователя это напугает и он начнёт звонить администратору с криками «Алярма! Алярма! Вирусы!»
Исследование бред.
Даже если это поп-ап и при нажатии на ОК чтото зловредное произойдёт, неужели там в тексте будет написано чтото вроде
«А вы (0xff6729cd) не возражаете if мы вам %username% винт форматнём rightnow потому что он can not be 'read'?»
А исходя из выводов, которые делают авторы исследования, можно сделать вывод, что авторы исследования линуксоиды холиварщики ))))))))))
Кстати, справедливости ради следует добавить, что чем меньше данных надо за раз залить, то разница соответственно будет чувствоваться меньше.
И, конечно же, зависит от того, что является приемлемым временем выполнения задачи заливки.
импортировались записи блоками разных размеров, 1000, 5000, 10000, 25000 и 50000, выходило, что чем меньше размер пакета данных, тем больше времени затрачивается на заливку данных.
Пробовалось как на InnoDB так и на MyISAM. На последнем при отключенной перестройке индексов скорость была выше, норазница сохранялась.
Точных цифр не скажу, так как было это больше полугода назад, но переход на генерацию sql-файла и его заливку вместо прямой передачи генерируемых данных в БД уменьшил время заливки данных в БД на порядок, а переход с sql-файла на CSV и LOAD DATA INFILE ещё на 30%.
Причём, чем больше необходимо залить данных, тем ощутимее становится разница.
это проверялось на практике при вставке 800 с чем-то там тысяч записей…
но даже если просто логически подойти к этому вопросу, то получается 10 000 запросов, а это 10 000 разборов запроса, 10 000 — 1 ожиданий для каждого следующего запроса пока выполнится предыдущий, не говоря уже о затратах на межпроцессное взаимодействие при передаче данных.
случайно забрёл в свои записи на Хабре, чего не делал уже давно, и вот не могу удержаться от вопроса.
Как в итоге сложилось-то? Что выбрали? К чему пришли? 5 лет прошло как никак. Интересно всё-таки сделать ретроспективу :)
но да не в этом дело.
Дело в том, что у программистов не развито практически чувство старшего мастера.
Мы все сами с усами. И сами рвёмся в бой с пылким взором!
В итоге и получается то, что получается.
Просто автор пишет о следствиях, тогда как давно пора задуматься о причинах и способах устранения их из ИТшной проф. области.
Но есть одно НО.
Есть задачи в которых требования меняются со временем. Увеличивается нагрузка посещаемостью, требования по оформлению и т.д. и т.п.
И чертовски обидно когда приходят и говорят «что же ты зараза сделал всё так плохо, что вот N месяцев спустя у нас ничего не работает». Упуская момент что N месяцев оно всё работало, а сейчас изменились бизнесс требования.
Архитекторов, например, не заставляют перестроить здание в краткие сроки через пару лет, существенно изменяя изначальные требования.
Текст написан с одной стороны, и да, нужно быть профессионалом и не увлекаться, когда речь идёт о реальном проекте, реальных деньгах и ограниченном времени.
Однако, к ИТ специалистам, как к футболистам и политикам, есть такое отношение со стороны народа, что народ всегда знает как сделать лучше. Что фигнёй мы занимаемся и сложного-то ничего в работе нет.
Вот это заблуждение так же надо искоренять из работодателей, заказчиков и менеджеров. Тогда будут и повышения квалификации и нормальное отношение программистов к выполнению своих обязанностей, без чрезмерного увлечения технологиями.
У нас же в ИТ порой каждый менеджер «знает как лучше» и «знает как быстрее», о чём обязательно уведомляет программиста, рассказывает ему своё мнение, заставляет выслушать, отъедая тем самым рабочее время, а потом ещё за это же время пеняет, что мол не уложился, дурью маялся.
Так же как и парикмахеры и прочие специальности.
всё таки Хабр он мужского рода, не? =)
а вы пишете о 30-40 секундах на загрузку? так это проблема канала а не браузеров )
и к тому же
" Прогонял каждый сайт по одному разу "
Бенчмарк подразумевает многократные повторения и сбор статистической информации.
В то же время сама тема интересная, но измерения надо производить тогда уж на той же машине, где крутятся браузеры, чтобы убрать фактор случайностей в канале и на серверах, повторять на одном и том же контенте и многократно. И явно ловить момент окончания рендеринга и от него отсчитывать милисекунды до показа, потому что именно это время будет бесполезным.
В любом случае, пользователь не готов видеть чистый не отрендереный html, который дёргается и извивается по мере загрузки стилей и скриптов, пользователя это напугает и он начнёт звонить администратору с криками «Алярма! Алярма! Вирусы!»
1-ая кружка/стопка
2-ая кружка/стопка
…
9-ая кружка/стопка
0 — ну и уже в ноль к этому моменту и спать )))
Кто его знает к чему это )))
Лишать доступа даже в персональный блог. Это уже статус ХабраБомж будет.
Даже если это поп-ап и при нажатии на ОК чтото зловредное произойдёт, неужели там в тексте будет написано чтото вроде
«А вы (0xff6729cd) не возражаете if мы вам %username% винт форматнём rightnow потому что он can not be 'read'?»
А исходя из выводов, которые делают авторы исследования, можно сделать вывод, что авторы исследования линуксоиды холиварщики ))))))))))
И, конечно же, зависит от того, что является приемлемым временем выполнения задачи заливки.
Пробовалось как на InnoDB так и на MyISAM. На последнем при отключенной перестройке индексов скорость была выше, норазница сохранялась.
Точных цифр не скажу, так как было это больше полугода назад, но переход на генерацию sql-файла и его заливку вместо прямой передачи генерируемых данных в БД уменьшил время заливки данных в БД на порядок, а переход с sql-файла на CSV и LOAD DATA INFILE ещё на 30%.
Причём, чем больше необходимо залить данных, тем ощутимее становится разница.
но даже если просто логически подойти к этому вопросу, то получается 10 000 запросов, а это 10 000 разборов запроса, 10 000 — 1 ожиданий для каждого следующего запроса пока выполнится предыдущий, не говоря уже о затратах на межпроцессное взаимодействие при передаче данных.