есть кеши, есть есть очень много решений с использованием нерелятивных баз, все работает все как часы, постепенно, постепенно выведу код чтобы деражть минимум 1кк запросов в день…
ну игра — было ОРМ «плохое», стало ОРМ заточенное :) Чем не игра:)
«низкоуровнего» скуль нет не было и не планирую использовать. (select from...)
хаков — ноль:) совершенно нет, чистая технология и возможности фреймворка…
Если говорить про слабые места — то их сейчас у меня 2:
— Т.к. django 1.3.4 юзаю — то проблема с подключениями постоянными
— Темплейт процессор у джанги хиленький… нужно менять :) Тесты можно легко найти в сети.
Это если не трогать базу:) (в плане сидеть на реляции)
и тот и тот код был с ОРМ (я говорю про свои кода)
а тут не чудо… тут техника… с выбором полей, юзаньем транзакция, проверками наличия данных, предподготовки данных… итд итп:)
То ли я писать комментарии не умею, то ли читают их через строку.
Попробую еще раз:
1. Тот скрипт, который был написан гуру владения мышкой, написали на Ruby on Rails обновление… там было 2000 товаров, обновление шло от 40 минут, и в большенстве случаев заканчивалось неудачей, ну и сайт лежал все это время
2. Когда и сайт и скрипты обновления были переписаны на Python/Django все было лучше… количество товаров увеличивалось и достигли значения в 12 тыс… Обновление шло 10 минут… ЭТО МОЙ КОД!!! МОЙ!!! КАК ПРОГРАММИСТА:) (сорри за шифт)
3. Набравшись опыта и понимая что у нас кол-во товаров резко возрастет в ближайший месяц, переписал код, использовал уже известные приемы ОРМ (все те же 5-10 приемов, но они отличные от того что было в пункте 2) и смог при увеличенном количестве товаров выдерживать небольшое время обновления.
теперь надеюсь понятна аналогия? что я сам свой же код и сравниваю…
Согласен что много. Работаю над уменьшением периодически.
Сейчас, если посмотреть статистику, время генерации страницы по сайту в среднем от 0,03 сек до 1,08 — этот диапазон в основном. Бывают проскакивают записи когда выхожу за рамку в 1,5 сек по генерации страницы, над этими страницами я и работаю по оптимизации в первую очередь. Местами удается уложиться в 8мь запросов. И это не может не радовать.
Сейчас на одном из разделов тестирую работу алгоритмов отличной от ОРМ связки. Верней там ОРМ конечно присутствует, но все же алгоритм работы другой.
Работает зашибись, скорости генерации страниц высоки, но пока есть ошибки в стабильности работы… все должно как часы там работать, а иногда появляются сбои. Как решу данную проблему, буду переписывать остальные части сайта и, наверное, начну гнобить чистый ОРМ :)
Все верно. Все обоснованно.
По скорости — в ОРМ есть косяк в т ом, непонятно сколько времени он затратит на составление запроса.
И так же есть примеры. В моем случае интересен пример обновления списка товаров с актуальными ценами и прочими подвязками из 1С на сайт.
Я опущу как было очень рано, когда мне только достался сайт, написанный тем более на РоРе, людьми которые, возможно, только с мышкой дружили… Но из моей практики было так:
— Обновление около 12 тыс товаров (читать как всего различных записей, описывающих товары) шло 10 минут (данные брались из сформированного файла 1С, указано время работы скрипта)
— Сейчас обновление занимает 1 минуту и 20-40 сек. Однако товаров (читать как и в предыдущем пункте) около 200 тыс
Достигнуто все это «игрой» с ОРМ. И да, нет у нас 100 серваков, и оптимизировать свой собственный код мы любим:)
возможно… только я говорю про 500к просмотров сайта:) каждый просмотр — в среднем (т.к. инет магазин с кучей всего) от 17 до 32 запросов на страницу… + учитывайте что они не равномерно распределены в сутках + как ни как уже оптимизировано.
необоснованное суждение
без думы юзать — согласен — выстрел получится предельно точным
если с умом подходить — получается вполне эффективный код… А буквально то нужно держать в голове 5-10 правил юзанья ОРМ и не лениться их пользовать.
на джанге с ОРМ работает у меня проект, который под НГ выдерживал нагрузку под 500к просмотров ежедневно. Вполне успешно, на среднем сервере. Пришел правда к этому постепенно, в течении года, но все же это реально.
Спасибо за статью — ушла в избранное, как ни как HL проекты на Django держу, и все может помочь.
Есть одна статейка интересная, с ссылкой на патч, тоже довольно интересный
Если я все правильно понял, то в 1.6 этот патч уже должен быть в боевом строю… поправьте, если не прав.
Прикольно
Был в Казахстане на прошлой недели… там уже была эта строка введена, думал что пропустил эту фичу в РФ… аннет, успел к ее анонсу :)
Получается тестят на казахах работоспособность:)
познакомился с dd когда лет 10-15ть назад на школьный комп, параллельно с виндой 98 воткнул линукс, и оставил виндовый загрузчик живым и невредимым. как раз через dd if=/dev/sda of=loader.bin bs=512 count=1 брался МБР и прописывался в винде, как вариант загрузки :)
«низкоуровнего» скуль нет не было и не планирую использовать. (select from...)
хаков — ноль:) совершенно нет, чистая технология и возможности фреймворка…
Если говорить про слабые места — то их сейчас у меня 2:
— Т.к. django 1.3.4 юзаю — то проблема с подключениями постоянными
— Темплейт процессор у джанги хиленький… нужно менять :) Тесты можно легко найти в сети.
Это если не трогать базу:) (в плане сидеть на реляции)
и тот и тот код был с ОРМ (я говорю про свои кода)
а тут не чудо… тут техника… с выбором полей, юзаньем транзакция, проверками наличия данных, предподготовки данных… итд итп:)
Попробую еще раз:
1. Тот скрипт, который был написан гуру владения мышкой, написали на Ruby on Rails обновление… там было 2000 товаров, обновление шло от 40 минут, и в большенстве случаев заканчивалось неудачей, ну и сайт лежал все это время
2. Когда и сайт и скрипты обновления были переписаны на Python/Django все было лучше… количество товаров увеличивалось и достигли значения в 12 тыс… Обновление шло 10 минут… ЭТО МОЙ КОД!!! МОЙ!!! КАК ПРОГРАММИСТА:) (сорри за шифт)
3. Набравшись опыта и понимая что у нас кол-во товаров резко возрастет в ближайший месяц, переписал код, использовал уже известные приемы ОРМ (все те же 5-10 приемов, но они отличные от того что было в пункте 2) и смог при увеличенном количестве товаров выдерживать небольшое время обновления.
теперь надеюсь понятна аналогия? что я сам свой же код и сравниваю…
Сейчас, если посмотреть статистику, время генерации страницы по сайту в среднем от 0,03 сек до 1,08 — этот диапазон в основном. Бывают проскакивают записи когда выхожу за рамку в 1,5 сек по генерации страницы, над этими страницами я и работаю по оптимизации в первую очередь. Местами удается уложиться в 8мь запросов. И это не может не радовать.
Сейчас на одном из разделов тестирую работу алгоритмов отличной от ОРМ связки. Верней там ОРМ конечно присутствует, но все же алгоритм работы другой.
Работает зашибись, скорости генерации страниц высоки, но пока есть ошибки в стабильности работы… все должно как часы там работать, а иногда появляются сбои. Как решу данную проблему, буду переписывать остальные части сайта и, наверное, начну гнобить чистый ОРМ :)
По скорости — в ОРМ есть косяк в т ом, непонятно сколько времени он затратит на составление запроса.
И так же есть примеры. В моем случае интересен пример обновления списка товаров с актуальными ценами и прочими подвязками из 1С на сайт.
Я опущу как было очень рано, когда мне только достался сайт, написанный тем более на РоРе, людьми которые, возможно, только с мышкой дружили… Но из моей практики было так:
— Обновление около 12 тыс товаров (читать как всего различных записей, описывающих товары) шло 10 минут (данные брались из сформированного файла 1С, указано время работы скрипта)
— Сейчас обновление занимает 1 минуту и 20-40 сек. Однако товаров (читать как и в предыдущем пункте) около 200 тыс
Достигнуто все это «игрой» с ОРМ. И да, нет у нас 100 серваков, и оптимизировать свой собственный код мы любим:)
без думы юзать — согласен — выстрел получится предельно точным
если с умом подходить — получается вполне эффективный код… А буквально то нужно держать в голове 5-10 правил юзанья ОРМ и не лениться их пользовать.
на джанге с ОРМ работает у меня проект, который под НГ выдерживал нагрузку под 500к просмотров ежедневно. Вполне успешно, на среднем сервере. Пришел правда к этому постепенно, в течении года, но все же это реально.
Есть одна статейка интересная, с ссылкой на патч, тоже довольно интересный
Если я все правильно понял, то в 1.6 этот патч уже должен быть в боевом строю… поправьте, если не прав.
Был в Казахстане на прошлой недели… там уже была эта строка введена, думал что пропустил эту фичу в РФ… аннет, успел к ее анонсу :)
Получается тестят на казахах работоспособность:)
dd if=/dev/sda of=loader.bin bs=512 count=1брался МБР и прописывался в винде, как вариант загрузки :)Pushing the Limits of HTML5 in Gaming and Music