Быстродействие и нагрузка на сервер переводов Drupal

Если поискать, то если не ошибаюсь тут где-то был рабочий пример перевода без использования базы. Но несколько обсуждений, причем больших, точно есть.

Murz пишет: "есть ли у кого в планах организовать локализованные данным способом версии Drupal? А если нет, то хотелось бы услышать почему."

У меня лично таких планов нет. И вот почему.

Время, которое потребуется на такую "оптимизацию" плюс риск глюков плюс необходимость делать такую "оптимизацию" при каждой смене версий Друпала - все это стоит намного дороже, чем дополнительные 5$ в месяц за нормальный хостинг.

Хорошие хостинги хорошо делают свое дело, проще платить им сколько они просят, чем пытаться своим временем нейтрализовать кривую работу дешевого хостинга.

Google дает много результатов по запросу:

перевод без использования базы site:drupal.ru

Да, точно! По такой фразе нашёл несколько веток обсуждения. А я формулировал запрос по-другому "перевод интерфейса drupal", "исходники с русским интерфейсом" и т.д.
Спасибо за ссылку!

там нельзя русские текста везде понапихать - траблы с Юникодом возникают - сами файлы то Друпала в виндовой кодировке.... Мне лень портировать на 5-ю версию свой способ оптимизации - будет время - сделаю.

Я уже несколько файлов русифицировал - просто написал по-русски фразы и сохранил как uft-8 - нормально всё сработало, ничего даже не сломалось ;) Единственное что - с сортировками и сравнениями без учета регистра, я думаю, проблемы вылезут при таком подходе, но вроде такие действия для выводимых текстов и не используются...

Razgonka.ru пишет: Время, которое потребуется на такую "оптимизацию" плюс риск глюков плюс необходимость делать такую "оптимизацию" при каждой смене версий Друпала - все это стоит намного дороже, чем дополнительные 5$ в месяц за нормальный хостинг.
Время конешно и переделки при переходе на новые версии - это довольно значительный фактор, но всё же разница в быстродействии, я думаю, будет не в 2 и не в 3 раза больше, а в десятки раз.
Цитирую строки автора темы по переводу Drupal без базы:
Мда, отследил я , сколько запросов идет от Друпал к базе с переводом( да и основным текстом) и ужаснулся.На главной например у меня подсчитывает 560 запросов, и это еще только пока, так как никакого функционала ещё нет. Как же это серверы то терпят? А если 2000 пользователей?
У меня тоже при включении перевода с 50-100 запросов к базе при загрузке страницы увеличивается до полутысячи и выше!

З.Ы.: Ещё тоже неплохой спамерщик запросов - модуль Path, генерящий каждый раз штук по 10-20 запросов типа "SELECT dst FROM url_alias WHERE src = 'node/24'", причем даже когда его выключаешь в админке.

