«LiveStreet и 200 000 топиков» или «Попытка взять споличным»
Сразу оговорюсь — я не «мастер пера», а если прибавить к этому еще и что это мой первый пост — получается не очень классная картина, но тем не менее, я надеюсь что все пройдет как и было задумано :)
Итак, поехали...
Конец 2006 года — первый раз когда я случайно зашел на сайт Хабры и, если не ошибаюсь, где-то начало 2008 когда первый раз я лицезрел проект, правда BigStreet, и где-то еще в течении месяца наткнулся на LiveStreet… уже не помню конкретно какие мысли посетили тогда меня в этот момент, но именно ЛайфСтрит попал в закладки и стал одним из посещаемых мною сайтов в контексте «от случая, к случаю...»
Проект развивался.
Последний апдейт дизайна — был «финальной каплей» когда я решился «пощупать» его на все 100%.
В свою очередь, отношусь к тому числу людей, которым если нравится какая-то идея, то сначало находится примерный аналог скрипта и с «жестким напильником», просто таки, «вытачивается» юзабельная версия. Если идея прет, посетители идут — значит все ок и уже тогда, вооружившись недельным запасом съестного — начинается полная переработка, что называется — «с «0»».
Так было уже ни с одним моим проектом.
Рассчитывать на миллиардную посещаемость — тут глупо. У первопроходца всегда «+1000 в карму» :)
Но, если брать узкий профиль специализации, то может выгореть и что-то интересное.
Исходя из такой тактики (именно технической стороны) здесь больше всего интересует один вопрос:
А сможет ли данная система выдержать необходимую нагрузку, которая может внезапно нахлынуть если «проект попрет»?
Недели на переработку может не хватить и «долгожданные посетители» могут быть упущены… тогда и смысла создавать что-то уже отпадает — вернуть сокровенных очень сложно (чисто ИМХО), хотя и не невозможно — просто на начальном этапе хочется избежать перегрузок сервера и времени генерации страницы в 10-15 секунд.
Итак, исключительно для меня и в рамках «данного» проекта ключевым показателем стабильности может являться исключительно стабильность работы «Движка LiveStreet» (можно с большой буквы? ;)) при большом количестве постов.
Возьмем термин «большое количество постов» как «условную переменную», которую я для себя выставил на планке в 200000 топиков.
Мне кажется что если проект за год «для начала» сможет набрать хотябы половину или треть — он более чем достоин внимания и вопрос переработки не встанет ребром (вопрос раскрутки и рекламы я не беру — здесь у меня есть партнер который этим и только этим и занимается).
Один из наших проектов — мы собираем новости по всевозможным источникам, фильтруем, сортируем, отбираем и предоставляем заинтересованным компаниям единой лентой с интервалом обновления в 5 минут — выходит примерно ± 2000 интересных новостей в сутки (всего).
Соответственно, сохраняются и архивы, которые, в свою очередь я и хочу использовать для тестирования.
Итак, 200000 (ну почти… см. картинку)… приступаем к конвертации.
Изучив строение базы — первое что бросилось в глаза это строение таблицы:
`prefix_topic_content` {
topic_id — ID — тут все понятно
topic_text — текст, ну куда же без него
topic_text_short — «анонс»… тоже дело
topic_text_source — сорцы… хммм…
topic_extra — вспомогательное поле… тут тоже, я думаю, все понятно
}
Итак, база в 200к новостей занмиает примерно 2,9 Гб (одна табличка),
`prefix_topic` — 55Мб.
Вопрос уперся именно в `topic_text_source`… если это поле «обнулить» табличка теряет в весе почти в 2 раза!
Сразу вопрос, а может быть вывести данное поле в отдельную таблицу? Тем самым «разгрузив» основную?
Насколько я понимаю, в выдаче фронтенда оно не играет никакого значения?
Железка для тестирования:
средняя загрузка системы порядка 30-40%,
в мемкешед загружено уже порядка 1,5Гб данных
в хтаксесс добавлено:
Итак, увидеть что получилось можно здесь:
livestreet [ТОЧКА] fxm [ТОЧКА] ru
(убираем пробелы и меняем [ТОЧКА] на… точку :))
Еще один вопрос — каким образом информация из разделов попадает на главную страницу?
Т.е. на совсем главную?
«Сюда еще никто не успел написать_$$»
Там безумное кол-во новостей но так и не удалось ни одной запихнуть на главную :)
PS. фишка с "_$$" — это «полет души» программера? :)
Взглянем на статистику в футере:
./new/
* MySql
запросов: 1
время: 0,035
* Cache
запросов: 21
set: 0
get: 20
время: 0,00167
* PHP
загрузка модулей:0,022
общее время:0,427
./new/page2/
* MySql
запросов: 1
время: 0,008
* Cache
запросов: 21
set: 0
get: 20
время: 0,00094
* PHP
загрузка модулей:0,022
общее время:0,478
./new/page40/
* MySql
запросов: 3
время: 0,01
* Cache
запросов: 22
set: 1
get: 20
время: 0,04269
* PHP
загрузка модулей:0,023
общее время:0,265
В процессе тестирования выявлена очень интересная деталь — не более 40 страниц в разделе
«Все -> Новые».
Погнали дальше…
Самым загруженным разделом является конечно же «Сток...». Сюда падает весь «варез» — все то что дает максимальный трафик :)
./blog/stock/
* MySql
запросов: 9
время: 0,696
* Cache
запросов: 30
set: 3
get: 26
время: 0,04199
* PHP
загрузка модулей:0,025
общее время:1,136
после «рефреша» страницы:
* MySql
запросов: 5
время: 0,013
* Cache
запросов: 27
set: 0
get: 26
время: 0,002
* PHP
загрузка модулей:0,025
общее время:0,497
возврат через 5 минут:
* MySql
запросов: 5
время: 0,011
* Cache
запросов: 27
set: 0
get: 26
время: 0,00216
* PHP
загрузка модулей:0,025
общее время:0,414
самя «глубокая» страница здесь —
./blog/stock/page1803/
первый заход:
* MySql
запросов: 12
время: 0,707
* Cache
запросов: 32
set: 5
get: 26
время: 0,04306
* PHP
загрузка модулей:0,025
общее время:0,979
рефреш:
* MySql
запросов: 5
время: 0,006
* Cache
запросов: 27
set: 0
get: 26
время: 0,00111
* PHP
загрузка модулей:0,025
общее время:0,231
открываем перую попавшуюся под руку новость:
* MySql
запросов: 7
время: 0,013
* Cache
запросов: 28
set: 5
get: 22
время: 0,04315
* PHP
загрузка модулей:0,025
общее время:0,185
рефреш:
* MySql
запросов: 5
время: 0,01
* Cache
запросов: 23
set: 0
get: 22
время: 0,00188
* PHP
загрузка модулей:0,026
общее время:0,239
Итого...
Двиг даже на большом кол-ве топиков ведет себя весьма и весьма неплохо.
О какой-то стабильности говорить — невозьмусь… это покажет время.
Однако, напильник в руки брать — желания нет. Все продумано, лаконично и… весьма быстро.
Так, немного мелкой наждачки, краски и немного лака чтобы «блестело» ;)
Едиственное что удручает — еАкселератор постоянно перекомпилитит весь проект — весьма странно.
С другими проектами таких проблем нет. Реализованные на фреймворке KohanaPHP — работают весьма быстро и стабильно.
Хотя, могу и ошибаться. Надо покрутить.
PS. Если разработчикам интересны «какие-то моменты» — смело можно стучать в личку или аську, или мыл.
Итак, поехали...
Конец 2006 года — первый раз когда я случайно зашел на сайт Хабры и, если не ошибаюсь, где-то начало 2008 когда первый раз я лицезрел проект, правда BigStreet, и где-то еще в течении месяца наткнулся на LiveStreet… уже не помню конкретно какие мысли посетили тогда меня в этот момент, но именно ЛайфСтрит попал в закладки и стал одним из посещаемых мною сайтов в контексте «от случая, к случаю...»
Проект развивался.
Последний апдейт дизайна — был «финальной каплей» когда я решился «пощупать» его на все 100%.
В свою очередь, отношусь к тому числу людей, которым если нравится какая-то идея, то сначало находится примерный аналог скрипта и с «жестким напильником», просто таки, «вытачивается» юзабельная версия. Если идея прет, посетители идут — значит все ок и уже тогда, вооружившись недельным запасом съестного — начинается полная переработка, что называется — «с «0»».
Так было уже ни с одним моим проектом.
Рассчитывать на миллиардную посещаемость — тут глупо. У первопроходца всегда «+1000 в карму» :)
Но, если брать узкий профиль специализации, то может выгореть и что-то интересное.
Исходя из такой тактики (именно технической стороны) здесь больше всего интересует один вопрос:
А сможет ли данная система выдержать необходимую нагрузку, которая может внезапно нахлынуть если «проект попрет»?
Недели на переработку может не хватить и «долгожданные посетители» могут быть упущены… тогда и смысла создавать что-то уже отпадает — вернуть сокровенных очень сложно (чисто ИМХО), хотя и не невозможно — просто на начальном этапе хочется избежать перегрузок сервера и времени генерации страницы в 10-15 секунд.
Итак, исключительно для меня и в рамках «данного» проекта ключевым показателем стабильности может являться исключительно стабильность работы «Движка LiveStreet» (можно с большой буквы? ;)) при большом количестве постов.
Возьмем термин «большое количество постов» как «условную переменную», которую я для себя выставил на планке в 200000 топиков.
Мне кажется что если проект за год «для начала» сможет набрать хотябы половину или треть — он более чем достоин внимания и вопрос переработки не встанет ребром (вопрос раскрутки и рекламы я не беру — здесь у меня есть партнер который этим и только этим и занимается).
Один из наших проектов — мы собираем новости по всевозможным источникам, фильтруем, сортируем, отбираем и предоставляем заинтересованным компаниям единой лентой с интервалом обновления в 5 минут — выходит примерно ± 2000 интересных новостей в сутки (всего).
Соответственно, сохраняются и архивы, которые, в свою очередь я и хочу использовать для тестирования.
Итак, 200000 (ну почти… см. картинку)… приступаем к конвертации.
Изучив строение базы — первое что бросилось в глаза это строение таблицы:
`prefix_topic_content` {
topic_id — ID — тут все понятно
topic_text — текст, ну куда же без него
topic_text_short — «анонс»… тоже дело
topic_text_source — сорцы… хммм…
topic_extra — вспомогательное поле… тут тоже, я думаю, все понятно
}
Итак, база в 200к новостей занмиает примерно 2,9 Гб (одна табличка),
`prefix_topic` — 55Мб.
Вопрос уперся именно в `topic_text_source`… если это поле «обнулить» табличка теряет в весе почти в 2 раза!
Сразу вопрос, а может быть вывести данное поле в отдельную таблицу? Тем самым «разгрузив» основную?
Насколько я понимаю, в выдаче фронтенда оно не играет никакого значения?
Железка для тестирования:
Core2Quad Q6600 (4x2.4 GHz)
4096MB RAM
2x500 GB (S-ATAII) HDD
Debian 4.0
php5, mysql 5.0.32, Апача 2.2
+ memcached
+ eAcceleratorсредняя загрузка системы порядка 30-40%,
в мемкешед загружено уже порядка 1,5Гб данных
в хтаксесс добавлено:
XBitHack on
ExpiresActive On
ExpiresDefault "access plus 30 minutes"
ExpiresByType text/html "access plus 3 minutes"
ExpiresByType text/css M315360000
ExpiresByType image/png M315360000
ExpiresByType image/gif M315360000
ExpiresByType image/jpeg M315360000
ExpiresByType image/icon M315360000
ExpiresByType application/x-javascript M315360000
Итак, увидеть что получилось можно здесь:
livestreet [ТОЧКА] fxm [ТОЧКА] ru
(убираем пробелы и меняем [ТОЧКА] на… точку :))
Еще один вопрос — каким образом информация из разделов попадает на главную страницу?
Т.е. на совсем главную?
«Сюда еще никто не успел написать_$$»
Там безумное кол-во новостей но так и не удалось ни одной запихнуть на главную :)
PS. фишка с "_$$" — это «полет души» программера? :)
Взглянем на статистику в футере:
./new/
* MySql
запросов: 1
время: 0,035
* Cache
запросов: 21
set: 0
get: 20
время: 0,00167
* PHP
загрузка модулей:0,022
общее время:0,427
./new/page2/
* MySql
запросов: 1
время: 0,008
* Cache
запросов: 21
set: 0
get: 20
время: 0,00094
* PHP
загрузка модулей:0,022
общее время:0,478
./new/page40/
* MySql
запросов: 3
время: 0,01
* Cache
запросов: 22
set: 1
get: 20
время: 0,04269
* PHP
загрузка модулей:0,023
общее время:0,265
В процессе тестирования выявлена очень интересная деталь — не более 40 страниц в разделе
«Все -> Новые».
Погнали дальше…
Самым загруженным разделом является конечно же «Сток...». Сюда падает весь «варез» — все то что дает максимальный трафик :)
./blog/stock/
* MySql
запросов: 9
время: 0,696
* Cache
запросов: 30
set: 3
get: 26
время: 0,04199
* PHP
загрузка модулей:0,025
общее время:1,136
после «рефреша» страницы:
* MySql
запросов: 5
время: 0,013
* Cache
запросов: 27
set: 0
get: 26
время: 0,002
* PHP
загрузка модулей:0,025
общее время:0,497
возврат через 5 минут:
* MySql
запросов: 5
время: 0,011
* Cache
запросов: 27
set: 0
get: 26
время: 0,00216
* PHP
загрузка модулей:0,025
общее время:0,414
самя «глубокая» страница здесь —
./blog/stock/page1803/
первый заход:
* MySql
запросов: 12
время: 0,707
* Cache
запросов: 32
set: 5
get: 26
время: 0,04306
* PHP
загрузка модулей:0,025
общее время:0,979
рефреш:
* MySql
запросов: 5
время: 0,006
* Cache
запросов: 27
set: 0
get: 26
время: 0,00111
* PHP
загрузка модулей:0,025
общее время:0,231
открываем перую попавшуюся под руку новость:
* MySql
запросов: 7
время: 0,013
* Cache
запросов: 28
set: 5
get: 22
время: 0,04315
* PHP
загрузка модулей:0,025
общее время:0,185
рефреш:
* MySql
запросов: 5
время: 0,01
* Cache
запросов: 23
set: 0
get: 22
время: 0,00188
* PHP
загрузка модулей:0,026
общее время:0,239
Итого...
Двиг даже на большом кол-ве топиков ведет себя весьма и весьма неплохо.
О какой-то стабильности говорить — невозьмусь… это покажет время.
Однако, напильник в руки брать — желания нет. Все продумано, лаконично и… весьма быстро.
Так, немного мелкой наждачки, краски и немного лака чтобы «блестело» ;)
Едиственное что удручает — еАкселератор постоянно перекомпилитит весь проект — весьма странно.
С другими проектами таких проблем нет. Реализованные на фреймворке KohanaPHP — работают весьма быстро и стабильно.
Хотя, могу и ошибаться. Надо покрутить.
PS. Если разработчикам интересны «какие-то моменты» — смело можно стучать в личку или аську, или мыл.
21 комментарий
много топиков это хорошо, но ничего не сказано про онлайн. 30-40% — это при одном конкурентном запросе?
поле text_source можно не заполнять при импорте топиков, если не требуется их редактировать. text_source введен для того, чтоб пользователь не ловил магию, когда написал одно, а при редактировании вылезло совсем другое. Т.е. некая забота о пользователе, но если нужно то от его использования можно легко отказаться.
Вообще сейчас на проекте turometr.ru пробуем немного другую логику по работе с БД, там решено отказаться от использования SQL запросов с множественными JOIN'ами и сделать их отдельными с возможностью кеширования. По теории при наличии достаточного объема памяти для memcache такая архитектура должна работать в разы быстрее при горячем кеше.
нет-нет… это средняя общая загрузка при дневном юзании…
«Вообще сейчас на проекте turometr.ru пробуем немного другую логику по работе с БД, там решено отказаться от использования SQL запросов с множественными JOIN'ами и сделать их отдельными с возможностью кеширования. По теории при наличии достаточного объема памяти для memcache такая архитектура должна работать в разы быстрее при горячем кеше.»
В ЯБЛОЧКО!
Мемкешед — идеален для этого!
В режиме поддержки соединения скорость получается весьма и весьма приличная!
Мы при хранении и выдачи новостей используем именно такую тактику.
Джоином объединяются исключительно некоторые запросы, которые ведут к единому неделимому результату или группируются по определенным характеристикам не нуждающимся в частых апдейтах.
но это все срезается на уровне nginx+memcached т.к. текст + картинки — «не изменяемые», т.е. чисто выдача
сейчас при запросе страницы не авторизованным юзером все СКЛ запросы кешируются на 15 минут, т.е. получаем что отрабатывает только инициализация ядра системы с выбросом результата из кеша.
Эх… =)
не понял тебя %)
я говорил про общую нагрузку на сервер другими проектами
а двиг лайвстрита взят с SVN с теми настройками кеширования которые заложены «по умолчанию»
сделаю бенчмарк на недельке — посмотрим…
а если поставить на фронтенд nginx для статики?
так так и стоит…
запрос -> nginx (проверяем есть ли эта страница готовая в кеше мемкеша и если нет то передаем запрос дальше) -> апач, пхп, мускуль
единственное что часто обновляется — разделы
PS. мы работаем на выдаче новостей по XML, RSS потокам — это основная нагрузка
Как быть с пользовательской информацией? например, блок пользователя вверху сайта, со ссылками на его профиль, личные сообщения и тп. Его-то не получится кешировать вместе со страницей — иначе он будет выдаваться из кеша всем другим пользователям?
Или кеширование сделано только для неавторизированных пользователей?
Ort, в Opera 10 alpha (Build 1345) комментарии не добавляются.
?