You've gotten a couple of answers that talk about how to prevent problems for heap fragmentation, but neither really addressed your question directly. Nearly the only way to estimate how likely it is to suffer problems for fragmentation is to simulate lots of use, and measure the fragmentation you get.
Since it's an NT service, simulating months of use mostly consists of making a lot of requests in a hurry. Chances are that you can make requests faster than it's normally expected to receive them, so you can probably simulate several months worth of requests in only a few hours, and quite possibly even less (depending on the rate at which you normally expect to receive requests).
Once you simulate months worth of work (or even as you're doing so) you then need to look at the heap to see how much fragmentation you're getting. This isn't easy, but it's normally possible. You'll start by injecting a thread into the service process (Googling on "thread injection" or something on that order should get a fair amount of info). Then you'll need to walk the heap, looking (in particular) for blocks that are free, but too small to be likely to satisfy most requests. Assuming you're using MS VC++, you walk the heap with _heapwalk, and it'll walk through the heap telling you the address, size, and status (free or in-use) of each block in the heap.
One last detail: for this to produce meaningful results, both the executable AND the DLL containing your injected thread have to be linked to the run-time library in a DLL. This means there will be one heap for the whole process, so your injected thread will walk the heap being used by your service. If you link the standard library statically, the DLL and the service will each have its own heap. The DLL will walk its own heap, which will tell you nothing about the heap being used by the service process.
与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
