Переход на новый хостинг. Оптимизация блога.

И так…

Причины по которым пришлось уйти со старого хостинга:

1. Перестала работать отправка почты. При регистрации нового пользователя, оставалось белое окно, письмо ни пользователю, ни мне не приходило. Письма о добавлении новых комментариев тоже не рассылались.
2. Не работали некоторые плагины, например плагин, реализующий древовидные комментарии.
3. Жуткие тормоза при работе с блогом.
4. Весьма интересный способ общения тех.поддержки хостера.

Первая проблема реально связана с настройками хостинга. Начал изучать этот вопрос, в  интернете полным полно тем с обсуждением проблем отправки писем wordpress’ом. Проблема частично решается установкой плагина phpmailer, частично потому что после его установки письма начинают приходить, но вся кириллица в них отображается какими-то кракозяблями, типа арабских знаков. На эту тему тоже полно постов в интернете. В любом случае народ сходится к проблеме настройки хостинга. Да и я тоже так считаю, хотя бы только потому, что после моей начальной установки wordpress работал нормально, потом хостер объявил о переносе на новые сервера, потом какие-то перенастройки были… сразу я ничего не заметил, от рассылки уведомлений о комментариях я отказался, в итоге узнал о проблеме только тогда, когда начали жаловаться друзья, что не могут зарегистрироваться в блоге. Конечно, можно было бы настроить отправку писем через SMTP, но увы…Со второй проблемой даже и не разбирался, знаю только, что например все тот же плагин WordPress Thread Comment без каких либо проблем работает в блогах моих друзей. Как выяснилось в дальнейшем, после переноса на новый хостинг, он начал работать без проблем и у меня. Раньше при добавлении ответа на чей-нибудь комментарий, вместо динамичной вставки ответа, я получал пустой прямоугольник, а сам текст можно было увидеть только после обновления страницы. Теперь ответ сразу же встает нормально.

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

Четвертая причина, вернее не совсем причина, просто еще одна капля… Когда начали разбираться с хостером по поводу неработающих плагинов (например все тот же WordPress Thread Comment) и функций (отправка почты), то на все наши (мой домен, один из 10-15 штук базирующихся на хостинге, по партнерскому договору) доводы по поводу одновременных, одинаковых проблем на всех сайтах, построенных на CMS WordPress, начавшихся после каких-то изменений в настройках хостинга (реально проводились какие-то работы, сайты какое-то время были не доступны) тех.поддержка ответила, что они “не занимаются проблемами наших скриптов”.

Как я переходил на новый хостинг:

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

1. сделал полный дамп базы на старом хостинге;
2. скопировал все содержимое корневой папки сайта;
3. на новом хостинге создал новую базу, в которую залил имеющийся дамп;
4. в корень сайта на новом хостинге залил все файлы и папки слитые со старого хостинга;
5. поправил wp-config.php на подключение к новой базе;
6. сменил NS сервера у регистратора домена;
7. подождал около 6 часов, и снова стал счастливым обладателем своего блога.

Единственная проблема, появившаяся после переноса, это какие-то ошибки в хедере страниц. Оказывается на старом хостинге стояло подавление таких ошибок, на новом нет. Ошибки касались тех плагинов, которые я когда-то правил руками. После недолгих поисков в интернете я выяснил, что сохранял их после правки в кодировке utf-8, а надо было в utf-8 без BOM. Проблема решилась путем открывания проблемных файлов и сохранения их в правильной кодировке.

Как я решал проблемы производительности:

Один мой друг посоветовал сделать следующее:

1. Разделить для админки и лица файлы локализации, т.е. полный – оставить для админки, “кастрированный” – для лица сайта. В этом есть логика, основная часть переводов требуется именно для админки. В качестве описания он дал мне ссылку на лекактуса. Я поправил свой wp-config.php, и скачал у лекактуса “кастрированный” файл локализации. Т.к. у меня версия движка 2.8.4, а на ссылке выше предлагаются файлы максимум версии 2.7, то я просто скачал целиком весь дистр wordpress’а 2.8.4 PowerPack Lecactus Edition, и из него выдернул нужные мне файлы локализации. Эффект был примерно такой же как и описывает лекактус.
2. Заблокировать проверку обновлений для плагинов и движка. Тут опять ссылка на лекактуса. Не скажу, что получил грандиозный прирост производительности, но все же получил. Разница во времени примерно 0,4-0,3 секунды на генерацию страницы.
3. Установить плагин wp-super-cache. Пожалуй, для меня, с моим ничтожным знанием php и web, на первый взгляд это было самым сложным. Как оказалось все просто. Я нашел две статьи на эту тему, одна старая, от 08.2008, которая собственно меня и повергла в ужас, описывала установку плагина (кстати, такое же описание, только на инглише на странице плагина на сайте wordpress.org). Последняя версия плагина при активации сделал все, что описано в приведенной выше статье автоматически, я же просто по пунктам проверил все. Вторая статья описывает настройку плагина, хотя она не такая уж и сложная.

Как итог. Я на новом хостинге, пока что все старые проблемы ушли, а новые либо отсутствуют (во что очень хочется верить), либо я просто их еще не нашел. При оптимизации я считаю наиболее эффективными приемами разделение файла локализации на толстый, для админки, и тонкий, для лица, файлы, а так же применение плагина wp-super-cache. В моем случае задержки на генерацию страницы упали с 5-6 секунд до 0,7-1,2 (значение больше секунды связано с использованием плагина Picasa Widget, который выполняется до 0,5 секунды), а использование памяти сервера с 15-18 Мб до 8-12 Мб.

Желаю всем успехов, буду рад если смог кому-то помочь.

Добавлено спустя несколько дней после публикации: все бы хорошо, но… плагин wp-super-cache почему-то напрочь испортил мне регистрацию новых пользователей. Возможно я просто не разобрался с какими-то из его настроек, может надо было добавить какие-нибудь исключения (кстати пробовал, но мои попытки не увенчались успехом). У меня стоит плагин sabre, стоит для того чтобы была капча на регистрацию, а так же чтобы пользователь при регистрации мог сразу указать нужный ему пароль, а не довольствоваться сгенерированным. Так вот, при регистрации, именно этот плагин начал ругаться, выдавая сообщения:

• ERROR: Fake user
• ERROR: Session timed out

Если я отключал плагин sabre, то при регистрации просто ничего не происходило, страница не обновлялась. Сообщение “ERROR: Session timed out” натолкнуло на мысль, что мне просто подсовывают старую страницу из кеша, в любом случае отключение плагина wp-super-cache исправило ситуацию.

Оставаться совсем без кеширующего плагина я не хотел, все же это помогает снять нагрузку на сервер, да и увеличить скорость работы с сайтом. В итоге опять помог лекактус, я поставил себе плагин Hyper Cache. Регистрация теперь работает нормально.