Я конешно понимаю что сейчас компьютеры быстрые и хостинг недорогой, но всё же как-то страшно видеть несколько сотен запросов для вывода одной текстовой страницы с простым текстом одной ноды из пары абзацев :( А уж если проект сильно посещаемый (тысяч 5-10 в день), то тут по-моему без выделенного сервера обычным хостингом за 5-20 баксов никак не обойдёшься ;(

Остальные CMS конешно тоже не сахар, но всё же я перешёл на Drupal в надежде что он более лоялен к нагрузке на сервер, особенно для небольших проектов (например штук 10 текстовых страниц, пара лент новостей с комментариями, простейший форум средствами drupal и форма обратной связи), но сейчас что-то мне так уже не кажется. Многие конешно скажут что такие сайты лучше писать самому ручками, но я наверное уже стал слишком ленив чтобы каждому клиенту для сайта руками прикручивать wysiwyg-редактор, админку и другие стандартные вещи, а использовать для каждого типа сайта свою CMS - тоже не дело, голова опухнет привыкать сразу к куче CMS-ок разных, лучше уж подобрать одну универсальную....

Или вот я ещё чего подумал - может сделать или может есть уже какая-нить Light-версия Drupal, в которой отключены логи, расширенные права доступа и другой фунционал, не особо нужный рядовому сайту аля визтка?

Murz says: А уж если проект сильно посещаемый (тысяч 5-10 в день), то тут по-моему без выделенного сервера обычным хостингом за 5-20 баксов никак не обойдёшься ;(

Если сидеть у русских хостеров, то здесь Вы правы. Тот же MasterHost.ru ри малейшей загрузке базы начинает подталкивать клиента на виртуальный сервер. И в базе MySQL для экономии места у него вся информация из UTF-8 на лету переконвертируется в в Win-1251, а при запросе восстанавливается обратно. Формально получается, что клиент у MasterHost.ru получает базу в кодировке UTF-8, но в некоторых тонких местах хранение данных в Windows-1251 вылезает наружу.

В импортной части Интернет есть хорошие хостинги, умеющие размещать с сайтами на Друпале. Например, http://www.cifnet.com/ На тарифном плане 15$ в месяц он держит указанную Вами посещаемость. Поддержка понимает не только по-английски, но и по-русски. Наш сайт Razgonka.ru сидит у них несколько лет вкупе с другими сайтами на Друпале, все прекрасно.

Если есть один хостинг, умеющий работать с Друпалом, наверняка есть и другие хостинги.

Murz says: я перешёл на Drupal в надежде что он более лоялен к нагрузке на сервер, особенно для небольших проектов (например штук 10 текстовых страниц, пара лент новостей с комментариями, простейший форум средствами drupal и форма обратной связи), но сейчас что-то мне так уже не кажется.

На том же CifNet.com сайт Razgonka.ru располагается не как основной сайт, а как припаркованный. Кроме Razgonka.ru в таком же паркованном состоянии на одном тарифном плане находятся еще под десяток сайтов на Друпале. Все вместе они генерят указанную Вами посещаемость. У каждого сайта отдельный FTP-вход, можно заводить много баз MySQL, у припаркованных сайтов практически те же самые возможности, что и у основного сайта. За все сайты идет общая оплата - 15$ в месяц.

Вы тратите свою энергию на увеличение быстродействия Drupal. И Вам придется тратить ее каждый раз при смене версий Друпала. Но проблему проще решить поиском подходящего хостинга.

Murz says: а использовать для каждого типа сайта свою CMS - тоже не дело, голова опухнет привыкать сразу к куче CMS-ок разных, лучше уж подобрать одну универсальную....

У Вас правильный поход. Широкие специалисты сейчас не нужны. Нужно специализироваться на одной CMS. Тем более, что Друпал достаточно универсальна как система управления сайтом. Ее можно использовать и для создания небольших сайтов для себя и для разработки сайтов серьезным клиентам.

Подпишитесь на форум "Заказы на разработку и поиск работы" Возьмите подходящий заказ на установку сайта на Друпале. У Вас появятся деньги, на них переедете на нормальный хостинг. И сможете тратить свое время не на адапатцию Друпала к русским хостингам, а на дальнейшее изучение его возможностей.

Murz says: А уж если проект сильно посещаемый (тысяч 5-10 в день), то тут по-моему без выделенного сервера обычным хостингом за 5-20 баксов никак не обойдёшься ;(

Если сидеть у русских хостеров, то здесь Вы правы. Тот же MasterHost.ru при малейшей загрузке базы начинает подталкивать клиента на виртуальный сервер. И в базе MySQL для экономии места у него вся информация из UTF-8 на лету переконвертируется в в Win-1251, а при запросе восстанавливается обратно. Формально получается, что клиент у MasterHost.ru получает базу в кодировке UTF-8, но в некоторых тонких местах хранение данных в Windows-1251 вылезает наружу.

В импортной части Интернет есть хорошие хостинги, умеющие размещать с сайтами на Друпале. Например, http://www.cifnet.com/ На тарифном плане 15$ в месяц он держит указанную Вами посещаемость. Поддержка понимает не только по-английски, но и по-русски. Наш сайт Razgonka.ru сидит у них несколько лет вкупе с другими сайтами на Друпале, все прекрасно.

Если есть один хостинг, умеющий работать с Друпалом, наверняка есть и другие хостинги.

Murz says: я перешёл на Drupal в надежде что он более лоялен к нагрузке на сервер, особенно для небольших проектов (например штук 10 текстовых страниц, пара лент новостей с комментариями, простейший форум средствами drupal и форма обратной связи), но сейчас что-то мне так уже не кажется.

На том же CifNet.com сайт Razgonka.ru располагается не как основной сайт, а как припаркованный. Кроме Razgonka.ru в таком же паркованном состоянии на одном тарифном плане находятся еще под десяток сайтов на Друпале. Все вместе они генерят указанную Вами посещаемость. У каждого сайта отдельный FTP-вход, можно заводить много баз MySQL, у припаркованных сайтов практически те же самые возможности, что и у основного сайта. За все сайты идет общая оплата - 15$ в месяц.

Вы тратите свою энергию на увеличение быстродействия Drupal. И Вам придется тратить ее каждый раз при смене версий Друпала. Но проблему проще решить поиском подходящего хостинга.

Murz says: а использовать для каждого типа сайта свою CMS - тоже не дело, голова опухнет привыкать сразу к куче CMS-ок разных, лучше уж подобрать одну универсальную....

У Вас правильный поход. Широкие специалисты сейчас не нужны. Нужно специализироваться на одной CMS. Тем более, что Друпал достаточно универсальна как система управления сайтом. Ее можно использовать и для создания небольших сайтов для себя и для разработки сайтов серьезным клиентам.

Подпишитесь на форум "Заказы на разработку и поиск работы". Возьмите подходящий заказ на установку сайта на Друпале. У Вас появятся деньги, на них переедете на нормальный хостинг. И сможете тратить свое время не на адапатцию Друпала к русским хостингам, а на дальнейшее изучение его возможностей.

CifNet.com за 15 долларов имеет очень серьезное ограничение всего "100MB of storage space on the CIFNet server" и "15Gb of Monthly Data Transfer"

Razgonka.ru says: Если сидеть у русских хостеров, то здесь Вы правы. Тот же MasterHost.ru ри малейшей загрузке базы начинает подталкивать клиента на виртуальный сервер. И в базе MySQL для экономии места у него вся информация из UTF-8 на лету переконвертируется в в Win-1251, а при запросе восстанавливается обратно. Формально получается, что клиент у MasterHost.ru получает базу в кодировке UTF-8, но в некоторых тонких местах хранение данных в Windows-1251 вылезает наружу.

В импортной части Интернет есть хорошие хостинги, умеющие размещать с сайтами на Друпале. Например, http://www.cifnet.com/ На тарифном плане 15$ в месяц он держит указанную Вами посещаемость. Поддержка понимает не только по-английски, но и по-русски. Наш сайт Razgonka.ru сидит у них несколько лет вкупе с другими сайтами на Друпале, все прекрасно.

Если есть один хостинг, умеющий работать с Друпалом, наверняка есть и другие хостинги.
Насчёт хостинга это понятно, что можно найти хороший и особо не партся, это не проблема и не в деньгах впринципе дело-то. Дело наверно больше во мне, как в программисте - просто рука не поворачивается каждый раз наворачивать модуль перевода и несколько тысяч строк перевода только лишь для того, чтобы у посетителей были русские ссылки "подробнее", "комментировать", "отправить" и ещё пара десятков строчек от силы. В админку лазюют только квалифицированные люди и их английский язык полностью устраивает, даже больше чем русский с некоторыми хитро переведёнными фразами, которые сразу-то и не поймёшь что имелось в виду. Весь контент сайта создаётся на русском, менюшка тоже на русском.

В итоге получается что очень функциональный модуль перевода используется всего лишь для перевода 10-20 строчек (даже не строчек а слов), при этом увеличивая в разы нагрузку на базу. Вот это мне как раз и не даёт спать по ночам ;) - сервер у меня свой (железка стоит у провайдера в стойке) и сайтов на нём крутится довольно много. И каждый раз нагружать сервак новым "тяжеловесом" на друпале из 5-10 страничек желания мало, прям так и хочется сделать эти странички статическими на html и выложить безо всякого mysql и php.

Когда я раньше сидел на других CMS (XOOPS, Mambo, Joomla и т.д.) - там такой проблемы не было, качаешь просто версию с русским фронтендом и все сообщения для посетителей сайта становятся русскими, а админка и остальные объемные вещи остаются на английском. Меня это вполне устраивало и не давала лишней нагрузке на базу. Или вот взять в пример русский инсталлятор Drupal - там авторы не побоялись и прямо в php-коды вписали русские тексты и ничего, не сломался вроде Друпал, много народу качают, пользуюся и счастливо живут, хотя по моему мнению - смысла переводить инсталлятор не было никакого, т.к. и в английской версии тех простейших сообщений любой малограмотный разберётся...

D друпале, я думаю, перевод только фронтэнда (как раз этих 10-20 строчек) много времени не отнимет, а облегчит нагрузку на сервер значительно. Тем более, я думаю, чтобы при каждой новой версии с нуля не русифицировать, можно процесс автоматизировать - создать скрипты с Regexp-выражениями, которые в слегка изменившемся коде будут находить места со строчками для перевода и заменять их на свои. Это, я думаю несложно написать. Если никто ещё этим не занялся, то как посвободней стану - думаю сам и займусь, а то устал уже по ночам ворочаться в переживаниях о лишних запросах к базе! :-)

Razgonka.ru, кстати - можно нескромный вопрос? ;) А каким образом Вы делаете цитирование имени и куска сообщения? (всмысле фразу "Murz says: ...") - тоже вручную оформляете как и я или есть на сайте волшебная кнопочка, которую я не заметил?

Я не думаю, что MySQL такой тупой сервак и по всем запросам лезет на диск в базы.
А как с кэшем, памятью у SQL?
Вы видели какие запросы генерирует 1С 8.1 на средненагруженный сервер или любая ERP система?
А там ещё куча SP на серваке работают, а тут прямой параметризованный SELECT.
IMHO, проще доплатить $5, чем "писать на ассемблере",

Да ну, тоже мне проблему нашли.
И не обязательно во всех модулях менять англ. словосочетания на русские.
Достаточно переписать функцию t() по своему что-бы она брала перевод из po файлов модуля напрямую и может уже это кто-то сделал.

Функция t() вызывается очень много раз и если каждый раз её заставлять перелопачивать po-файл для поиска строки на замену, то получится примерно то же самое что и из mysql-базы брать, так что смысла в этом мало.

PVasili says: Я не думаю, что MySQL такой тупой сервак и по всем запросам лезет на диск в базы.
А как с кэшем, памятью у SQL?
Если у MySQL одна база и один сайт, то всё выглядит очень хорошо - все необходимые данные MySQL закеширует и будет отдавать очень быстро из памяти, к тому же многие запросы тоже запомнит и будет выдавать результат вообще без обращения к базе. Но у хостингового сервера ситуация обычно другая - баз там около 100-500-1000 и сайтов соответственно крутится на нем примерно столько же, при этом обращения идут не по-очереди (утром к одной базе, а вечером - к другой) а в разнобой, поэтому база уже не в состоянии прокешировать весь этот объем разнообразных запросов и отдача от кеширования сводится практически к нулю.

PVasili says: Вы видели какие запросы генерирует 1С 8.1 на средненагруженный сервер или любая ERP система?
А там ещё куча SP на серваке работают, а тут прямой параметризованный SELECT.
IMHO, проще доплатить $5, чем "писать на ассемблере",
Та же 1С или ERP-система имеет обычно выделенный сервер и работает с ним единолично, поэтому преимущества кеширования там себя проявляют во всей красе, тем более запросы там идут однотипные и группами. К тому же при добавлении нового "тяжелого запроса" разрабочики, я думаю, не раз поразмыслят над его целесообразностью, оптимизацией и упрощению перед тем как добавлять в код, иначе бы эти программы сейчас работали бы совсем "небыстро". А оставшиеся сложные запросы действительно целесообразны и от них уйти нельзя, поэтому они и остаются.

И в этой теме я как раз поднимаю вопрос не о количестве и сложности запросов Drupal а об упрощении и ускорении его работы без ущерба в функционале.

7 Murz saysобычно другая - баз там около 100-500-1000 и сайтов.
Не думаю, что сайты с высокой посещаемостью живут среди 500 сайтов на одной машине. Отсюда и вывод напрашивается большая нагрузка - выделенный сервак, маленькая - нормально и среди 500 будет жить.

7 Murz saysимеет обычно выделенный сервер вы считаете, что у провайдеров серверы заняты параллельным вычислениями ядерных реакция, а сайты так в фоне крутятся(тем более 500 на одном компьютере)? Это в 1C однопитные? Даже не знаю как и откомментировать...

Про $5 я уже упомянул. Да ещё + "красные решения" [(с) Разгонка] и время потраченное на всё это вкупе, выльется в потери, несравненно большие, чем те же $5.

PVasili says: вы считаете, что у провайдеров серверы заняты параллельным вычислениями ядерных реакция, а сайты так в фоне крутятся(тем более 500 на одном компьютере)? Это в 1C однопитные? Даже не знаю как и откомментировать...
Обычно провайдеры нагружают сервера чуть ли не на 100% чтобы получать с них максимум дохода, а когда уже валятся массовые жалобы что всё тормозит - начинают закупать новое оборудование и расширяться, по крайней мере в России я думаю у большинства точно так и происходит, а уж в Нижнем Новгороде, где я живу - все провайдеры именно такие ;)
Про однотипные запросы в 1С я имел в виду что база одна и кол-во типов запросов довольно ограничено, поэтому можно задать большой кеш и всё это дело правильно закешируется, в отличии от хостингового сервера, на котором куча сайтов крутится.

