Ресурсы для сайта
Недавно на webdev.org.ua случился спор с одним человеком, который начал утверждать, что для того, чтобы сделать портал, надо непременно стойку серверов итд. Человеком оказался Алексей Танчик (i.ua), потому я дальше спорить не стал - ему виднее что нужно, потому что он один из тех, кто имеет в этом неплохой опыт. Однако с самой идеей я все же не согласен. Если не брать в расчет веб-мыло, рейтинг и статистику сайтов и прочее, что напрямую к классическим сайтам не относится, то вполне реально на 1-2х серверах добиться нормальной работы по 5-15млн просмотров страниц в сутки. Для этого надо пересмотреть архитектуру сайтов и делать их не так, как принято (и как делают во многих движках), а так, как будет оптимально с точки зрения производительности. C++ при этом использовать не обязательно, хватит и php.
На что тратятся ресурсы веб-сервера? На генерирование страниц. Каждый раз, когда пользователь открывает страницу, сервер получает данные из базы и подставляет их в шаблон страницы. По крайней мере, обычно происходит именно так. Но ведь данные обычно не меняются между запросами разных пользователей (меняются сравнительно редко). А значит есть смысл говорить о кэшировании. Кэширование бывает разных уровней, обычно его разбивают на 3:
- Кэширование запросов к БД. Самый низкий уровень, как правило. Вариантов много, в большинстве случаев используют самый простой: каждый запрос кэшируется на какое-то время. Перед выборкой из базы, смотрим, нет ли у нас сохраненного результата для этого запроса, если есть, то быстро возвращаем его, если нету, то делаем запрос и сохраняем результат (возвращая его-же). Данные хранить можно в shared memory или memcached или где-то еще. Я рекомендую последний - удобно и достаточно быстро. Время жизни кэша задает программист при запросе. Можно использовать более умные методы кэширования, например, если можно однозначно сказать, когда изменяются данные. Однако в большинстве случаев предсказать однозначно не получится, и будут либо устаревшие данные в кэше, либо слишком частые запросы к базе. Поэтому, как правило, на этом стоит остановиться и перейти к следующему блоку.
- Кэширование отдельных блоков в виде готового html кода. Предположим, что каждая страница, это блок. И в состав каждого блока могут входить другие блоки. Тогда подстановку блока в дизайн можно сделать функцией, которая будет перед подстановкой проверять наличие нужного блока в кэше, если он там есть, то возвращаем только его html-код. Если нет - тогда сначала генерируем его, потом заносим в кэш, потом возвращаем. Для кэширования можно использовать как memcached, так и просто хранить файлы кэша на диске. Поступая таким образом, мы экономим время на том, что даем меньше работы интерпретатору, в большинстве случаев, вообще не используем запросы к БД (и предыдущее кэширование) и можем лучше управлять кэшированием. Ведь то, как часто нам надо обновлять конкретные блоки, сказать намного проще, чем в случае обычного запроса. Скажем блок с облаком тегов не надо обновлять чаще 10ти минут, вот задаем ему такие время кэширование и теперь сервер практически не занимается его построением.
- Кэширование целых страниц. Для такого кэширования надо определиться с тем, как можно однозначно определить уникальность страницы. Чаще всего, при совпадении uri страниц id текущего пользователя в сессии, html код тоже оказывается одинаковым. От этого можно отталкиваться. Если на конкретном сайте код страницы зависит от чего-то еще, то надо это учесть. Создав папку с кэшами, например, /var/cache/site.com/, мы кладем туда закэшированые страницы, например, так: /var/cache/{$uid}/md5($uri} (на самом деле лучше не кидать много файлов в одну папку, а сделать подкаталоги, но тут это обсуждать не будем). Далее, когда приходит запрос к странице, то небольшой скрипт составляет имя файла кэша для этого запроса и проверяет, если файл есть, то отдает его, если нет – то уже подключает движок и отдает управление ему. Эту схему можно улучшить с помощью реверсивного прокси, например nginx. Прокси вызывает скрипт (который при желании можно оформить и на Си, чтобы совсем быстро), который шлет в ответ accel-redirect либо на файл с кешем, либо на бекэндовский веб-сервер. При таком способе кэширования, надо немало внимания уделить контролю за временем жизни кэша. На страницы с комментариями, например, удалять кеш при добавлении комментария. А главную страницу сайта можно раз в минуту или 10 минут обновлять, смотря что на ней находится.
Что мы таким образом получаем? 95% запросов, на достаточно посещаемом ресурсе, будут обрабатываться без участия основного генерирующего движка вообще (если модуль, отвечающих за кэширование на уровне целых страниц, написать на Си (он достаточно простой), то можно обойтись вообще без php), та часть, что выполняется уже веб-сервером, работает быстро, потому что процентов 50-80 из того, что ей надо сгенерировать, будет уже закэшировано и даже то, что незакэшировано, будет достаточно быстро сгенерировано за счет кэширования БД.
По примерным расчетам, на сервере останется примерно 1% от основной нагрузки GET запросов, по сравнению с таковой, но без кэширования. Кроме всего прочего, это очень поможет справляться с большинством DoS и DDoS атак, которые недостаточно сильные, чтобы забить канал и недостаточно "умные", чтобы бить точечно куда-то, где сервер боится перегрузок.
Конечно, многие вещи так не кэшируются. Например, поиск. Можно закэшировать одно слово, но если будет большой наплыв запросов с разными словами, то так просто уже не получится. В прочем для большинства сайтов это некритично, основная нагрузка идет далеко не на поиск.
Позже я поделюсь мыслями по поводу того, как защититься от перегрузки в случае большого числа POST запросов. Если где-то накосячил - пишите в комментах - исправлю;)
06.10.2007 в 13:11
А еще пункт 4: используем байткод-кешер (APC) вкупе с ZendOptimizer для повышения производительности самого РНР - так интерпретатору не надо будет компилировать скрипты при каждом вызове, а ZO их еще и немножко ускорит.
06.10.2007 в 14:43
хотелось бы услышать о ваших методах борьбы с ДДОС атаками раз уж о них зашла речь :)
06.10.2007 в 15:29
2DM, я не писал про байт-код кэшер, потому что не хотел привязываться к конкретному языку. Ведь то что я пишу применимо даже если сайт на Си писал (даже в этом случае будет ощутимое повышение производительности). Т.е. применять или не применять акселераторы - зависит от того, что я платформа для сайта используется.
Для PHP - конечно лучше бы использовать;)
2ursus - на нас небыло серьезных атак, однако небольшие атаки идут постоянно. От них защищает скрипт, который каждые 20-40 сек парсит логи и банит самые настырные ip. Ну и банит некоторые другие ip, запросы которых мы считаем похожими на ДДОС.
09.10.2007 в 13:04
этот скрипт называется DoS Evasive ))
09.10.2007 в 18:00
2 Dm, я орендую впс, товарищь админ поставил ngnix&eAccelerator ускорение 20-30% минимум. Правда ненамного это помогло как только посещаемость выросла на теже 20 процентов опять тупит.
10.10.2007 в 18:37
в таком случаи хватит и Nginx + SSI + memcached. а что будет класть в memcached кешированные страницы совершенно непринципиально, хотя я предпочитаю php
10.10.2007 в 18:37
точнее как страницы, так и кусочки страниц
11.10.2007 в 01:43
тю, ну и зря удалил про SSI
http://blog.kovyrin.net/2007/08/05/using-nginx-ssi-and-memcache-to-make-your-web-applications-faster/
11.10.2007 в 13:43
я ничего не удалял. Просто не заппрувил еще к тому времени.
не вижу смысла в ssi. Оно в любо случае будет медленнее чем просто отдача уже сгенеренного файла, и недостаточно функциональное, чтобы нормально снегерить страницу из готовых кусочков.
Но как альтернативу - можно.
Только вот memcached на сколько я знаю не дает гарантии сохранности данных в нем, потому при большой количестве страниц может случиться такое, что в кеше данных не будет просто. Потому юзать memcached считая что кто-то туда уже что-то положил и оно никуда не делось - чревато.
2 abs0lut3
Я стараюсь поменьше юзать разного рода скрипты из инета. Антидос мы писали сами, на перле;)
11.10.2007 в 16:08
Андрей, добрый день.
Скажите, пожалуйста, во что вы цените FileShare.
11.10.2007 в 16:30
зря не видишь, это быстрее, чем вызов какого-то там скрипта, отдающего файл.
более того НИЧТО вообще не даёт гарантии сохранности данных.
всё просто: nginx проверяет данные по ключу в мемкеше - если их нет - скрипт нагенерит их.
SSI удобен для включения кусочков в страницу, тем более что nginx отдаёт эти кусочки из мемкеша
11.10.2007 в 17:09
2 Михаил, я не продаю FileShare и в планах этого нет.
З.Ы. Я думал, что ukr.net уже начал работы над своим обменником и уже скоро его выпустит. Раз это не так, то у меня есть еще немного дополнительной форы и это радует;)
11.10.2007 в 17:14
Насчет скрипта - скрипт ничего не отдает. Он посылает заголовок, который заставляет сам сервер отдать этот файл. Его можно написать на Си или в виде демона на php и все будет не медленнее ssi. А вот как подружить ssi с той-же сессией, это уже посложнее вопрос. А без этого я не вижу вариантов.
Схема с nginx и ssi удобна для неинтерактивных не сильно структурированных страниц. Например обычных СМИ. В таком случае применение ssi может быть оправдано, как простое решение. Будет работать как простая замена последним двум уровням кеширования. Но если сессия текущая пользователя имеет значение, то врядли этот метод применим. По крайней мере так думаю я, пока мне не сказали как подружить сессии и ssi.
17.10.2007 в 21:41
Разработчики сайта fileshare.in.ua нагло “позаимствовали” свой
“новый” флеш-аплоадер у своего прямого конкурента freespace.com.ua. Причем они даже не потрудились заменить иконки на кнопках, не говоря уже об уникальных функциях, которые до сих пор остаются нерешенными в OpenSource решении, на котором якобы основан “их” флеш-аплоадер.
Не буду спорить, в нашей стране это нормальное явление, когда одни сайты используют ресурсы других, но от того факта, что лидирующий файлообмениик Украины fileshare.in.ua, созданный и поддерживаемый серьезными разработчиками, ворует функциональность своего конкурента, становится очень грустно…
Предлагаю сравнить и найти отличия:
http://www.freespace.com.ua/flashUploader.jsp
http://fileshare.in.ua/fupload.aspx
18.10.2007 в 00:57
Да ты что? А давай на сайт http://2shared.com зайдем. Ничего не напоминает?=)
Внизу флешевого аплоадера на файлшаре указана ссылка на блог с его исходником;) Я немного подрехтовал его (насколько позволило практически полное незнание флеша), перевел на русский и прикрутил. Аналогично, видимо сделал и сайт 2shared.com. А вот freespace.com.ua, взял и спер у них все.
Функциональность, кстати не воруется;) Иначе бы уже бы и КДЕ засудили и я бы завтра-послезавтра кричал что upload.com.ua стырил у меня идею аплоада по фтп (они завтра скорее всего откроют у себя такой фунционал).
18.10.2007 в 13:24
1) Сайты http://www.4shared.com, http://www.2shared.com и http://www.freespace.com.ua созданы и поддерживаются одним разработчиком, а именно компанией pmstation.com.
2) В исходнике, на который вы ссылаетесь, не реализованы следующие функции:
- сортировка в датагриде, в частности сортировка по размеру файла - это нетривиальное решение, не являющееся стандартной функцией флеша;
- удаление файлов из датагрида и полная очистка датагрида;
- возможность добавлять новые файлы в датагрид, если перед этим файлы уже были выбраны (в исходнике новый выбор файлов удаляет прежние)- см. комментарий 57 в блоге, на который вы ссылаетесь.
- проверка что файлы уже добавлены в датагрид;
- проверка на максимальный размер файла;
- общий прогрессбар;
- количество выбранных файлов и их общий размер;
- количесво залитых файлов и их размер (в процессе заливки);
- остановка аплоада;
- disable-enable кнопок;
- решение проблемы зависания аплоада и появления алерта “A script in this movie is causing Flash Player to run slowly” - см. комментарии 15, 22, 44, 52 в блоге, на который вы ссылаетесь. Эта проблема у них так и не решена.
- аплоад по 1 файлу, а не все сразу, как это делает флеш по умолчанию - см. комментарий 47 в блоге, на который вы ссылаетесь. Эта проблема у них так и не решена.
…и др.
3) Очевидно полное незнание флеша не позволило вам хотя бы ради приличия поменять цвета и значки на кнопках - эти иконки не являются компонентами флеша, и их вы уж никак не найдете в сходнике, на который вы ссылаетесь…
Если же вы честно “немного подрехтовали” исходник Vixicom Axioms, то вам несложно будет объяснить, как при “практически полном незнании флеша” вам удалось реализовать все вышеперечисленные функции и почему иконки и цвета вашего флеш-аплоадера идентичны аплоадерам на сайтах компании pmstation.com.
Если же вы все еще утверждаете, что вы не украли аплоадер с одного из наших сайтов, то это не делает чести ни вам как разработчику, ни вашему популярному сервису.
Всего хорошего.
18.10.2007 в 13:48
Я изменил описание на странице аплоада. Я действительно подсмотрел много функций на 2shared.com. А насчет дизайна - я поищу флешера, который сможет мне сменить дизайн на тот, что больше относится к файлшаре. Использовать чужой действительно как-то неправильно, как минимум потому что это плохо интегрируется в сайт.
18.10.2007 в 16:18
гиги…. ждем продолжения истории:
hint: а ведь в природе есть еще и джава-аплоадеры. вопрос: кто первый воткнет его себе на сайт?
18.10.2007 в 16:22
я реверснул ваш аплоадер и отослал сорцы автору опен-сорц версии, чтобы он наконец-то пофиксил свои баги, и новый, БЕЗБАЖНЫЙ аплоадер стал достоянием ВСЕГО ЧЕЛОВЕЧЕСТВА!
18.10.2007 в 16:24
Джава-аплоадер использует джава-машину, она установлена мало у кого, потому в таком аплоадере не сильно много смысла. Флеш сейчас у намного большего количества людей.
18.10.2007 в 16:26
опа…. вот автор уже и пофиксил одну багу!
Hey guys I was able to fix the “A script in this movie is causing Flash Player to run slowly” problem by using an onEnterFrame event and have posted the updated source code on my blog at http://rockstardeveloper.com/articles/2007/04/22/flash-script-running-too-slowly
18.10.2007 в 16:35
2#19 - это было бы отлично. Если нужно - я без проблем поставлю кнопку с ссылкой на авторов и ссылки где нужно.
Я не собираюсь присваивать какие-то права на аплоадер, без проблем расскажу всем пользователям, кто автор. Моя цель - сделать как можно лучше сервис, не больше.
Я, как разберусь с саппортом, тоже выложу некоторые из своих инструментов для общего использования. Кое что, что можно оказаться полезным, в условиях украинских реалий.
18.10.2007 в 16:41
в отличии от http://www.freespace.com.ua, автор fileshare.in.ua повел себя более корректно по отношению к автору опер-сорц версии: прямо под аплоадером сцылка на его блог!
18.10.2007 в 16:59
Ну на сайт freespace и так есть ссылки с этой страницы, да и у меня не такой блог, чтобы поднимать кому-то пиар. А если и поднимет - пусть будет;)
18.10.2007 в 17:21
Ну зачем вы пишете, что подсмотрели функции на 2shared? Вы декомипллировали swf-файл, перевели на русский, подставили свой url для аплоада, и вот вам дорогие пользователи чудесный аплоадер!
И дело даже не в дизайне… Дизайна там на самом деле и нет никакого, кроме иконок на кнопках, которые сразу вас выдали. Все дело в вашем неуважении к тем усилиям и времени, что были потрачены на разработку и отладку всех этих функций, и нечестной конкуренции.
Удачи!
18.10.2007 в 20:15
Ну вы же лучше меня знаете как я делал - считайте так как вам будет удобно;). В той-же Украине с файлшары достаточно много людей или кусок дизайна брали или тексты или что-то еще. Мне всегда плевать на это было - лишь бы на пользу пошло. Если у вас другое отношение к этому - патентуйте исходники (если конечно кто-то даст патентовать оперсорсный подпиляный скрипт под себя) или шифруйте или что-то еще с этим делайте на ваше усмотрение, может быть лучше будете спать.
Механизм аплоада у меня немного отличается от того что у вас (я видел исходиники вашей флешки, я могу об этом судить), так что если вы думаете что достаточно подставить урл, то думайте. Я много чего у вас скопипастил, но механизм аплоада пришлось немного поменять (можете декомпильнуть и посмотреть diff), хотя это неважно в общем-т о.
Я вот только не понимаю. чего вы хотите добиться этой дискуссией? Типа пристыдить меня чтобы я убрал аплоадер? этого не будет, на это есть ряд объективных причин (одна из них то, что это подпиляный оперсорсный скрипт). Есдинственной моей ошибкой было то, что я не дал ссылку на авторов изменений. Я вроде это уже исправил.
А там, считайте уважением или неуважение что вам будет угодно.
29.10.2007 в 20:33
ХеХе! Как владелец большого ресурса, тебе пора бы уже научится забивать на такие комменты )) Таких людей везде хватает, многие любят считать чужое бабло и раскрывать “великие заговоры” тех, кто это бабло зарабатывает )))
29.10.2007 в 23:18
Ну я считаю что жалоба была обоснованной и потому решил ответить.
Ясно что на сопливые отзывы о том какая я продажная тварь и как я через месяц закроюсь, я бы не стал отвечать;)
А так мне хорошо, софт у меня практически весь свой, хотя бы по поводу крякнутого IPB итд вони не будет (пару раз встречал такое. Самое смешное что в тех случаях все было купленным;) разве что в банерку будут стучать идиоты разные;)
19.12.2007 в 11:36
Господа, а не проще найти флешера, который с нуля напишет аплоадер? Или 3 сотни баксов жалко? Уверяю, это сделает любой вменяемый программер, причем гораздо лучше, нежели поделки под гордым именем OpenSource.
Кстати, на флеше еще и давнлоадер написать можно…
07.01.2008 в 15:07
Ну сейчас можно поюзать и опенсорс, позже (где-то чере месяц) наймем человека, чтобы переписал немного аплоадер, заточил под наш диз итд. В прочем даже тогда это будет опенсорс (как минимум из-за лицензии). В прочем сделано это будет не потому что этот плохой. Этот тоже хороший. Туда просто добавится пару фиш.
Насчет даунлоадера - можно подумать. Когда-то видел удобный на gamefiles.com (вроде), в принципе можно и нам сделать, чтобы меньше было проблем с непонятными менеджерами закачек, которые не умеют нормально обрабатывать ошибки итд.