[s0ulleSS]

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

[Mr. Anderson]

s0ulleSS
У меня на прошлом провайдере периодически роутинг на разное зарубежье пропадал. То кривые руки админов, то недовведенные мощности, то перебитые магистральные каналы... Так вот в такие моменты я часто по минуте ждал открытия страниц гуру... Не потому, что тормоза, а потому что гугл-аналитикс (а еще и адсенс был одно время) + отсуствие роутинга на сервера гугла и привет - жди таймаута. Но это фигня - на собственно функционале сайта не сказывалось... Чего не скажешь о вашем предложении...
Вы же просто предлагаете увеличивать надежность, увеличивая число уязвимых мест. Нонсенса не замечаете?

[Garret_Dark]

s0ulleSS писал(а):Вы бы хоть посмотрели что это за сторонний ресурс, а потом уже говрили. Есть небольшие(хотя, болшьшие) подозрения что у вашего хоста шансы упасть намного выше.

Блин...
Если, гипотетически, мой хост на время упадет, но при этом тотже гугл со своим JQuery останется онлайн, то моему хосту это аж никак не поможет, а вот наоборот, если упадет гугл, а мой хост останется онлайн, то это навредит.
Такчто однозначно заливать к себе и зависить только от своего хоста.

[nixit]

А решена ли проблема открывании формы быстрого ответа, при быстром цитировании?

[nissin]

Поддержу s0ulleSS, а то ведь заклюете
С точки зрения скорости загрузки желательно статику размещать на другом домене (файл javascript тоже статика), поскольку в этом случае браузер делает загрузку в несколько параллельных потоков.
Файл лежащий на сайте у гугла вполне может быть уже закеширован в браузере у пользователя (например, если пользователь уже открывал другой сайт, на котором используется эта библиотека размещенная на гугле).
Файл лежащий на гугле не создаёт нагрузки на сервер форума.
Минус только один, если сайт гугла недоступен, либо гугл решил закрыть у себя поддержку данной библиотеки, то она не сможет загрузиться.

PS: Можно и на Яндексе хранилище использовать:
http://api.yandex.ru/jslibs/libs.xml
http://habrahabr.ru/company/yandex/blog/87609/

[Петрович]

nissin писал(а):а то ведь заклюете

Даже и в мыслях не было. На его вопрос, каждый привел свой аргумент.

nissin писал(а):Файл лежащий на гугле не создаёт нагрузки на сервер форума.

Будь добр, внеси ясность тогда, какую нагрузку будет испытывать сервер форума, если файл будет лежать здесь же? Это ведь статика

[nissin]

Любая раздача создаёт какую-либо нагрузку на сервер.
А javascript библиотеки, как правило грузятся для каждого посетителя, в случае jquery это получается более чем 100 Кб.
Если на фронте не стоит nginx, то для апача в самом популярном режиме prefork раздача статики как серпом ниже пояса.

PS: Люди, следящие за оптимизацией скорости загрузки и нагрузкой на сервер, для уменьшения количества запросов стараются объединить все js и css файлы, а изображения выводить через спрайты.

[cyber_punk]

есть пара вопросов по нагрузке

1. Смотрю в phpMyAdmin Текущее состояние MySQL
там красным отмечены следующие переменные:

Handler_read_rnd 6,966 k
"Количество запросов, на чтение строки, основанных на ее позиции. Большое значение переменной может быть обусловлено частым выполнением запросов использующих сортировку результата, выполнением большого числа запросов требующих полного сканирования таблиц, наличием объединений не использующих индексы надлежащим образом."

Handler_read_rnd_next 2,380.29 M
"Количество запросов на чтение следующей строки из файла данных. Данное значение будет высоким, при частом сканировании таблиц. Обычно это означает, что таблицы не проиндексированы надлежащим образом или запросы не используют преимущества индексов."

Select_full_join 29 k
"Количество запросов-объединений, выполненных без использования индексов. Если значение переменной не равно 0, рекомендуется проверить индексы таблиц."

Вопрос: почему таблицы не проиндексированы/не используют индексы?
Как их проиндексировать?

2. Стоит ли разделять большие многостраничные темы или это уже не актуально?
Если да, то сколько максимум сообщений оставлять в одной теме?

[Пчелкин]

2. 250 максимум (рекомендуется)

[cyber_punk]

250 сообщений? не страниц?
если сообщений, то это совсем не серьезно, при 20 сообщений на страницу, 13 страниц всего получается.
а где такое рекомендуется можно посмотреть?

[mih_io]

cyber_punk писал(а):2. Стоит ли разделять большие многостраничные темы или это уже не актуально?
Если да, то сколько максимум сообщений оставлять в одной теме?

У меня есть тема больше 300 страниц. Любая страница этой темы открывается быстро и легко. Я думаю это ограничение не актуально.

[Пчелкин]

Пригодится...
Закрытие темы после некоторого количества постов

Добавлено спустя 34 секунды:

mih_io писал(а):У меня есть тема больше 300 страниц

И кто ее всю будет смотреть?

[mih_io]

Пчелкин писал(а):И кто ее всю будет смотреть?

Не вижу связи между количеством страниц и вопросом "И кто ее всю будет смотреть?".

По вашему лучше разделять такие темы, к примеру, на 3 части? чтобы было 3 темы по 100 страниц?

Или вопрос риторический? зачем нужны такие темы и о чем они?

[rxu]

Попрошу не оффтопить.
mih_io
Вопрос слишком общий. Неясно, о каких конкретно таблицах и запросах идет речь. Скорее, относится к настройке сервера, нежели к работе phpBB.

[Mr. Anderson]

cyber_punk
Тут нужна детализация - и по самой статистике и по времени её сбора. К тому же нет определенных рекомендаций - под каждый паттерн/настройку будут свои выводы/рекомендации.