PVasili says: Про $5 я уже упомянул.
Я уже писал, что эту тему поднял не с проблемой того что сайты на Drupal тормозят на дешёвых хостингах, а с целью обсуждения возможности создания альтернативного перевода Drupal, который значительно снижает нагрузку на базу, особенно для маленьких сайтов из нескольких страничек на одном неанглийском языке. А в результате тут развели полемику и споры о том, что дешёвый хостинг отстой, что нужно покупать выделенные серваки и не парится по поводу тормозов и т.д. и т.п.

Каждому своё, кому-то наплевать на деньги и бюджеты на хостинг, а кто-то бережёт каждую копейку, поэтому перед пользователями должен быть выбор - либо дёшевый хостинг и лёгкий быстро работающий сайт, либо полнофункциональный универсальный сайт и дорогой хостинг.

Поэтому предлагаю прекратить споры о хостингах и нагрузках на базу и просто обсудить предложенный мною вариант локализации.

Немного пораскинув мозгами я вроде-бы нашёл довольно простой способ локализовать интерфейс в исходниках сайта в автоматическом режиме:
1. Берём файл перевода (например, ru.po).
2. Подгружаем все исходные строчки и перевод.
3. Запускаем скрипт, который пробегается по всем исходным файлам, ищет строчки "t('<строка для перевода>'...)" и заменяет в них строку на переведённую.

