Забыл добавить кое-что важное: если размещаете весь движок или хотя бы его часть в оперативке, обязательно позаботьтесь о регулярном резервном копировании на диск — дабы потом не было мучительно больно.
Ловите фирменный рецепт для высоконагруженных проектов на LS (испробовано на личном опыте путём множества проб и ошибок.)
Во-первых, устраняем узкие места.
Начать надо не с LS и даже не с самого веб-сервера, а с общесистемных заморочек.
Иногда бывает так, что много процессорного времени уходит на дисковые операции, т.е. IOwait.
Здесь две задачи: выставить адекватный IO Sheduler (CFQ, или даже Noop), и перенести всё — слышите, всё, что можно, в RAM FS. Особые джедаи-оверклокеры переносят весь движок в оперативку (об этом расскажу позже.)
Вот уж теперь приходит очередь сервера. Толстый и неповоротливый апач, падающий от SlowLori-атаки в одиночку (банальный питоноскрипт), сносим к Дискорду.
Качаем исходники nginx'а.
./configure --help
Вдумчиво курим мануал, и определяемся, что нам надо. Потом курим опять, и вновь конфигурируем для сборки с нужными флагами (Модуль STUB не забудьте, ага), выставляем все пути соответственно FHS!
make
Витиевато выражаемся, доставляем нужные зависимости и пакеты (опять-таки, если вы джедаист-пингвиновод, этот пункт пропускаем.)
checkinstall
(аккуратно собираем в пакет). Ставим.
Всё, теперь у нас красивый, быстрый, аки Рэйнбоу Дэш, сверкающий новизной nginx. Конфигурирование его может ускорить ещё на 20%.
Затем — php. Естественно, работать будем только, и только через CGI-интерфейс. Джедаисты качают исходники, собирают@компиляют. Ленивые кунг-фу панды ставят из пакетов.
Затем приходит время настраивать ШINDOШS nginx и собственно связку php-fpm. Приблизительные цифры могу посоветовать только тогда, когда скажете параметры этого вашего сервера и среднюю нагрузку на сайт (посещаемость). Для статики ставьте expires: max и отфутболивайте вплоть до ~75% запросов статики не с 200, а с 304 ответом, ня!
Переносим временные каталоги nginx в предусмотрительно откушенный кусок оперативной памяти.
Настраиваем mysql… тот же mysqltuner.pl вам в помощь, а временные каталоги вы уже поняли, куда. Само взаимодействие тоже строго через сокет — линукс же!
Затем ставим ускоритель. eAccelerator, спросите вы? Да как бы не так. Во-первых, он древнее Селестии и Луны вместе взятых, и не развивается уже очень долго. И потом, из-за его вредной привычки не следить за целостностью shared memory, и при высокой нагрузке то и дело отправлять в 502 сайт, я и отказался от него — ну стопорит обработку php-cgi, и всё тут. Доработка напильником как spawn-fcgi, так и php-fpm помогала лишь временно — до первой же лавины запросов.
Иногда советуют ставить memcached… ИМХО, излишний велосипед. Да, у него есть няшная фича распределения по нескольким серверам, но оно вам надо? Запускать отдельный кеширующий сервер, особенно на слабых хостингах/серверах суть лишняя головная боль. Поэтому выбрасываем это звено также.
Два вышеназванные «ускорителя» успешно заменяет xCache — кеш как опкода, так и переменных (var cache). Гибкая настройка, наличие «админки», быстродействие и нетребовательность к ресурсам процессора — что ещё надо для полного счастья? Благо, LS с ним работать умеет (и по сокету тоже), посему ставим. Аппетиты настраиваем в xcache.ini, если захотели стабильности и решили включить RO-protection, то файл также ложим в RAM FS.
Ставим сфинкс, ротацию топиков-комментов вешаем на крон, сам сфинкс просто вешаем на сокет.
Если не можете позволить себе полностью переместить LS в RAM FS, сделайте это хотя бы для каталога шаблонов — и немного, и ощутимо сэкономите ресурсы.
Вот, в принципе, и всё… по просьбе могу расписать любой пункт более подробно.
Переписывать код шаблона надо… задумывался об iframe'изации LS только когда делал радио на сайте, для непрерывного воспроизведения «а-ля ВК», но реализовано было в конце другим путём.
Calling FB.login prompts the user to authenticate your application using the OAuth Dialog.
Calling FB.login results in the JS SDK attempting to open a popup window. As such, this method should only be called after a user click event, otherwise the popup window will be blocked by most browsers.
Так, а теперь насчёт неработающего Facebook.
Смотрите, сейчас вылетит птичка:
Unsafe JavaScript attempt to access frame with URL https://www.facebook.com/dialog/oauth?access_token=TOKEN&api_key=API_KEY&app_id=APP_ID&client_id=CLIENT_ID&display=popup&domain=DOMAIN&locale=en_US&origin=1&redirect_uri=REDIR_URI&response_type=token%2Csigned_request&scope=read_stream%2Cpublish_stream%2Coffline_access%2Cemail&sdk=joey from frame with URL http://DOMAIN/login/openid/. Domains, protocols and ports must match.
FB.provide.containsCssall.js:67
FB.provide._xdRecvall.js:72
FB.provide._xdNextHandlerall.js:72
aaall.js:63
q.register.init.rall.js:61
И фокус №2
I discovered that Chrome on today's machine was blocking the login pop-up when I was calling FB.login(), but I know I wasn't getting those 190 error messages in the JavaScript console yesterday.
So, when I allow pop-ups in Chrome, it does work for an end user, but all those new error messages are killing my diagnostic experience as a developer.
I've found the solution. If you execute FB.login without user action, webkit blocks the popups.
For instance, I used an invite system on my project. There was a input/text to enter invitation code. I checked the invitation code is available with an ajax/post request. if it is available, I run FB.login(). As you guess, browser blocked popup and tons of errors appeared at js console.
So you must run FB.login() after a user action. I'll put a facebook login button between ajax/post and FB.login(). Users'll have to click it -thats sucks- but they'll not see a problem.
Btw, problem occures in a few days. I think it's about trust system of browser. When you're developing it, you visit lots of times, browser thinks it's reliable at first. I'm not sure about this part but my solution works.
Два маффина сему джентельмену! Ибо воистину доставил годноту. Прошёлся бы плюсами, но рейта нет… ладно. Надо скурить-таки маны и подумать, куда ещё встроить этот микрокод.
Нет. При тестировании на реально нагруженном сайте в топике с 2000+ комментариями и активным общением с «лесенками» обнаружен-таки Ёpic Fail.
Откат на unmodified, эх…
Кажется, понял, в чём дело. Права доступа берутся из user_is_administratoruser_is_moderator из $oBlog. И именно их xCache очень агрессивно кеширует.
Ещё один выход — если позволят мощности, разбить количество слотов хранилища данных на большое, порядка 16, то есть:
Немножко пошаманил. Вынес омск из плагина в надлежащее ему место, то есть в ACL, и, соответственно, подправил хуки. Всё равно конфликт с механизмом кеширования variables в xCache. Вот же ж… ну как конфликт. Отдаются старые данные, да. gs() и var_ttl для xCache и так выставлены в 10 секунд. Сервер сказал okay.jpg, но выдержал.
P.S. И всё же чуток обидно — столько пропало возможностей для ускорения из-за этой доработки.
Нет, нет и ещё раз нет!
У меня все полгигабайта лежат в RAMFS, и без xCache (опкод и данные. Да, именно так, memcached — велоипедное излишество) приходится весьма туго, LA при пиковой ~3.5. А так 1 в среднем, ну 1.8~2.3 в пик.
фирменныйрецепт для высоконагруженных проектов на LS (испробовано на личном опыте путём множества проб и ошибок.)Во-первых, устраняем узкие места.
Начать надо не с LS и даже не с самого веб-сервера, а с общесистемных заморочек.
Иногда бывает так, что много процессорного времени уходит на дисковые операции, т.е. IOwait.
Здесь две задачи: выставить адекватный IO Sheduler (CFQ, или даже Noop), и перенести всё — слышите, всё, что можно, в RAM FS. Особые джедаи-оверклокеры переносят весь движок в оперативку (об этом расскажу позже.)
Вот уж теперь приходит очередь сервера. Толстый и неповоротливый апач, падающий от SlowLori-атаки в одиночку (банальный питоноскрипт), сносим к Дискорду.
Качаем исходники nginx'а.
Вдумчиво курим мануал, и определяемся, что нам надо. Потом курим опять, и вновь конфигурируем для сборки с нужными флагами (Модуль STUB не забудьте, ага), выставляем все пути соответственно FHS!
Витиевато выражаемся, доставляем нужные зависимости и пакеты (опять-таки, если вы джедаист-пингвиновод, этот пункт пропускаем.)
(аккуратно собираем в пакет). Ставим.
Всё, теперь у нас красивый, быстрый, аки Рэйнбоу Дэш, сверкающий новизной nginx. Конфигурирование его может ускорить ещё на 20%.
Затем — php. Естественно, работать будем только, и только через CGI-интерфейс. Джедаисты качают исходники, собирают@компиляют. Ленивые кунг-фу панды ставят из пакетов.
Затем приходит время настраивать
ШINDOШSnginx и собственно связку php-fpm. Приблизительные цифры могу посоветовать только тогда, когда скажете параметры этого вашего сервера и среднюю нагрузку на сайт (посещаемость). Для статики ставьте expires: max и отфутболивайте вплоть до ~75% запросов статики не с 200, а с 304 ответом, ня!Переносим временные каталоги nginx в предусмотрительно откушенный кусок оперативной памяти.
Настраиваем mysql… тот же mysqltuner.pl вам в помощь, а временные каталоги вы уже поняли, куда. Само взаимодействие тоже строго через сокет — линукс же!
Затем ставим ускоритель. eAccelerator, спросите вы? Да как бы не так. Во-первых, он древнее Селестии и Луны вместе взятых, и не развивается уже очень долго. И потом, из-за его вредной привычки не следить за целостностью shared memory, и при высокой нагрузке то и дело отправлять в 502 сайт, я и отказался от него — ну стопорит обработку php-cgi, и всё тут. Доработка напильником как spawn-fcgi, так и php-fpm помогала лишь временно — до первой же лавины запросов.
Иногда советуют ставить memcached… ИМХО, излишний велосипед. Да, у него есть няшная фича распределения по нескольким серверам, но оно вам надо? Запускать отдельный кеширующий сервер, особенно на слабых хостингах/серверах суть лишняя головная боль. Поэтому выбрасываем это звено также.
Два вышеназванные «ускорителя» успешно заменяет xCache — кеш как опкода, так и переменных (var cache). Гибкая настройка, наличие «админки», быстродействие и нетребовательность к ресурсам процессора — что ещё надо для полного счастья? Благо, LS с ним работать умеет (и по сокету тоже), посему ставим. Аппетиты настраиваем в xcache.ini, если захотели стабильности и решили включить RO-protection, то файл также ложим в RAM FS.
Ставим сфинкс, ротацию топиков-комментов вешаем на крон, сам сфинкс
просто вешаемна сокет.Если не можете позволить себе полностью переместить LS в RAM FS, сделайте это хотя бы для каталога шаблонов — и немного, и ощутимо сэкономите ресурсы.
Вот, в принципе, и всё… по просьбе могу расписать любой пункт более подробно.
Да пребудет с вами мудрость Селестии.
developers.facebook.com/docs/reference/javascript/FB.login/
Попробую переписать JS на бессонную голову, лолСмотрите, сейчас вылетит птичка:
И фокус №2
Нагло стыбрено отсюда
И третий, но уже вопрос: что и как править?
tabun.everypony.ru
Автор, обнови описание.
«Чистый» плагин, и всё те же баги. При любых комбинациях. ><
Откат на unmodified, эх…
Ещё один выход — если позволят мощности, разбить количество слотов хранилища данных на большое, порядка 16, то есть:
P.S. И всё же чуток обидно — столько пропало возможностей для ускорения из-за этой доработки.
У меня все полгигабайта лежат в RAMFS, и без xCache (опкод и данные. Да, именно так, memcached — велоипедное излишество) приходится весьма туго, LA при пиковой ~3.5. А так 1 в среднем, ну 1.8~2.3 в пик.
Вывод php error (полный, строк с 10, желательно с backtrace), код ActionMailing.class.php сюда.
А потом будем думать.