Некоторое время назад сработал проект выпущенный группой единомышленников с моим участием. (30к уников в день/200к страниц в день)
Приходилось сталкиваться с рядом проблем, хочется расказать о них, а также о решениях принятых в процессе разработки и поддержки.
1. В команде не было дизайнера/верстальщика, мы готовы были в целом их оплатить, но идея висела в воздухе, нужно было реализовать все крайне быстро.
В этом нам очень сильно помог twitter bootstrap framework, а также решение об использовании yii bootstrap extension. Не обладая внятными навыками в разработке интерфейсов мы смогли сделать достаточно простое приложение.
2. Ожидался минимальный функционал. Нужно было быстро разработать, а также иметь возможность развернуть на любом хостинге, сервера у нас не было.
Использование php + yii framework дало нам возможность реализовать прототип в предельно сжатые сроки. Это было действительно быстро.
3. Одна из основных фишек проекта, поиск по документам по ряду аттрибутов.
mysql + избыточность хранения данных, дали нам предельно быстрые выборки для небольших объемов данных. На текущем этапе смотрим в mongodb, теоретически это дает нам идеальный результат. Дело в том что аттрибуты для сущностей получаются в виде json, мы можем хранить готовые документы в mongodb в оригинальном виде, что заодно и решит проблему с версионностью документов.
4. Хранение файлов и место. Это одна из основных проблем, основная проблема в отстуствии прогнозируемых трат при использовании облачных хралищ данных.
Тут решения все еще нет :( Пока обходимся арендой сервера с большим дисковым пространством.
Все эти проблемы были встречены при разработке и особых проблем не вызвали. Самое веселое началось при росте посетителей.
5. Монетизация, хоть это и известно, но было неприятно понять на своей шкуре, что о монетизации нужно было заботиться заранее.
Пожертвования совсем себя не оправдали.
Баннеры кое как покрывали расходы на первый сервер. Эффективность крайне низкая.
Инвестиции от заинтересованных в развитии проекта лиц спасли его. Т.е. в общем случае мы могли вылететь в трубу.
1. База данных как всегда начала дохнуть первой.
При помощи memcached избавились от yii запросов к кэшированию схем таблиц, полностью были закешированы запросы к словарям ( они у нас практически не меняются). Это снизило нагрузку в два раза.
Далее шел вдумчиваый анализ каждой страницы, и рутинная работа по оптимизации запросов, изучения возможности их кэширования. После этого за базу данных мы были спокойны.
2. После того как разобрались с базой, имели большой load average и нагрузку на диски, думали это из за специфики сервиса, оказалось все до тривиального просто. Одно из расширений было включено в режиме дебага, а в этом режиме оно перезаписывало кучу assets'ов при каждом обращении к страницы. Это создавало дикую нагрузку на диск. Собственно запретив для него debug мы полностью решили свои проблемы.
3. У нас был мониторинг медленных запросов, он начал пухнуть, причем на операции которая по cron script обрабатывала документы, для построения ряда специфических поисковых таблиц. И эти операции лочили таблицы. Вместо того чтобы запускать его с определенной периодичностью отдавая небольшую пачку документов, мы перенесли его на время, когда пользователей на сайте практически нет, и заставили его обрабатывать все документы за день. Лог медленных запросов стал практически пустым. 4. Теперь у нас быстро генерировалась страница, но долго грузилась в браузере. Использование scriptMap + yiicomporessor решели проблему кучи js скриптов, а также их минимизации.
Использование yii extension contentCompresssor позволило ужать наш гигантский html до внятных размеров.
За счет этих простых триков, по версии google analytics мы ускорили время загрузки страницы с 5 секунд до 1й секунды.
Не знаю имеет ли смысл в этой статье без особых тех подробностей, но показал ход развития проекта и общие принятые решения. Мне было крайне интересно, а ведь будет еще интереснее :)
Меня очень порадовал тот момент, что я не оптимизировал проект заранее, я лишь имел представление о потолке наших возможностей и при приближении к нему проводил ряд оптимизаций, которые откатывали нагрузку на предыдущий уровень.
Приходилось сталкиваться с рядом проблем, хочется расказать о них, а также о решениях принятых в процессе разработки и поддержки.
1. В команде не было дизайнера/верстальщика, мы готовы были в целом их оплатить, но идея висела в воздухе, нужно было реализовать все крайне быстро.
В этом нам очень сильно помог twitter bootstrap framework, а также решение об использовании yii bootstrap extension. Не обладая внятными навыками в разработке интерфейсов мы смогли сделать достаточно простое приложение.
2. Ожидался минимальный функционал. Нужно было быстро разработать, а также иметь возможность развернуть на любом хостинге, сервера у нас не было.
Использование php + yii framework дало нам возможность реализовать прототип в предельно сжатые сроки. Это было действительно быстро.
3. Одна из основных фишек проекта, поиск по документам по ряду аттрибутов.
mysql + избыточность хранения данных, дали нам предельно быстрые выборки для небольших объемов данных. На текущем этапе смотрим в mongodb, теоретически это дает нам идеальный результат. Дело в том что аттрибуты для сущностей получаются в виде json, мы можем хранить готовые документы в mongodb в оригинальном виде, что заодно и решит проблему с версионностью документов.
4. Хранение файлов и место. Это одна из основных проблем, основная проблема в отстуствии прогнозируемых трат при использовании облачных хралищ данных.
Тут решения все еще нет :( Пока обходимся арендой сервера с большим дисковым пространством.
Все эти проблемы были встречены при разработке и особых проблем не вызвали. Самое веселое началось при росте посетителей.
5. Монетизация, хоть это и известно, но было неприятно понять на своей шкуре, что о монетизации нужно было заботиться заранее.
Пожертвования совсем себя не оправдали.
Баннеры кое как покрывали расходы на первый сервер. Эффективность крайне низкая.
Инвестиции от заинтересованных в развитии проекта лиц спасли его. Т.е. в общем случае мы могли вылететь в трубу.
1. База данных как всегда начала дохнуть первой.
При помощи memcached избавились от yii запросов к кэшированию схем таблиц, полностью были закешированы запросы к словарям ( они у нас практически не меняются). Это снизило нагрузку в два раза.
Далее шел вдумчиваый анализ каждой страницы, и рутинная работа по оптимизации запросов, изучения возможности их кэширования. После этого за базу данных мы были спокойны.
2. После того как разобрались с базой, имели большой load average и нагрузку на диски, думали это из за специфики сервиса, оказалось все до тривиального просто. Одно из расширений было включено в режиме дебага, а в этом режиме оно перезаписывало кучу assets'ов при каждом обращении к страницы. Это создавало дикую нагрузку на диск. Собственно запретив для него debug мы полностью решили свои проблемы.
3. У нас был мониторинг медленных запросов, он начал пухнуть, причем на операции которая по cron script обрабатывала документы, для построения ряда специфических поисковых таблиц. И эти операции лочили таблицы. Вместо того чтобы запускать его с определенной периодичностью отдавая небольшую пачку документов, мы перенесли его на время, когда пользователей на сайте практически нет, и заставили его обрабатывать все документы за день. Лог медленных запросов стал практически пустым. 4. Теперь у нас быстро генерировалась страница, но долго грузилась в браузере. Использование scriptMap + yiicomporessor решели проблему кучи js скриптов, а также их минимизации.
Использование yii extension contentCompresssor позволило ужать наш гигантский html до внятных размеров.
За счет этих простых триков, по версии google analytics мы ускорили время загрузки страницы с 5 секунд до 1й секунды.
Не знаю имеет ли смысл в этой статье без особых тех подробностей, но показал ход развития проекта и общие принятые решения. Мне было крайне интересно, а ведь будет еще интереснее :)
Меня очень порадовал тот момент, что я не оптимизировал проект заранее, я лишь имел представление о потолке наших возможностей и при приближении к нему проводил ряд оптимизаций, которые откатывали нагрузку на предыдущий уровень.
3 comments:
как проект-то называется?
Вроде что-то интересное, но совсем ни о чем... Можем только порадоваться за вас)
Понял, хорошо, я попробую подготовить на основе этой же статьи что нибудь такое, что можно будет пощупать.
Post a Comment