Вот впринципе и всё - простейший скрипт, никаких сложностей и Drupal с переведенными исходниками готов. И нет никаких зависимостей от версии исходников и полноты перевода. И в результате получается лёгкий локализованный вариант для мелких одноязычных сайтов.

Как найду время - займусь написанием и как всё будет готово - обязательно поделюсь с народом.

Еще важно не забыть про кодировку!
И второй сложный момент - плюралы (множественное число).

Интересно, а как можно замерять кол-во запросов к базе, есть ли какие-нить штатные средства у самого друпала?

andypost@drupal.org says: Еще важно не забыть про кодировку!
И второй сложный момент - плюралы (множественное число).
Кодировка-то вроде у Drupal одна, UTF-8. А по поводу плюралов - я пока ещё не видел как эта проблема решается в модуле локализации, но думаю можно что-нибудь придумать...

andypost@drupal.org says:
Интересно, а как можно замерять кол-во запросов к базе, есть ли какие-нить штатные средства у самого друпала?
Есть модуль Devel, в нём есть система сбора и отображения всех запросов к базе при загрузке страницы, а также времени запросов и т.п.

// 3. Запускаем скрипт, который пробегается по всем исходным файлам,
// ищет строчки "t('<строка для перевода>'...)" и заменяет в них строку на переведённую.

