Project description
We run an online catalogue that has been growing for six years, and it has finally outgrown the machine it lives on. Category pages take about five seconds to open, catalogue search is worse, and at peak hours the whole site feels stuck. The database still sits on the old server, while the new one is already paid for and prepared. I am looking for someone who will move the data across with as little downtime as possible — by a written plan, with a rehearsal and an agreed switch-over window, not by pulling the plug on a Friday evening and hoping.
The second half of the job matters just as much, because paying for a faster machine and keeping the same slow queries makes no sense. Please read the slow query log in full, tell us honestly what really eats the time, add the indexes that are missing, rewrite the heavy selects, and replace the pages that fetch the whole table and cut it up in code with real pagination. What people request most often should be cached, and the cache must refresh itself rather than serve yesterday's prices. After the move I expect a verification pass over the entire site — sections, forms, search, user accounts — plus a short plain-language instruction our own admins can actually follow.
Before-and-after measurements are part of the work, not a bonus: I want numbers, not impressions.
Conditions I will not bend on:
— the migration is rehearsed on a copy, and the production database is not touched until that copy has been verified;
— every schema change is preceded by a backup whose restore has been tested, not merely created;
— nothing is changed live during busy hours — all risky steps happen inside the agreed quiet window;
— every index and every rewritten query comes with its own timing before and after;
— the closing report says what was changed, why it was changed, and how to roll it back.
The second half of the job matters just as much, because paying for a faster machine and keeping the same slow queries makes no sense. Please read the slow query log in full, tell us honestly what really eats the time, add the indexes that are missing, rewrite the heavy selects, and replace the pages that fetch the whole table and cut it up in code with real pagination. What people request most often should be cached, and the cache must refresh itself rather than serve yesterday's prices. After the move I expect a verification pass over the entire site — sections, forms, search, user accounts — plus a short plain-language instruction our own admins can actually follow.
Before-and-after measurements are part of the work, not a bonus: I want numbers, not impressions.
Conditions I will not bend on:
— the migration is rehearsed on a copy, and the production database is not touched until that copy has been verified;
— every schema change is preceded by a backup whose restore has been tested, not merely created;
— nothing is changed live during busy hours — all risky steps happen inside the agreed quiet window;
— every index and every rewritten query comes with its own timing before and after;
— the closing report says what was changed, why it was changed, and how to roll it back.
Software development Cash, Bank transfer
