ПС без разницы, что за движок. Если URL останутся прежними, тексты и разметка останутся прежними, то вообще ничего в плане ранжирования не изменится. Потом, после переноса можете начинать потихоньку менять содержимое сайта.
Процессоры одинаковые? Тип дисков (SSD/HDD) одинаковый? Померьте характеристики через unixbench (например скриптом http://serverbear.com). И самое главное: суппорт одинаковый? ☝
proksey-net: Вы, может, заметили, что SQL_CALC_FOUND_ROWS, например, используются очень редко. Вместо этого отправляется запрос COUNT(*), потом выборка. Также редко используются INNER JOIN при связях таблиц.
If you have an INDEX on your where clause (if id is indexed in your case), then it is better not to use SQL_CALC_FOUND_ROWS and use 2 queries instead, but if you don't have an index on what you put in your where clause (id in your case) then using SQL_CALC_FOUND_ROWS is more efficient.
А что конкретно интересует? Описание ключей к openssl? Документация к EJBCA? Или как настроить центр сертификации в windows server?
А что в dmesg и в /var/log/syslog пишется после modprobe?
После обновления ядра перезагружались?
uname -a что пишет?
А что за ядро у вас? Дистрибутивное или от хостера?
ПС без разницы, что за движок. Если URL останутся прежними, тексты и разметка останутся прежними, то вообще ничего в плане ранжирования не изменится. Потом, после переноса можете начинать потихоньку менять содержимое сайта.
Новый домен мошенников: skywarts.ru
https://www.dropbox.com/help/4204
Что то вида http://html5maker.com или вам другое?
Просто нет смысла оптимизировать то что *пока* никому не нужно :)
Цена одинаковая
Процессоры одинаковые? Тип дисков (SSD/HDD) одинаковый? Померьте характеристики через unixbench (например скриптом http://serverbear.com). И самое главное: суппорт одинаковый? ☝
Вы, может, заметили, что SQL_CALC_FOUND_ROWS, например, используются очень редко. Вместо этого отправляется запрос COUNT(*), потом выборка. Также редко используются INNER JOIN при связях таблиц.
Наверное, на это есть причины?
According to the following article: https://www.percona.com/blog/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/
If you have an INDEX on your where clause (if id is indexed in your case), then it is better not to use SQL_CALC_FOUND_ROWS and use 2 queries instead, but if you don't have an index on what you put in your where clause (id in your case) then using SQL_CALC_FOUND_ROWS is more efficient.
P.S. Сам не тестил.