это вообще абсурд, если боитесь что t() создаст нагрузку, тогда надо ее более правильно написать, наверно есть какие-то приемы.

Да и вообще это все актуально только для зарегистрированных пользователей - так как для анонимных оно все идет из mysql кеша.

kiev1 says: это вообще абсурд, если боитесь что t() создаст нагрузку, тогда надо ее более правильно написать
Я здесь предлагаю способ не "более правильно написать" а вообще избавить эту функцию от лишней работы. А если лишнюю работу функция делать должна, то как её не переписывай, всё-равно лишнюю нагрузку она давать будет.
Ведь для осуществления перевода нужно устанавливать модуль Localizer, который вешает перехват на кучу функций и этого никак не избежать, проверки так и так проводятся, обращения к базе тоже (пусть даже там 10 фраз вместо 1000). А в случае перевода исходников - никаких дополнительных перехватов не вешается. В этом как раз и идёт значительное облегчение работы.

К тому же в описанном выше способе перевода возможно сделать двунаправленный перевод - "перевести" и "вернуть в исходные строки как было", так что всё будет безопасно. Планирую даже сделать интерфейс, в котором галочками отмечаешь какие модули переводить а какие нет, и "вернуть исходный вариант" чтобы люди не боялись всё сломать этими переводами.

Murz says:1. Берём файл перевода (например, ru.po).
2. Подгружаем все исходные строчки и перевод.
3. Запускаем скрипт, который пробегается по всем исходным файлам, ищет строчки "t('<строка для перевода>'...)" и заменяет в них строку на переведённую.
Ага, потом не забудь ещё все файлы Друпала перевести в кодировку UTF8, и каждый новый модуль автоматом....

> Ведь для осуществления перевода нужно устанавливать модуль Localizer,
За перевод интерфейса отвечает штатный модуль Locale.

jason32 says: Ага, потом не забудь ещё все файлы Друпала перевести в кодировку UTF8, и каждый новый модуль автоматом....
Перевести в UTF8 труда не составит - одна строчка кода. Каждый новый модуль автоматом - тоже не требуется, да и разьве сейчас при установке нового модуля автоматом подгружается к нему перевод на нужном языке? Нет. Нужно ручками его искать, ставить и т.д.
И у меня будет делается таким же способом, с тем же количеством "кликов".

vadbars@drupal.org says: За перевод интерфейса отвечает штатный модуль Locale.
Да, извиняюсь, перепутал, стандартного модуля хватает для перевода основного интерфейса. Но то что он штатный - это не означает что он не создаёт лишней нагрузки и его отключение не ускорит работу сайта.

Локализация через статический файл для Друпала 5