Комментарии 30
>>Если на веб-проекте часто меняется верстка будет сложно, очень сложно поддерживать Selenium-тесты в актуальном состоянии
Поверьте, не сложно. Нужно всего лишь иметь классы с префиксом Selenium- И использовать их только для тестов. Ну конечно еще не обойтись без грамотного фронтендера.
Поверьте, не сложно. Нужно всего лишь иметь классы с префиксом Selenium- И использовать их только для тестов. Ну конечно еще не обойтись без грамотного фронтендера.
Это сначала не сложно. Я встречал веб-проекты, не раз, где тестировщики и прикрепленные к ним программисты только и занимались, что адаптировали тесты к изменяющися требованиям и когда их число стало приближаться к числу боевых разработчиков, люди задумались — мы на верном пути? :-)
Соглашусь, техника будет работать, если проект небольшой, развивается медленно, есть время навести марафет, как говориться.
Соглашусь, техника будет работать, если проект небольшой, развивается медленно, есть время навести марафет, как говориться.
Я с вами не соглашусь, касательно больших сложных, быстро изменяющихся проектов — часто изменение верстки — это изменение интерфейсов, их поведения и т.п.
Каждый раз при этом приходится переписывать касающиеся их тесты почти целиком. При этом тестов становится очень много, и в них самих уже могут появляться ошибки и неучтенные моменты, а еще и покрытие на 100% всех вероятных случаев обеспечить нереально.
В таком случае Selenium это далеко не панацея, а просто инструмент который отчасти может помочь.
Каждый раз при этом приходится переписывать касающиеся их тесты почти целиком. При этом тестов становится очень много, и в них самих уже могут появляться ошибки и неучтенные моменты, а еще и покрытие на 100% всех вероятных случаев обеспечить нереально.
В таком случае Selenium это далеко не панацея, а просто инструмент который отчасти может помочь.
Интуитивно понимаешь, что Selenium нужен, и unit-ы нужны, но также понимаешь, что требования меняются не по прихоти манагеров, а так рынок устроен — и понимаешь, почему проекты в веб появляются и подолгу висят в статусе beta — это единственный разумный и недорогой способ их постоянно тестировать :-)
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Так пятница же :-) Хочется провести два ближайших прекрасных весенних теплых выходных дня поближе к природе и подальше от жесткого хардкора прикладной математики и обезглавленных жучков-багов, псевдослучайно рассыпанных на полу серверной и изредка подергивающих лапками и усиками под действием сквозняка охлаждающего кондиционера ЦОД :-)
«Совы не те, кем они кажутся» :-)
Какие-то жуткие битриксные костыли. Хорошо рубистам с newrelic, airbrake, etc. И да, тесты надо просто уметь писать.
>Если у вас веб-кластер
черверт миллиона на софт не каждый отдаст.
черверт миллиона на софт не каждый отдаст.
совы прикольные
pinba рулит, используйте ее!
спасибо за подсказку xhprof- буду курить!
2 сек на запрос — это жесть! мой HiLoad 5-7 ms — это норма.
спасибо за подсказку xhprof- буду курить!
2 сек на запрос — это жесть! мой HiLoad 5-7 ms — это норма.
Ну тут такая история. Получение ключа из memcached, расположенного в локальной сети — не меньше 1ms, запрос к mysql — несколько ms. А если приложение обладает сложной бизнес-логикой, то запросы к БД выполняются часто, а к кешу — постоянно. 5-7 ms это видимо простой оптимизированный веб-сервис без админок и многопоточной загрузки файлов?
причем тут админка, файлы вы тоже через php отдаете? ;)
>5-7 ms это видимо простой оптимизированный веб-сервис
не простой, а специфичный — много бизнес логики, полностью nosql, удачная архитектура и быстрые хорошо настроенные сервера.
>5-7 ms это видимо простой оптимизированный веб-сервис
не простой, а специфичный — много бизнес логики, полностью nosql, удачная архитектура и быстрые хорошо настроенные сервера.
Так nosql как раз и придумали для простых веб-приложений, где целостность и транзакционность не нужна :-) Серьезные бизнес-платформы будут жить на ACID-принципах, выполнять сложные выборки и надежно фиксировать транзакции, связанные с деньгами клиентов. Правда, если весь контент закэшировать в html и отдать через nginx то конечно, можно за 5 ms успеть, я так тоже умею.
Так nosql как раз и придумали для простых веб-приложений, где целостность и транзакционность не нужна :-)Транзакционность поддерживается в ряде NoSQL
иначе не вылезла бы CAP ...
Серьезные бизнес-платформы будут жить на ACID-принципах, выполнять сложные выборки и надежно фиксировать транзакции, связанные с деньгами клиентов.это верно, но выборки вероятно можно упростить, или некоторые из них подготовить заранее :), а вот от транзакций связанных с платежами конечно не скрыться. И в этом месте безусловно можно пожертвовать производительностью. И Я был бы безмерно счастлив, если бы платежные транзакции на моем сервисе совершались хотя бы раз в секунду! Я даже готов отдавать стр «проведения платежа» за 0.98 сек. Да при таком потоке бабла исключительно только для «страницы проведения платежей» я готов забашлять выделенный сервер или даже два, если один не будет справляться…
Компонент Model (самый ресурсоемкий): Если мы говорим об электронном магазине, то не закешированная страница электронного каталога, используя sphx +первичный ключ БД вполне может полностью сформировать данные за 0.2-2ms
если мы начнем наворачивать ORM то отдача возрастет до 140ms и более…
и это к сожалению правда жизни.
Компонент View: Хотите быстро формировать контент — не используйте стандартные шаблонизаторы. Мы предварительно «компилим» шаблоны в шаблонную строку, а потом просто используем sprintf который формирует необходимый контент методом подстановки. А разве шаблонизаторы работают не так???
И это работает даже быстрее чем блиц alexeyrybak.com/blitz/blitz_ru.htm
Я трейсил шаблонизатор. Он составляет до 1-2% времени формирования стр. Это еще может сэкономить 0.5-3 ms (в зависимости от сложности шаблонной логики и используемого шаблонизатора)
Компонент: Controller. мы используем nginx в качестве контроллера. Он разруливает урлы и в параметре page fastCGI переменной передает имя класса, который нужно подгрузить. На этом экономим еще 1-2 ms.
Конечно со всем этим хозяйством геморой: нужно запускатиь скрипты компиляции шаблонов и настройки конфигов nginx перед дистрибьюцией продукта или после апдейта…
хотя это делается в большинстве «простых» архитектур.
Но можно делать «правильно», а можно делать быстро
я рассказал как можно сделать быстро. Возможно есть пути сделать еще быстрее…
Я не использовал Битрикс, видел его исходники (20М) лишь десятилетней давности (знаю что сейчас уже многое соптимизированно и переписано да и самому стыдно за тот код, который я писал 5 лет назад), я не могу ни чего сказать плохого про этот продукт, Сергея Рыжкова знаю лично, возможно он меня тоже вспомнит при встречи.
То, что его продукт хорошо продается — это его большая заслуга. Значить он (продукт) полностью покрывает потребности клиентов и приносит им пользу. Трудно сделать полностью универсальное коробочное решение, удовлетворяющее все потребности.
Могу еще раз подтвердить, что в данной статье есть полезные советы и мысли…
Не раз встречал такой кейс. Собираются 2 команды. Одна пишет на ZF, вторая дописывает компоненты к Битрикс. В первой команде быстро начинает все усложняться, наиболее грамотные и имеющие слух в ООП пытаются сохранить архитектуру, тогда как все остальные уродуют созданные классы и интерфейсы — на выходе сайт вроде работает, но поддерживать его уже практически нельзя :-) Команда, создавшая проект на Битриксе — его запускает в срок, но, конечно, кроме процедурного кода компонентов и возможно немого ООП в модулях ребятам раскрыться не получилось. Для бизнеса эта команда выполнила задачу и достигла цели :-) Т.е. фреймворк решил одну из главных задач — снизил риски и сложность. Вот потом можно начать оптимизировать узкие места и переписывать хайлоадно и быстро, хоть на C, появилось дальнейшее финансирование и новые интересные требования.
> 2 сек на запрос
Собственно, по этой причине я бы и не стал доверять статьям об оптимизации производительности от «Битрикса» ;). Badoo (разработчики pinba) отдают страницы за 100-200 ms…
Собственно, по этой причине я бы и не стал доверять статьям об оптимизации производительности от «Битрикса» ;). Badoo (разработчики pinba) отдают страницы за 100-200 ms…
Ну давайте еще посмотрим тесты производительности MySQL и Oracle на простых запросах, объявим Oracle тормознутым и жирным говном и перестанем интересоваться темой оптимизации серьезных и сложных бизнес-приложений :-)
В отличии от социальной сети, Битрикс — сложная бизнес-платформа другого класса с навороченной логикой, проактивным файерволом http-траффика и веб-антивирусом на выходе, «ORM»-слоем и встроенной системой статистики и аудита безопасности. Именно поэтому крупные интернет-магазины рунета делают в основном на ней. Отказаться от ACID и джойнов, начать все шардить направо и налево, закешировать в персональном кабинете и корзине юзера html — нельзя :-) Тем не менее, 0.5 сек мы держим уверенно и постоянно улучшаем показатели производительности. А за pinba еще раз — спасибо.
В отличии от социальной сети, Битрикс — сложная бизнес-платформа другого класса с навороченной логикой, проактивным файерволом http-траффика и веб-антивирусом на выходе, «ORM»-слоем и встроенной системой статистики и аудита безопасности. Именно поэтому крупные интернет-магазины рунета делают в основном на ней. Отказаться от ACID и джойнов, начать все шардить направо и налево, закешировать в персональном кабинете и корзине юзера html — нельзя :-) Тем не менее, 0.5 сек мы держим уверенно и постоянно улучшаем показатели производительности. А за pinba еще раз — спасибо.
>Битрикс… встроенной системой статистики и аудита безопасности
у вас все ещё 150+ полей в таблице статистики (видел в последний раз её года 3-4 назад)? система безопасности которая создает иллюзию безопасности… может обойдемся без маркетингового булшита?!
у вас все ещё 150+ полей в таблице статистики (видел в последний раз её года 3-4 назад)? система безопасности которая создает иллюзию безопасности… может обойдемся без маркетингового булшита?!
Иллюзию безопасности? Да вы нюхали хоть раз поддержку миллионов клиентов и их лицевых счетов, десятков тысяч заказов и сотен сотрудников магазина в админке и оборотом несколько миллионов долларов? Ежедневно на таких проектах файервол защищает от XSS и SQL-инъекций в написанном на скорую руку говнокоде, ходящем мимо АПИ Битрикс в базу данных. Нечего сравнивать серьезные бизнес-решения с веб-сервисами на NoSQL :-)
У вас мания величия
У меня сухие факты и красивые совы :-). Просто не понимаю, когда разработчики везде упоминают умные модные словечки типа «NoSql», «настроенные сервера», «кэширование»… Достаточно раз в жизни в выводе tcpdump увидеть RTT tcp пакета до СУБД или мемкэша чтобы понять, что веб-приложения на фреймворках и не на C, состоящие из тысяч файлов классов, распределенные по кластеру машин — это сотни миллисекунд.
Отличный пост! Спасибо за подборку инструментов и методик!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Отладка сложных веб-приложений — эффективная багодробилка на production-серверах