Allright, here is some general advice on streamlining your base to help both your client and the server to cope with things better.
I could of course give you a 1000 point long list of what causes lag but that'd have me typing all day and I'd still forget half the cases, so what I'll try to do with the following lines is to give you a basic understanding of how Minecraft's inner working influence server and client performance. I am simplifying things in this post and my numbers are probably not 100% accurate but it should help you get the idea.
When you play Minecraft, the server has to sent your client what is in the world around you. It does so when you load a new chunk (by moving around or logging on) or when a block update occurs (for example your furnace has cooked an item etc.). With every bit the server sends, it of course has to do some calculations (one item cooked means one more in them output slot, 1/8 of that coal piece has been used etc.) and the client has to do the same (update the number on your screen for example). The more is send and calculated the more server- and clientside resources are used (that's what we're trying to reduce here).
What we can do to lighten the load is reduce the amount of sending and calculating going on in the background but also how much is send.
A series of examples with rising load:
1.) Imagine a world with just one dirt block or stone block or stair. What the server has to send in this case is the item ID and the so-called metadata. All in all that's less than 2 Bytes of data, so even if we have thousands of blocks to load that's not a problem since we're only somwhere around a few Kbyte. That's easy to handle for server, client and connection. Additional bonus is that we only have to send the data once because, well, stone blocks do not change on their own so no need to inform the client that nothing has changed.
2.) To go away from the above ideal case we now look at the feared microblocks. These need more than just those 2 Bytes I mentioned above because they contain information on which different materials occur in the block in which form and in which position. 2 Bytes, that's 16 0s and 1s is not enough to contain that much information. This additional info is saved in the often discussed tile entities. Of course there's not much to calculate in this case, micro blocks don't change on their own, but you have to see that we are now sending several times the data per block and microblocks are usually used in massive amounts. That leads to a gradual decline in performance, so while 100 microblocks are not a problem and 1000 are not a problem either, they add up to the total load on both client and server.
3.) Another nice thing about the blocks under 1.) is that there can only be one of them in any given space. That means even if the world is completely filled with blocks their amount is finite. This sadly doesn't apply to entities though. What are entities now? Simply put, animals and items on the ground or in tubes or pipes. If you have 1000 cows on your plot the server has to calculate where every single one of those is moving atm and it has to send that information to the client as well. Same goes for items.
Some things to avoid are loops in your pipe or tube networks, eternal automatic breeding machines (beware of villagers) or overflow pipes pumping into the landscape (use lava or even better void pipes). Entity that are easily forgotten because they are invisible in the game (as a single unit) are EU packets and liquids/gases. How to reduce the amount of EU entities? Shorter cables = shorter travelling times = less entities on the map (same for liquids). Also keep in mind that every solar panel sends out 20 entities per second, so better get that one big panel instead 200 small ones.
4.) A different way to "spam" the server and client is to have the same information processed and send very often. A classic example is a timer that pulses rapidly. With every pulse the information about the timer and all cables and machines hooked up to it gets reprocessed and resent. So switching from pulsing every 200ms to once a second or two makes a huge difference(try to alter your setups in a way that makes this possible/feasable). I do know that a certain amount of pulsing is necessary for many an automation so here some tips:
There are hidden "pulsers" in the game for example the RedPower relay. It checks several times a second if it contains something that it can send, better use a chest with a wooden pipe+autarchic gate.
DO NOT ever pulse any light sources. Every time a light source (torch, lamp etc.) turns on or off it does not only send it's own information into processing again but also the info of all the blocks it lights up (or stops lighting). With a pulser and 20 lightblocks you can punch your FPS down to <1 easily.
Protip: Use insulated wire instead of normal redstone or uninsulated wire it uses less resources to switch its state because it doesn't change visually.
5.) Any type of machine or otherwise advanced block is a combination of 2. and 4. so they ar slightly worse than microblocks especially when active. Generally every player can build a full set of machines without breaking the server though unless some people have to overdo things again ... *whistles*
Lastly a special case I have to mention because it is something used by almost every player:
Sorting systems! These have to check dozens of inventories to find a spot for every single item and that can mean dozens of items per second. Whatever way this is done it will be a severe performance problem, so the more player through their stuff together, the better.
I'd ask anyone who wants a sorting system to check with me or someone else who has knowledge of these things if their system can not be improved in one way or another. A hundred barrels connected by tubes is definitely not the best choice.