This is not a lot different from any other project. You have a large task that will be accomplished by doing a bunch of small tasks. Whether the small task is to create a database, develop a UI, or perform load testing is somewhat irrelevant for the purposes of planning.
In order to do this "story" (which is really an epic, but could also be looked at as a feature or product or project), you need to break it down into smaller pieces just like you would with any other project. Then, you prioritize the pieces, then start working on them.
For example, the first few stories might be to do the following:
- develop load tests
- run load tests to generate a list of candidates for optimization
- prioritize the candidates
At that point you might have a dozen or so candidates. The next story would be to work on the highest priority candidate, then the next, then the next.
- create first optimization
- create second optimization
- ... and so on
That's not the only way. You could, for example, set up a story for "create and run load tests", then "optimize biggest bottleneck", then just repeat those stories over and over.
That being said, not all types of software development or teams are a good fit for scrum. It's impossible to say what's best for your organization. If you have a top-notch team that can simply go into a room, lock the door, and be highly productive for two weeks, scrum is overkill. If you have a team full of less skilled, disorganized people, you may want to stick as close as possible to scrum.
The bottom line is to get the work done. If scrum helps, use scrum. If it doesn't help, find what does. The most important parts of scrum are the transparency and continuous improvement. The stories usually help with the former, and the retrospectives usually help with the latter. In between there's a lot of room to do whatever works best for your team.