Every API interaction is billed as a quantity of
ceil(payload_size_kb / 64kb) requests, so each request (send, receive, empty receive) is billed as a number of requests ranging from 1 to 4 (256kb is the maximum payload).
If you have 2.5M empty receives per day, then you either have a very large number of consumers, or you are not using long polling. You should definitely be using long polling. I've never encountered a case where it was not appropriate.
Long polling helps reduce the cost of using Amazon SQS by eliminating the number of empty responses (when there are no messages available for a ReceiveMessage request) and false empty responses (when messages are available but aren't included in a response).
Long Polling is sometimes misunderstood, since the queue parameter are called things like Receive Message Wait Time and WaitTimeSeconds and this is occasionally misinterpreted to mean the consumer will wait or be delayed by this many seconds... but this is not the case. This is only the amount of time the consumer waits when 0 message are available. When a message is available, it is still returned immediately. If the queue is empty and a consumer is, say, 7 seconds into a 20 second long poll when the next message arrives, the consumer does not wait for the remaining 13 seconds. The new message is returned immediately.
You will almost always want to use long polling, and use the maximum possible value of 20 seconds. This value should really have been the default, and a consumer wanting anything else should have been required to specify it.
If your consumers can handle multiple messages at a time, increasing the number of messages requested to the maximum value of 10 will also reduce the number of billable requests. Again, setting this value to more than 1 will not increase the amount of wait time. If fewer than max messages are available, the number available is returned immediately, when long polling. You only wait when the available messages are 0.