Един свеж съвет за уеб разработчиците

Labels: , ,

Здравейте колеги и приятели,

Може би някои от вас, вчера са забелязали проблеми с достъпа до svejo.net - както кратка липса, така и малко по-бавно действие. Причината, не е тайна - технически проблеми. Човешко е да се случват :). В духа на свежо и споделянето, решихме че може да е полезно за всички, които се занимават с уеб технологии - да разкажа какви проблеми имахме и как се справихме с тях.

Принципно зад сайта стои една доста сериозна и силна машина - 2 четириядрени процесора и 6G RAM (до скоро имаше само 2G RAM). Въпреки това при около 450 едновременни посещения машината се запъхтяваше много сериозно. По подразбиране платформата, която ползваме - Ruby on Rails, е по-бавна (процесорно и иска повече памет), за сметка на леснота при разработката и пускането на промени. И все пак, при този хардуер, ако всичко е направено добре, би трябвало да могат да се посрещнат много по-големи натоварвания. След работа по оптимизации и профилиране на сайта установихме, къде в същност е проблема - следенето на потребителските сесии. На първи преглед, бяхме изпуснали, че Tyxo показва 450 потребителя онлайн, но реално апликейшъна (извинявам се за чуждицата), поддържа много повече активни сесии. Не другаде, но за всеки свеж бутон на отделечен сайт, за всеки отделен потребител се вдига сесия. Примерно, ако има бутончета на 1000 сайта, а всеки от тях има средно по 10-20 посещения от различни хора, това прави около 15000 сессии, което никак не е малко...

Съответно, като технологично решение до тази нощ ползвахме сесии в базата данни - "ActiveRecord session store", доста стандартно решение за Ruby on Rails. В таблицата имахме около 350 000 записа, като сесиите се различават по 32 символен низ (стариите сесии/записи се трият). Тази реализация последните дни започна доста сериозно да товари MySQL, а от там и целия сървър, който достигаше "1-2 unix load".

Тези от вас, които са прочели нещата до тук или вече знаят или се сещат какво се оказа решението на проблема ни. Изнесохме сесиите от DB сървъра към Cache-а (memcached). Това имаше очаквано за мен добри резултати :) . В момента при ~600 онлайн потребителя според Tyxo, натовареността на съръра ни е около 0.6 . Смея да твърдя, че с текущата архитектура, сървърът ще може да обсужва поне 1000 едновременни посещения, както и всички блогове и сайтове, който имат свеж бутон. Спокойно може да кажете на приятелите си да прегледат свежия фронт, свежия сървър ще ги приеме с отворени врати ;)

Моят съвет към вас - колегите, които се сблъсквате с подобни проблеми - преди да правите какви ли не оптимизации по самия код на уеб приложението, замислете се за кешване да определени блокове код, както и изнасяне на сесиите в кешта.

Надявам се споделянето на проблема ни, да е бил полезен на някой от вас. Не се колебайте да помолите и за съвет, ако имаме възможност ще помогнем. Аз от своя страна искам да припомня, че инсталирането на свеж бутон, е полезно както за нас така и за Вас. Това ще е за сега.

Поздрави и пожелания за хубав ден,

Станислав

3 comments:
gravatar
Никола Павлов каза...
вторник, август 12, 2008  

Memcached е изключително мощен инструмент. Въобще откакто се зарибих с него, доста ми се промени начина, по който си структурирам нещата. Вече си е неизменна част от уеб приложенията, с които се занимавам, не просто кеширащ механизъм като всички останали.

gravatar
Анонимен каза...
вторник, август 12, 2008  

Ами в ASP.NET по подразбиране сесиите се слагат в паметта. Единствено ако се нуждаем от web farm или записване на сесията при restart на приложението има вариант за storage в session state server или MS SQL Server база. Интерено ми е как по подразбиране сесиите ruby on rails решава да ги сложи в базата.

gravatar
Анонимен каза...
четвъртък, юни 11, 2009  

Абе вия майтап ли си правите за 20 000 посещения дневно да слагате Memcached и то при тоя мощен сървър.

Публикуване на коментар