Вынос БД и скриптов на отдельный сервер

Igor Prusakov, Цифры посещаемости в студию!

Полезная штука

5 и 6 к в сутки, просмотров понятное дело сильно больше. машинка простейшая. просто есть возможность от арендованного сервера избавится. т.е. мысль то какая - сами сайты на обычный хостинг, а все тяжелое на другой сервер. он для меня халява будет (но там не сервера - змей горыныч о 2 процах да на квадре). но по определенным орг. причинам сами домены целиком я туда повесить не могу.

попробуйте нанять программиста пофиксить запросы, явно есть путь упростить работу. и не думали ли вы, что это могут быть не скл запросы медленные ? такое тоже бывает :)

некомендую пройтись по запросам select sql_no_cache ...

и посмотреть сколько в реале выполняются запросы, расставить индексы и пооптимизить можно же :)

встречал ситуацию, когда изза плохих рук запрос выполнялся от 40 до 150 секунд. после оптимизации ~0.000 время выполнения запроса.

bearman добавил 07.06.2008 в 03:10

ну и вынос на другой сервер это решение влоб, и то может поднимете посещаемость до 7-9 и получите опять такую проблему :)

Теоретически-то можно, но вот на практике в Вашей ситуации "тяжелый сервер" скорее всего окажется "далеко от обычного хостинга", допустим даже 0.1с пинг + запрос в БД, 20 запросов в БД, уже 2 секунды получится, а если 40? А если 0.2с пинг с запросом?

Если бы Вы размещали сервера рядом, то в общем-то это стандартное решение - пхп скрипты тут, мускул там.

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

А вообще при 5-6к имхо должна быть достаточная прибыль с проекта, что бы держать нормальный сервер, Вы своего времени возможно больше потратите, чем денег сэкономите в результате. Или как вариант - заплатить за оптимизацию скриптов и/или БД и/или сервера в конце концов, зачастую помогает экономить на сервере в 2-3 раза - факт.

bearman, спасибо за ответ.

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

40 запросов к бд чтобы получить страничу это уже ***ц :)

проще оптимизировать, класть в сессию и тп, можно же многое закешировать в конце концов.

дайте урл сайта просто на интерес, можно в личку.

edogs, хостер и сервер живут в 1 дц. воткнуты в одну циску.

т.е. верно понимаю - что собственно имеет смысл выносить базу, а не скрипты, верно?

ну если уж выносить, то конечно мускуль базы на отдельный сервер. и по возможности если есть доступ к my.cnf добавить query_cache или нечто подобное не помню точно, поставить метров 100. это даст автоматическое кешширование результатов запросов самим мускулем! :)

так что одни и те же страничку начнут грузиться быстрее)

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

bearman добавил 07.06.2008 в 03:27

ну и думаю напоследочег ))

http://www.arnebrachhold.de/2007/02/16/four-plus-one-ways-to-speed-up-the-performance-of-wordpress-with-caching/

если знаете ингл, то думаю, что статья вам поможет.

bearman добавил 07.06.2008 в 03:27

WordPress Internal Caching

In case of a slow database server, it might be a good idea to store frequently used data in a serialized form on disk. WordPress has an integrated disk-cache which stores rarely changing data like categories and users in a special folder. Note that this cache is not recommended if the disk is slow or your host (like DreamHost) set up a NFS based storage solution which would request the cached data from a remote storage server. To enable WordPress’s internal caching, uncomment or add this to your wp-config.php: define( ‘ENABLE_CACHE’, true ); and make sure that the wp-content/cache folder is writable!

bearman добавил 07.06.2008 в 03:29

и вот еще :)

MySQL Query Cache

Since WordPress uses MySQL, almost every page load results in various MySQL queries for logins, post content, categories and so on. It is very likely that this data didn’t change since the last request so we begin with enabling the cache within the MySQL server. Basically, all you need to to is to activate it in the my.cnf (or my.ini) MySQL configuration file with setting the query-cache-type variable to 1. The query-cache-size variable is the size of the query cache in MB, for example 20M. To change the MySQL configuration file, you’ll probably need root access which won’t be available on shared hosts. More info about query cache is available on techiecorner.com and the MySQL Performance blog.

На чисто теоретический вопрос чисто теоретический ответ: да, можно.

Но практически, не факт, что это что-то изменит.

Смотрите, какие процессы грузят сервер и оптимизируйте их.

Меня тоже прогнали с хостинга, даже выделенный сервер не справлялся, заменил софт, и проблема решена. Устанавливайте Nginx/php-fcgi/apc и будет вам счастье!

Оффтоп.

Вспомнилось (не помню откуда, с баша чтоли):